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

Subject: Re: [xsl] are all strings in a sequence valid potential QNames
From: Andrew Welch <andrew.j.welch@xxxxxxxxx>
Date: Fri, 5 Feb 2010 09:26:31 +0000
>> However, it's not possible because of the (imho) unnecessary
>> restriction in the spec, so you are forced to fall back to a regex
>> based solution.
>> Currently even NCNames fail the castable xs:QName test, which has to be
>> wrong.
> Note that I included an NCName literal string in my illustration and it
> passed ... or are you referring to a string with an NCName value?  A string
> with an NCName value would still be based on the default namespace of the
> unspecified node for context.  In my illustration the default namespace was
> effectively null since there was no default namespace declaration.

The problem I have with it is that currently you can't test any
values, at all.  For example, given "foo:bar" (value, not literal) you
can't tokenize it and test the prefix against the in-scope-prefixes
and then check the local part is castable as xs:QName....  which would
be a reasonable work around.  I can't see why checking an NCName value
should always return false?

>> Hopefully this could be looked at for 2.1...?
> What would be the details of your proposal for a change?  Would simply
> the context node (and an error if the context item isn't a node) be enough?

I would think either allowing values that are NCNames, so the
workaround can be done, or if it's considered better to leave
everything as it is, then add a new function such as fn:is-QName(name
as xs:string, context as node())

Andrew Welch

Current Thread