[XSL-LIST Mailing List Archive Home]
[By Thread]
[By Date]
Michael Ludwig wrote:
Interesting... :)
What you might try is using a "real" node (I mean, an element). Any node is "real" of course, but perhaps Xalan-C (I'm surprised it doesn't show the same behavior as Xalan-J) and LibXslt are more inclined to do the effort to create a new node when the node itself is an element.
One might argue that this is a non-conformance bug, but I vaguely remember having had a discussion along these lines with Michael Kay. The net result of that discussion being that node-set is an extension function and once an extension function (or instruction) is in place, all bets are off considering conformant behavior.
That said, if you state "node-set creates a node or a set of nodes" and "generate-id generates a unique id for each node" would mean, imho, that the mentioned behavior is indeed a bug (though perhaps not strictly non-conforming).
Btw1, what about *not* using node-set? Would generate-id work on the $node variable? Would it work in the same way?
Btw2, does any of these processors have an extension instruction, like Saxon, to create a node from a string representation of XML? if so, would that yield the same erroneous results?
Re: [xsl] current-dateTime()
Subject: Re: [xsl] current-dateTime() From: Abel Braaksma <abel.online@xxxxxxxxx> Date: Fri, 18 Apr 2008 18:29:48 +0200 |
Michael Ludwig wrote:
Abel Braaksma schrieb:Michael Ludwig wrote:That would probably not work. I tested this the other day, just out of curiosity, calling a script that incremented a number, and found that the result was cached when using LibXSLT, Saxon and Xalan.
you forgot to add the generate-id + a newly created node to add to the URI. However, the processors you mention use XSLT 1.0. To get the same behavior in XSLT 1.0 you need to be a little bit more creative and use the extension function exslt:node-set (or equivalent for your processor).
I felt creative enough calling an external script, so I forgot to be more creative :-) Now, following your example: This works for Saxon (both 6.5.5 and 9.0.0.4) and for Xalan-J 2.7.1, but not for Xalan-C 1.10.0 and LibXSLT 1.1.22. The latter do not seem to generate new nodes, so no new IDs are generated either.
Interesting... :)
What you might try is using a "real" node (I mean, an element). Any node is "real" of course, but perhaps Xalan-C (I'm surprised it doesn't show the same behavior as Xalan-J) and LibXslt are more inclined to do the effort to create a new node when the node itself is an element.
One might argue that this is a non-conformance bug, but I vaguely remember having had a discussion along these lines with Michael Kay. The net result of that discussion being that node-set is an extension function and once an extension function (or instruction) is in place, all bets are off considering conformant behavior.
That said, if you state "node-set creates a node or a set of nodes" and "generate-id generates a unique id for each node" would mean, imho, that the mentioned behavior is indeed a bug (though perhaps not strictly non-conforming).
Btw1, what about *not* using node-set? Would generate-id work on the $node variable? Would it work in the same way?
Btw2, does any of these processors have an extension instruction, like Saxon, to create a node from a string representation of XML? if so, would that yield the same erroneous results?
Cheers, -- Abel Braaksma
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] current-dateTime(), Michael Ludwig | Thread | Re: [xsl] current-dateTime(), Michael Ludwig |
Re: [xsl] current-dateTime(), Dimitre Novatchev | Date | [xsl] Non-English languages in XSLT, Ramkumar Menon |
Month |
Keywords