Re: [xsl] are all strings in a sequence valid potential QNames

Subject: Re: [xsl] are all strings in a sequence valid potential QNames
From: "G. Ken Holman" <gkholman@xxxxxxxxxxxxxxxxxxxx>
Date: Thu, 04 Feb 2010 11:41:08 +0100
At 2010-02-04 10:24 +0000, Andrew Welch wrote:
On 4 February 2010 09:53, G. Ken Holman <gkholman@xxxxxxxxxxxxxxxxxxxx> wrote:
> At 2010-02-04 09:45 +0000, Andrew Welch wrote:
>> Doesn't that restriction then make "castable as xs:QName" pretty
>> useless? I can't see when you would need it...
> I think many specifications end up with useless vestiges resulting from the
> product of two concepts where most of the combinations make sense but the
> odd one here or there end up not being very useful. On the left operand you
> have all of the different operands of literals and values, and on the right
> operand you have all of the different types, and that produces a myriad of
> combinations that need to be considered and implemented.

Without the restriction it's definitely useful, and intuitive :)
...but with the odd requirement that it will return false unless it's
given a hard-coded string, then it is a really subtle and annoying
gotcha... I'm sure one that's got me in the past.

But thinking about it, perhaps it isn't all that bizarre at all, Andrew ... consider the following:

T:\ftemp>type ken2.xsl
<?xml version="1.0" encoding="US-ASCII"?>
<xsl:stylesheet xmlns:xsl="";

<xsl:output method="text"/>

<xsl:template match="/">
'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

'abcdef':   true
'abc:def':  false
'xsd:def':  true

The second string being cast above is obliged to return false() because there is no prefix binding for 'abc'.

Remember that QNames have a different value space from the lexical space. The lexical space is the prefix and local name but the value space is the URI and the local name.

In my illustration above, the first and third literal strings can be converted to QNames because the lack of prefix and the prefix are both acceptable in generating the URI for the value space for the casted value. But the second literal string is obliged to return false because there is no bound URI with which to satisfy the value space.

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.

So the restriction is not in any way artificial.

I hope this is considered helpful and not pedantic.

. . . . . . . . . . . . . Ken

XSLT/XQuery/XPath training after 2010-03-15/19
XSLT/XQuery/XPath training:   San Carlos, California 2010-04-26/30
Vote for your XML training:
Crane Softwrights Ltd.
Training tools: Comprehensive interactive XSLT/XPath 1.0/2.0 video
Video lesson:
Video overview:
G. Ken Holman                 mailto:gkholman@xxxxxxxxxxxxxxxxxxxx
Male Cancer Awareness Nov'07
Legal business disclaimers:

Current Thread