Re: Future XSLT expansion.

> Even if teh API's for extensions were brought into line, it won't ever
> be really convenient to do this unless the extensions are all in the
> same namespace which means either an agreement between implementors
> (short term) or an official w3c extension namespace.

That is changing the stylesheet. That is easy ( of course, I would be 
happy if  vendors will agree on a common namespace, but if not - 
changing a few lines in the stylesheet header is not a big deal).

Changing the Java code of extension is much harder.
 
> > Returning Strings and allowing the typecast from Strings to node-sets
> > is better.

> ?? How in general would you get from a string to a node set?
> Parse it as XML? 

Exactly like document() hack works. It is turning text into node-set.
Why the same could not be done with just the text ( String ) ?

> In that case why not just return the node set
> directly, why force the internal tree to be linearised as a string and
> > reparsed? 

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. 

> > At that point it would be better to have to-node-set 
> > typecast  in the core.
> 
> You obviously have something in mind since youve posted so many messages
> in this thread all asking for the same thing, but I don't see it.

I have the same thing in mind right from the beginning. That's not my 
problem than instead of reading my letters I was bashed as a 
student, who has to read XPath specifation, address everything in this 
world with URIs and ignore  the ( de-facto existing ) node-set() typecast.  

I had to repeat my explanations.  ( and I still have to, because all the 
arguments for to-node-set() typecast are already in the thread in 
my first or second letter ).

> If the extension function is handling trees then it makes far more sense
> to pass back a tree (aka node set) than a string. 

Yes. So instead of introducing to-node-set typecast into the core you 
suggest:

a. Add one more 'hidden'  typecast ( variable -> node-set ).
b. Ask all vendors to use a common NodeSet class 
( 'political' typecast ).

That could be done ( but that's solving one particular problem 
after another, and still gives no way to capture the external 
text with the help of 'correct' document() ). 

I need to review some other places in the specs - 
there could be some more problems with missing typecast.
When system has some non-obvious datatypes and the typecast 
from/to core datatype is missing in the system - the system 
should have some more problems with that.

to-node-set typecast() still will be more scalable, 
because it at least gives some chance to use C 
extension ( returning String ) with Java XSTL engine.

> If it is not I don't see how in general you can convert to a node set.

Exactly like document() works ( because the real semantics 
of document() is to convert some text to node-set ).

Rgds.Paul.



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