This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
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