This is the mail archive of the xsl-list@mulberrytech.com mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Future XSLT expansion.




> 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.

Are you saying that means it should *never* give any way to transfer text 
into node-set on the fly? Looks like something religios  to me.
 
> >
> > 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***.

Yes, what you are saying looks consistent and reasonable. I'm very glad that 
XSLT vendors were wise enough to provide the back door ( node-set typecast ), 
not thinking too much about the suff you are explaining. 

> 
> >
> > 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?

I understand. It is clear. But I think you are assuming that it is me 
who wants to destroy this beauty with my ugly node-set typecast? 
Your assumption is wrong ;-)
 
> > 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.

I suggest you will start learning  the behavior of *already*implemented* node-set
typecasts. Yes. They are already in the game in XT, SAXON, e t.c. I think 
almost any XSLT vendor has that type-cast in there, because "XML document
is node-set by definition" and other scientific stuff looks nice only on 
paper, but in the real life there are some problems with that view. 

Those type-cases are not in the core, but they already exist and are 
used in almost any complex stylesheet, which tries to do something 
more smart than just processing bunch of XML plain files.

This learning will answer to your questions better than I can.

Rgds.Paul.



 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]