[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Future XSLT expansion.

Subject: Re: Future XSLT expansion.
From: Paul Tchistopolskii <paul@xxxxxxx>
Date: Sat, 18 Mar 2000 10:15:05 -0800
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


Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.