Bug 15675 - [XQ30] Computed Namespace Constructors
Summary: [XQ30] Computed Namespace Constructors
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XQuery 3.0 (show other bugs)
Version: Member-only Editors Drafts
Hardware: PC Windows NT
: P2 normal
Target Milestone: ---
Assignee: Jonathan Robie
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL: https://www.w3.org/XML/Group/qtspecs/...
Depends on:
Reported: 2012-01-23 13:52 UTC by Tim Mills
Modified: 2012-10-02 19:45 UTC (History)
1 user (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Tim Mills 2012-01-23 13:52:02 UTC
XSLT prevents computed namespace node from having namespace URIs outside the lexical space of xs:anyURI.  (see http://www.w3.org/XML/2007/qt-errata/xslt-errata.html#E6)

[ERR XTDE0905] It is a non-recoverable dynamic error if the string value of the new namespace node is not valid in the lexical space of the data type xs:anyURI. [see ERR XTDE0835]

XQuery 3.0 does not.  Is this an intentional difference?
Comment 1 Michael Kay 2012-01-23 21:34:08 UTC
I believe it is intentional, though I would have trouble proving it: the history is long and tortuous.

Note that in XSD 1.1 the lexical space of xs:anyURI is the set of all strings of XML characters, so the question becomes (in the American parlance) moot.

At the heart of the problem is that the namespaces recommendation (deliberately, I understand) does not make it a well-formedness error if a namespace name is not a valid URI (or IRI, in the case of the 1.1 specification). There is clearly an intent and desire that namespace names should be URIs/IRIs, but there is no error defined if they are not. 

This point can itself be disputed. The rules for conformance of documents to the Namespaces spec are circular: Section 7, Conformance of documents, says "A document is namespace-well-formed if it conforms to this specification". 

Section 8, on conformance of processors, says "a processor must report violations of namespace well-formedness, with the exception that it is not required to check that namespace names are legal IRIs." which suggests that documents using illegal IRIs are NOT namespace well-formed; but it is explicit that the parser isn't required to reject such documents, and if the XML parser isn't going to reject them then it doesn't make much sense for downstream software to reject them.

So I think all of our specs have moved in the direction of removing any requirement that namespace names be valid IRIs.
Comment 2 Tim Mills 2012-01-24 09:53:27 UTC
Doesn't this then mean that the following text from 2.4.5 URI Literals is now redundant?

"However, an implementation may raise a static error [err:XQST0046] if the value of a URILiteral is of nonzero length and is not in the lexical space of xs:anyURI."

Comment 3 Michael Kay 2012-01-24 10:04:17 UTC
The sentence becomes redundant once we move firmly to XSD 1.1.: or at any rate, it needs changing.

Note that the contents of a URILiteral do not always represent a namespace. If the URILiteral is a relative URI, in some contexts for example a collation URI, then it needs to be resolved against a base URI, and in these cases I think there is still an error condition if the value is neither an absolute URI nor a relative URI: but it's no longer appropriate to define this error by reference to the xs:anyURI data type.
Comment 4 Tim Mills 2012-01-24 10:27:24 UTC
Indded, but for implementations following the XSD 1.0 definition, in this one place in the specification the check being made everywhere else has been dropped.

I'd like to see XQuery follow XSLT 2.0 on this, with an error which the implementation MAY raise.  Of course, an implementation following XSD 1.1 on this would never have cause to raise such an exception.
Comment 5 Jonathan Robie 2012-02-14 13:06:58 UTC
The Working Group has decided to resolve this by endorsing comment #3. We want interoperability, and prefer not to allow some implementations to raise an error that others would not in this context.
Comment 6 Tim Mills 2012-07-23 16:07:49 UTC
I've reopening this bug in light of the expected changes regarding XQST0046.

If an implementation is at liberty to prevent use of a braced URI literal because it doesn't match RFCxxxx, then it should be possible to prevent creation of namespace URIs of this form.
Comment 7 Tim Mills 2012-09-25 17:12:01 UTC
Here's a summary of the inconsistency which is currently in the specification.

If X is an invalid URI then at the moment:

element Q{X} { } <-- MAY RAISE XQST0046
namespace "foo" { "X" } <-- NEVER RAISES AN ERROR
Comment 8 Jonathan Robie 2012-10-02 19:45:19 UTC
(In reply to comment #7)
> Here's a summary of the inconsistency which is currently in the specification.
> If X is an invalid URI then at the moment:
> element Q{X} { } <-- MAY RAISE XQST0046
> namespace "foo" { "X" } <-- NEVER RAISES AN ERROR

In today's telcon, we agreed to allow implementations to raise an error for computed namespace constructors, but not the same error used for URI literals.

This error will be a dynamic error, defined in terms of xs:anyURI.