Re: [xsl] current-dateTime()

[Michael Ludwig <mlu@xxxxxxxxxxxxx>]

Abel Braaksma schrieb:
> Michael Ludwig wrote:
> > 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.

Can't find them more inclined to do the effort, neither using a literal
element nor an xsl:element instruction, neither using LibXSLT nor
Xalan-C.

Judging from the version history, it seems Xalan-J and Xalan-C do not
correspond one-to-one. As of now, it's 2.7.1 for Java and 1.10 for C++.
Xalan-C seems to have started in 1999 with the intention to provide a
faster Xalan implementation less demanding in terms of CPU and memory
consumption. They don't seem to have marched in parallel.

> 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).

Maybe the non-conforming processors think on the second iteration
that the new node from the first iteration is gone forever, so being
economical with IDs in face of the upcoming global ID scarcity, they
deem environmentally appropriate to reassign the same ID.

> Btw1, what about *not* using node-set? Would generate-id work on the
> $node variable? Would it work in the same way?

All four XSLT 1.0 processors agree an RTF is not an acceptable argument
for generate-id(). Saxon 9.0.0.4 doesn't care, probably for the reasons
given by Michael Kay here:

http://www.biglist.com/lists/lists.mulberrytech.com/xsl-list/archives/200804/msg00203.html
http://www.biglist.com/lists/lists.mulberrytech.com/xsl-list/archives/200804/msg00207.html

> 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?

I don't know. What's that Saxon instruction called?

Michael