Re: Future XSLT expansion.

Subject: Re: Future XSLT expansion.
From: David Carlisle <davidc@xxxxxxxxx>
Date: Tue, 21 Mar 2000 00:10:21 GMT
> Changing the Java code of extension is much harder.
no disagreement there.

> Exactly like document() hack works. It is turning text into node-set.
No actually, it is returning an XML tree (node-set) as a result of
passing a URI to a server. There never need have been a linearised form
of the document returned, it could be the result of a database query.
Or the parsing of some other syntax than XML that has a SAX parser.
> Why the same could not be done with just the text ( String ) ?
Actually a string-parse() function that took a string and returned
a node set might be useful in a few special cases, but I wouldn't
like to see that all interfacing to external documents and extension
functions went through such an interface, that would appear to
lose  far too much functionality.

> To have it portable means vendors should agree on the 
> common NodeSet  class. That is possible, but that  is harder 
> than placing to-node-set( String ) into the core. 

even if you had a function converting strings to node sets, you'd still
want the common API for node set expressions, otherwise what would you
do with _arguments_ to the extension function that were node sets,
surely you don't want to linearise them do you?

> I was bashed as a 
not by me, I think

> a. Add one more 'hidden'  typecast ( variable -> node-set ).
that isn't a typecast it is simply using variable of the type node-set.

> b. Ask all vendors to use a common NodeSet class 
> ( 'political' typecast ).
I can only ask. W3C if specifying XSLT n+1 could mandate.

> after another, and still gives no way to capture the external 
> text with the help of 'correct' document() ). 

The two issues are quite distinct. You still want the API for node set
(and other types) in extension functions even if you had a version of
document that returned a string (or a text node). Actually you could
import non XML text files now given a suitable server that served them
as a text node, but as noted in the spec more convenient ways would be


 XSL-List info and archive:

Current Thread