This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
(From a comment by Christian Grün <christian.gruen@gmail.com> on the saxon-help list). Consider element e { namespace {''} {'u'} } The rules say that (a) the name of the element is Q{}e (b) the element has a namespace binding (""=>"u") This would violate a consistency constraint in the data model (section 6.2.1 rule 12). Possibilities are: (1) change the name of the element to Q{u}e (2) don't add the namespace binding to the element node (3) raise a dynamic error XSLT chooses (3). Specifically [ERR XTDE0440] It is a non-recoverable dynamic error if the result sequence contains a namespace node with no name and the element node being constructed has a null namespace URI (that is, it is an error to define a default namespace when the element is in no namespace). Christian was expecting (1).
I have added test case nscons-042 to test this situation.
Reclassifying as XQuery. Previously misclassified.
The Working Group has decided to raise a dynamic error for this case.
The error code for this will be XQDY0102.
Can I make this error more specific? Does the following text cover this case? I find it more readable: It is an error to define a default namespace for an element if the element's name is in no namespace <errorref class="DY" code="0102"/>. For instance, the following computed constructor raises an error because the element's name is not in a namespace, but a default namespace is defined. <eg role="parse-test">element e { namespace {''} {'u'} }</eg>
It's more readable, but is the term "to define a default namespace for an element" clear? You've basically taken the informal readable description of the error condition in XSLT in preference to the more formal and accurate one. In XSLT there are several ways a namespace node can find its way into the content sequence for an element constructor; in XQuery there is only one way, namely the use of a namespace constructor. So I agree the XQuery case is a little simpler. But I don't think I would understand "define a default namespace" as used here, except by reference to the example, and it's not good if the spec can only be understood by reference to examples.
How about this: If the name of an element in a computed element constructor is in no namespace, creating a default namespace for that element using a computed namespace constructor is an error <errorref class="DY" code="0102"/>. For instance, the following computed constructor raises an error because the element's name is not in a namespace, but a default namespace is defined. <eg role="parse-test">element e { namespace {''} {'u'} }</eg>
Much better, but doesn't the rule apply equally to a direct element constructor?
(In reply to comment #8) > Much better, but doesn't the rule apply equally to a direct element > constructor? Hmmmphhh, yes it does. If the name of an element in an element constructor is in no namespace, creating a default namespace for that element using a computed namespace constructor is an error <errorref class="DY" code="0102"/>. For instance, the following computed constructor raises an error because the element's name is not in a namespace, but a default namespace is defined. <eg role="parse-test">element e { namespace {''} {'u'} }</eg> [reply] [-] Comment 8