RE: undefined behavior (was document(a,b) for b not a singleton n ode set)

[Kay Michael <Michael.Kay@xxxxxxx>]

> <rant> Obviously this undefined behaviour is accidental. I think that
> for an empty-node-set second argument to give the same behaviour as no
> second argument, as you mention, is _easily_ the best 
> candidate for what was intended. Undefined behaviour leaves no grounds for
criticizing an
> XSLT processor which adopts _any_ value for the base uri, or which
> always returns an empty node set, or which always signals an 
> error. Can something be done about this?

There are a great many things in the spec that leave behavior undefined,
some of them deliberate and some probably accidental. Other examples:
- the spec doesn't say whether a Processing Instruction in a stylesheet is
an error or should be ignored or is a permitted way of doing vendor
extensions. (Actually it doesn't say anything about comments either, or if
it does I've missed it.)
- the spec doesn't say what should happen if the value passed to xsl:number
(in the value attribute) is negative
- in a numeric sort, the spec doesn't say where NaN values should collate

There are also plenty of ambiguities, where alternative readings are
possible. 

Up until now the editors have been happy to take comments on board and issue
interpretations: see http://lists.w3.org/Archives/Public/xsl-editors/ I hope
this process will continue. But I think the published errata list should be
used only for things that are clear-cut errors, I'm sure they'll resist the
temptation to use it for specification creep.

Mike Kay


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