W3C home > Mailing lists > Public > public-qt-comments@w3.org > September 2005

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

From: <bugzilla@wiggum.w3.org>
Date: Thu, 29 Sep 2005 10:49:45 +0000
To: public-qt-comments@w3.org
Cc:
Message-Id: <E1EKvyz-0002Fw-AY@wiggum.w3.org>

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


mike@saxonica.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




------- Additional Comments From mike@saxonica.com  2005-09-29 10:49 -------
The Working Groups reviewed this carefully.

Essentially the groups agreed that the solution outlined in my comment #3 works.

Let's reiterate. XPath says:

 "An unknown schema type might be encountered, for example, if a source document
has been validated using a schema that was not imported into the static context.
In this case, an implementation is allowed (but is not required) to provide an
implementation-dependent mechanism for determining whether the unknown schema
type is derived from the expected schema type."

The example here isn't relevant, but the basic situation is the same: there's a
type encountered at run-time (in this case, the type xs:NCName) that isn't in
the static context. In this situation we allow implementations to have some kind
of mechanism for knowing that the "undeclared" type (xs:NCName) is in fact a
subtype of a "declared" type (in this case xs:string); if it has this knowledge
then it can safely treat this value as a string.

Note that this rule is carefully designed to preserve type safety. The
implementation can use any mechanism it likes to "know" that xs:NCName is
derived from xs:string, but its deduction must be correct.

One could argue that this example involves an unknown type at compile time,
rather than at run-time. In XQuery, which does static type analysis across
modules, this would be an issue. However, in XSLT (at least formally) all type
matching is done dynamically. So the dynamic type matching rules cited in XPath
are relevant.

Concrete implementations can handle this in many different ways: the XPath
formulation was deliberately chosen to be very abstract, recognising that
product architectures would be very different here. One implementation might
recognize the type xs:NCName at run-time even though it is not recognized at
compile time. Another implementation might choose to implement the F+O functions
to know that they are running in a basic XSLT environment and simply return a
string rather than an NCName in this situation. Some implementations might have
a run-time representation of the type xs:NCName that's a actually pointer to a
schema components within a data structure that represents the full type hierarchy.

So the resolution is the following addition to XSLT section 21.1:

<new>
For a Basic XSLT Processor, schema built-in types that are not included in the
static context (for example, xs:NCName) are "unknown types" in the sense of
XPath section 2.5.4. In the language of that section, a Basic XSLT Processor
MUST be able to determine whether these unknown types are derived from known
schema types such as xs:string. The purpose of this rule is to ensure that
system functions such as fn:local-name-from-QName(), which is defined to return
an xs:NCName, behave correctly. A stylesheet that uses a Basic XSLT Processor
will not be able to test whether the returned value is an xs:NCName, but it will
be able to use it as if it were an xs:string.
</new>
Received on Thursday, 29 September 2005 10:49:50 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:57:09 UTC