This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Section 3.13 allows an implementation to add additional types to the context. But it does not provide a means to detect that this has been done. Without this rule, an implementation can detect whether int (for instance) is a valid atomic type in an XPath expression, by checking the value of the system-property xsl:is-schema-aware, and can take appropriate action. With this rule in place, that can no longer be done, unless the implementation ALWAYS adds these types (in which case a combination of the xsl:vendor, xsl:product-name and xsl:product-version is sufficient for the stylesheet author) Suggestion: Require an implementation that adds some of these types to provide a system-property to detect that they have been added, unless the implementation always adds these properties.
The Working Group discussed this on 14 June 2006 and decided to add a new interrogative function. Colin, could you please confirm that this is an acceptable resolution. The function will appear in a new section 18.1.4 as follows: 18.1.1 Testing Availability of Types The type-available function can be used, for example with the [xsl:]use-when attribute (see 3.12 Conditional Element Inclusion), to explicitly control how a stylesheet behaves if a particular schema type is not available in the static context. type-available($type-name as xs:string) as xs:boolean A schema type (that is, a simple type or a complex type) is said to be available within an XPath expression if it is a type definition that is present in the in-scope schema componentsXP for that expression (see 5.4.1 Initializing the Static Context). This includes built-in types, types imported using <elcode>xsl:import-schema</elcode>, and extension types defined by the implementation. The value of the $type-name argument must be a string containing a lexical QName. The lexical QName is expanded into an expanded-QName using the namespace declarations in scope for the expression. If the lexical QName is unprefixed, then the default namespace is used in the expanded QName. The function returns true if and only if there is an available type whose name matches the value of the $type-name argument. [ERR XTDE1425] It is a non-recoverable dynamic error if the argument does not evaluate to a string that is a valid QName, or if there is no namespace declaration in scope for the prefix of the QName. If the processor is able to detect the error statically (for example, when the argument is supplied as a string literal), then the processor may optionally signal this as a static error.
This is acceptable. N.B. The list of functions usable with [xsl:]use-when will also need updating.
Thanks for the reminder - I missed that one! Mike
Unfortunately the error code allocated in the resolution of this bug was also assigned in the resolution of bug #3608. It is therefore proposed to change the error code in section 18.1.4 to XTDE1428.
The change proposed in comment #4 was accepted as an emergency fix before publication of the Proposed Recommendation (it was needed to make the document pass validity checking against the DTD). The bug report can therefore now be closed.