This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 29081 - [xslt 3.0] Use of reserved namespaces in extensions
Summary: [xslt 3.0] Use of reserved namespaces in extensions
Status: CLOSED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XSLT 3.0 (show other bugs)
Version: Last Call drafts
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Michael Kay
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-08-24 20:06 UTC by Michael Kay
Modified: 2015-10-29 12:42 UTC (History)
0 users

See Also:


Attachments

Description Michael Kay 2015-08-24 20:06:51 UTC
Tests maps-901a to maps-901e assume that a processor is required to reject calls on the map:new() function.

Now, as it happens, current Saxon releases support this function in order to ease transition from earlier working drafts.

The question therefore arises whether this is non-conformant.

If the function is allowed at all, then it is an extension function, and the question is whether extension functions are permitted in a reserved namespace.

Section 5.1.3 on reserved namespaces says that they can be used for some purposes (names of literal result elements and attributes) and not others (names of stylesheet-defined variables and functions). Extension functions are not mentioned.

Do we want to disallow use of reserved namespaces in the names of extension functions (and presumably extension elements?) If so, we should say so, otherwise we need to remove these tests.

Allowing extension functions in these namespaces allows vendors to implement a function defined in one version of the W3C specs in a processor that aims for conformance with a different version. This can help interoperability in some ways, and hinder it in others, so the right answer is not obvious.
Comment 1 Michael Kay 2015-09-03 22:00:46 UTC
The WG was minded to impose the rule that extensions must not use reserved namespaces.

The following wording is proposed:

(a) In 5.1.3 change the sentence

Reserved namespaces must not be used, however, in the names of stylesheet-defined objects such as variables and stylesheet functions.

to

Reserved namespaces must not be used, however, in the names of stylesheet-defined objects such as variables and stylesheet functions, nor in the names of extension functions or extension instructions.

(b) In 5.1.3 add:

It is not an error to use a reserved namespace in the name of an extension attribute: attributes such as <code>xml:space</code> and <code>xsi:type</code> fall into this category. XSLT processors MUST NOT reject such attributes, and MUST NOT attach any meaning to them other than any meaning defined by the relevant specification.

(c) Add the error:

[ERR XTSE0085] It is a static error to use a reserved namespace in the name of any extension function or extension instruction, other than a function or instruction defined in this specification or in a normatively referenced specification. It is a static error to use a prefix bound to a reserved namespace in the [xsl:]extension-element-prefixes attribute.

(d) In 24.1 Extension Functions

after the sentence "The set of functions that can be called from a FunctionCallXP30 within an XPath expression may include one or more extension functions. The expanded QName of an extension function always has a non-null namespace URI."

add ", which MUST NOT be the URI of a reserved namespace."

(e) 24.2.1 Designating an Extension Namespace

add "A reserved namespace cannot be designated as an extension namespace: see [ERR XTSE0085]"

(f) Add to the incompatibilities appendix: "XSLT 3.0 reserves certain namespaces for use as defined in this or related specifications."
Comment 2 Michael Kay 2015-09-12 22:35:06 UTC
The change was accepted and has been applied to the spec.