Re: Future XSLT expansion.

> Thus I think your desire to force all communication between the XSL
> engine and external documents and extensions to go via a linearised
> string representation of XML would entirely be against the natural
> flavour of the language.

As I said - I have nothing against the world, when 'node-set' is everywhere. 
But we are not there and I don't think we'l get there in reasonable time.

What is 'natural flavour' - I don't understand. 
 
> As I mentioned, I have no particular objection to the provision of a
> pair of functions that parse a string as XML and conversely linearise an
> XML tree, Extra functionality is always useful. 

I don't care how typecasts would be called if  they will appear.

> I just don't see much use for them directly myself. 

> XSL already has enough problems as
> typically an entire document tree has to be held in memory, I can't see
> it will help much if you first have to pass the entire document as a
> string, and then in addition construct the tree.

I don't understand. document(URI) function already does it.
It takes the entire document and constructs the tree from it.

> > How can 'server' return 'node-set' ? 'Server' returns text. String.
> > XML file.
> 
> If I have SGML files (for which there exist sax compliant parsers)
> or in principle files of comma separated fields, or anything else
> the local setup can be arranged so that document() produces a suitable
> node set on that file. 

> Just as at the top level, the main input document
> does not have to be a real linear XML file it might be for example an in
> memory DOM resulting from an earlier transform. 

I understand  that  XML could be produced from any source. 
I have wrote PXSLSerlvet for creating XML from SQL. 

What PXSLServlet also does it has a chaining :

1. First PXSLServlet creates XML from the SQL.
2. Then generated XML  is passed to the XSLT
to be transformed. And of course it is passed not in 
form of linearized tree no intermediate file / string 
is created.

But doing things like this has nothing to do with 
typecasts I'm talking about.

> Saxon already has a simple method of chaining together transformations. 
> I assume (but havent looked at the code) that it does _not_ write out the result tree
> of one transformation as a string and the reparse the whole thing to
> produce the input of the next transformation. 

Yes. I assume it just invokes to-node-set() typecast on rtf. That's 
what I'm suggesting, BTW. Typecast from/to basic node-set type
in the core.

> So I don't want to think in terms of linearising trees to strings in
> order to communicate from the stylesheet to extensions, or to other
> documents. If some protocols can only transport strings and not
> structured objects then internally the tree may get linearised
> transported and re-parsed, but that is a feature of that particular
> protocol that I don't need or want to know about that. Either as an XSL
> engine, or a person:-)

It is good to  know that you have found some portable way to pass 
node-sets without linearisation. I think I  don't need to know about 
this protocol, because I don't see too much purpose for it right now.
 
> Your terminoligy is also confusing. You don't want to `typecast'
> strings to node sets. By that I would (and did for several of your
> messages) understand the oposite transformation to the current automatic
> typecast of nodesets to strings, which would be to take a string
> and convert to a node set which consisted of a text node with the value
> being the string. You don't want a typecast, you want a new function
> which is to make an XML parser available from within XSL.

I don't think terminology is confusing.

Rgds.Paul.




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