But thinking about it, perhaps it isn't all that bizarre at all, Andrew ...
consider the following:
<?xml version="1.0" encoding="US-ASCII"?>
'abcdef': <xsl:value-of select="'abcdef' castable as xsd:QName"/>
'abc:def': <xsl:value-of select="'abc:def' castable as xsd:QName"/>
'xsd:def': <xsl:value-of select="'xsd:def' castable as xsd:QName"/>
T:\ftemp>xslt2 ken2.xsl ken2.xsl
The second string being cast above is obliged to return false() because
there is no prefix binding for 'abc'.
Sure, but you don't really need to test if it's castable as xs:QName
as you can tell from static analysis of the stylesheet it will fail.
The more realistic use case is to test an unknown value.
Now consider a string variable: the string is in the lexical space for the
QName, but without an indication of which node to base the value space
evaluation for the given string, it is impossible to create a complete QName
value. And there is no opportunity in the syntax of "castable as" to supply
a second input operand being the context node for the evaluation of the
value-space for the given lexical string.
That's a good point. But would there be any problems if it used in
the in-scope-prefixes of the context node? At least then it can
achieve its main use case. Flatly refusing any string literal means
you can't even work around it by testing the prefix against the
in-scope-prefixes yourself, and then checking the local part is
castable as an xs:QName...
And of course, "silently" returning false like this seems a bit XSLT
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>