RE: Resoultion of Bug 1824: Functions return xs:NCName, but xs:NCName is not support in XSLT 2.0 Basic

> 
> If I understand this correctly, then code such as the following:
> 
> 
>         <xsl:variable name="element_name" select="../@name"
>         as="xs:TOKEN" />
> 
> should not be rejected by a Basic XSLT processor, but should be
> treated as if it were coded as:
> 
>         <xsl:variable name="element_name" select="../@name"
>         as="xs:string" />
> 
> Is this a correct understanding?

No, this is incorrect. xs:TOKEN is not one of the types in the static
context, therefore its name isn't available for use in the stylesheet. The
effect is the same as saying as="dvla:vehicle-reg" when you haven't imported
a schema for "dvla". Similarly if you ask

<xsl:if test="local-name-from-QName(node-name(.)) instance of xs:NCName">

you'll get a static error with a basic processor. The only thing you can
test for, and depend on, is

<xsl:if test="local-name-from-QName(node-name(.)) instance of xs:string">

because xs:string is the nearest "known" type. This code will work, and give
the same answer, with both a basic processor and a schema-aware processor.
When I mentioned in the bugzilla entry that the solution is type-safe, one
of the properties of this is that any expression that's legal in a basic
XSLT processor will give the same answer as the same expression in a
schema-aware processor. This works because we've carefully avoided any
function such as get-type() that returns the most specific type of a value:
you can only do tests to determine whether the value is an instance of a
type that's in your static context.

I hope this clarifies.

Michael Kay