Re: Future XSLT expansion.

> What should I write if I want to return some 'node-set' from the extension 
> and I want that to be portable across different vendors engines ? 

As you know, you can't.


>  If I'm returning the String from extenstion - I'm fine.
You might be fine (well you almost certainly will be but you can't be
sure)

> Being possible to 
> switch from / to  Xalan from / to  Oracle XSL  from / to XT  should be
> enough.

> Yes, that's a political workaround. Actualy I don't like when some 
> technology is based on a hypotetical agreement between vendors. 

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.

> 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? In that case why not just return the node set
directly, why force the internal tree to be linearised as a string and
> reparsed? 

> 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.
If the extension function is handling trees then it makes far more sense
to pass back a tree (aka node set) than a string. If it is not I don't
see how in general you can convert to a node set.

David


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