Subject: RE: Future XSLT expansion. ( Re: Microsoft XSL and Conformance ) From: "Didier PH Martin" <martind@xxxxxxxxxxxxx> Date: Sat, 18 Mar 2000 00:08:50 -0500 |
Hi Paul, Paul said: Now what is the way it should be wih document(URI); --------------------------------------------------------------------------- document(URI) ( like any other 'grabber-of-data' ) should return text but not node-set, but node-set typecast should be in the XSLT core. 1. This allows user to import some XML document *not* converting it into node-set ( not the way current 'polluted' document() works) BTW, could you achive this functionality with XSLT ? Just insert some external document into the output ? Why should everything be always 'converted' to node-sets, 'processed' an then turned back into text? I guess the only answer is 'because we see it this way'. Good for you, but limiting. 2. If user wants to achive the current document() -> nodeset conversion, she should use the node-set typecast explicitly. 3. Such design allows easy writing engine-independed extensions ( passing text to/from extension, but not node-set's) Isn't it obvious that the way taken by XSLT document() is perlish ? Still not ? Didier replies: not necessarily. I you mean that having a node tree is perlish, so yes you are right the construct is perlish since the concept of having a node tree is perlish. But to have the document returning a node set make sense especially if you use the following construct: <xsl:apply-templates select="document('....')/elementx/elementy"/> In fact the document function is probably more useful in this context than to simply get pure text. At least a node set can be processed. Paul said: My question is: do you see any way to utilize document()/part hack when you have multiple document trees / sources, or document()/part hack could be utilized only when processing multiple XML files ( something identified by URL ) ? The *real* semantics of document()/part is: 1. Give me some data from the outher space. 2. Filter that data with some criteria. The 'outher space' is considered to be XML file and only XML file + it should be *nodeset and only nodeset*. This is not scalable and very limiting. Not all the data in this world are XSLT vendor-specific node-sets. Why should SQL engine bother itself with conversions of some table into 'one-root-nodeset-alike' structure ( XSLT vendor specific nodeset structure). Didier replies: Error, the sql vendors will provide XML documents not node sets. So why are you talking about node set returned by sql servers here? Paul said: It is XSLT paranoya to see everything in this world as XSLT-vendor-specific-node-sets. Didier replies: Take note here that you said that, nobody else said that and more particularly not me. SQL vendors provide XML documents in text format not node sets. However, this XML document is transformed into node set for processing. Paul said: XSLT is better to solve it's paranoya by itself. ( placing node-set typecast into the core , but if making that step - what is the purpose of having current document() semantics? No purpose, instead of perlish 'send/recv and read/write' e t.c. ) I wish it is now clear. Didier replies: Its your opinion. Paul said: You are welcome. Because I have an impression that you don't understand what that realy means I have explained it once again in more detail. I'm sorry if that was disturbing. Didier replies: What was disturbing Paul is that you said that I proposed this and that this is not part of the specs. Sorry, you said that. And no, up to date I do not see any convincing arguments, just opinions and opinions are undisputable. Paul said: Yes. That's what I'm saying. 'documents other than the main source document'. This assumes the world is full of XML documents and only XML documents (XML files) are to be processed. That's just funny. That's what I was trying to explain. Didier replies: So... What is the point here. Paul said: Of course it is valid. It is just ugly. I'm not saying 'send/recv' are illegal in perl. My point is that perl is a monster. And also my point is that with document() hack XSLT choosed perl-ish way. Didier replies: OK its your opinion. Paul said: Core XPath engine type is vendor-specific 'node-set' and there is no type-cast to that type in the core. That's just funny, you don't see a problem here. That *is* a problem. A *real*design*problem*, forcing logical hacks ( like document() hack ) Didier replies: Do you mean here that a vendor may choose to return text from a document() function and an other a node set? I guess that we are still talking within the boundaries of XSLT 1.0 recommendations. Conclusion: Based on my experiments I discovered that the document() function is very useful. I just say that: useful. If you think this is not, the choice is obvious, do not use it. Cheers Didier PH Martin ---------------------------------------------- Email: martind@xxxxxxxxxxxxx Conferences: Web Chicago(http://www.mfweb.com) XML Europe (http://www.gca.org) Book: XML Professional (http://www.wrox.com) column: Style Matters (http://www.xml.com) Products: http://www.netfolder.com XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
How to import XML data into an imp, Vulcane Design | Thread | Re: Future XSLT expansion. ( Re: Mi, Paul Tchistopolskii |
Re: How do I output an ampersand?, Chris Knoll | Date | Re: Storing XSL Documents In Databa, ural |
Month |