RE: Future XSLT expansion.

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