[Bug 1824] Functions return xs:NCName, but xs:NCName is not support in XSLT 2.0 Basic

http://www.w3.org/Bugs/Public/show_bug.cgi?id=1824


mike@saxonica.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Functions return xs:NCName, |Functions return xs:NCName,
                   |but xs:NCName is not support|but xs:NCName is not support
                   |in XSLT 2.0 Basic           |in XSLT 2.0 Basic




------- Additional Comments From mike@saxonica.com  2005-07-28 19:05 -------
This one is going to be a bit tricky. As it happens, it arrived just before an
XSL WG telcon and we had time for a bit of preliminary discussion.

At one time the set of types supported by a basic XSLT processor was chosen to
align with the set of types used in the signatures of F+O functions. This
alignment broke when two functions were changed to return an NCName. On the face
of it there are three solutions possible:

(a) change the functions back to returning strings (there are other functions
that create a precedent for this)

(b) change XSLT to allow xs:NCName in its set of supported types (together,
presumably with its supertypes xs:Name, xs:token, and xs:normalizedString)

(c) finesse the definition of a basic XSLT processor so that if it calls a
function that returns a value of a type that's a subtype of a recognized type,
the value is in effect promoted to the nearest recognised type. Section 2.5 of
XPath is carefully crafted to recognize the possibility of input values having a
dynamic type that not one of the statically known types, but is a subtype
thereof, and we could build on this capability.

We'll need joint meeting time with XQuery to discuss this one, which means it
won't be addressed for a month or so as there's a break in the meeting schedule.

Michael Kay (personal response)

Received on Thursday, 28 July 2005 19:05:55 UTC