Subject: RE: Future XSLT expansion. From: "Jonathan Borden" <jborden@xxxxxxxxxxxx> Date: Sat, 18 Mar 2000 10:32:52 -0500 |
Paul Tchistopolskii wrote: > > Yes I think document() function in the form document()/something/here > ( and in the form document() function itself ) has polluting the > 'core' sematics > of 'right' document() function and I will now explain it in > very much detail > below. > [lots of arguments deleted ....] > That means extensions should be by definition *engine-specific*. > > Once again. > > document() function is a logical hack, but not a reasonable > extension. document() is not an XSLT extension, whether you agree or not, it is a core language function. Frankly, not only don't I agree, but I don't even follow this series of convoluted arguments. The most sense I can make out of this is that you would prefer that document() not return a node-set, the only explanation I can reasonably see for this desire is that you would like document() to be used to incorporate non-XML data into the transform. Many people would prefer that XSLT accept non-XML input but it doesn't. XSLT is not a generalized transformation language, it is a transformation language designed to transform XML documents. > > Now what is the way it should be wih document(URI); Perhaps the problem is a language issue. I assume you are trying to say "Now this is the way it should be with 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. "text" is not an XSLT datatype (string is). The spec is very specific about the 4 xslt datatypes. A document is defined as an XML document, not an arbitraty MIME document. An XML document is a node-set (by definition!). The nodes it may contain include: comments processing-instructions *one* element (the root) document was not designed to be a 'grabber-of-data' rather a mechanism to allow ***multiple input XML documents***. > > 1. This allows user to import some XML document *not* converting > it into node-set ( not the way current 'polluted' document() works) Again: All XML documents *are* node-sets by definition. An XML document *is always* a node-set ... can I be more clear? > 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. What you are asking for is a way to include *non-XML* input documents into the result-tree. Do you wish to limit this to strings or extend this to binary data as well? What happens if the raw included data does not produce valid XML output? Error checking? You see, some processing/escaping etc. is desirable. Jonathan Borden XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: Future XSLT expansion. ( Re: Mi, Paul Tchistopolskii | Thread | Re: Future XSLT expansion., Dan Morrison |
Re: How do I output an ampersand?, David Carlisle | Date | Re: Future XSLT expansion., Dan Morrison |
Month |