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 section 1.1: [Definition: The implied namespace binding of a QName is the association of its namespace prefix (or absence thereof) with its namespace URI (or absence thereof).] [Definition: Two namespace bindings are said to conflict if their namespace prefixes (or absence thereof) are the same but their namespace URI's (or absence thereof) are different.] Now, consider section 2.4.1 bullet 3. b. which indicates XUDY0023 should be thrown when an attribute to be inserted has a QName with an implied namespace binding that conflicts with a namespace binding in the namespaces property of $target. This seems wrong if you consider attributes with no prefix. An attribute name without a prefix should not conflict with the default element/type namespace. For example, assume we have the default element/type namespace ""="my_default_uri" defined in the namespaces property of some element. Now, consider what happens when we insert an attribute with the implied namespace binding ""="". According to the definition, it seems these conflict but they should not in this case.
I think you're right. An unprefixed attribute does not (should not) imply the namespace binding ""="". For attributes, no prefix means no namespace, and no namespace binding is needed to establish this; there is no conflict between an unprefixed attribute on an element, and a namespace binding such as ""="abc.uri" on the same element.
We believe you are correct - I will produce text to fix this here in this bug report.
(In reply to comment #2) > We believe you are correct - I will produce text to fix this here in this bug > report. I suggest we fix this by explicitly stating the exception for an attribute with no namespace prefix in the three places where this problem occurs. 2.4.1 Insert Bullet 3.b. No attribute node in $alist may have a QName whose implied namespace binding conflicts with a namespace binding in the "namespaces" property of $target [err:XUDY0023] <new>unless the namespace prefix for the attribute is absent</new>. Bullet 4.b. No attribute node in $alist may have a QName whose implied namespace binding conflicts with a namespace binding in the "namespaces" property of $target [err:XUDY0023] <new>unless the namespace prefix for the attribute is absent</new>. 2.4.3.1 Replacing a Node Bullet 4.b. No attribute node in $rlist may have a QName whose implied namespace binding conflicts with a namespace binding in the "namespaces" property of $parent [err:XUDY0023] <new>unless the namespace prefix for the attribute is absent</new>.
The WG accepted the solution in comment #3 in today's call.
I've added XQUTS test case id-insert-expr-094 as a result of this resolution.
Going this route, I think you would also need to make a change for 3.2.1 upd:mergeUpdates (2) f. and 3.2.2 upd:applyUpdates (1) f. It seems, for example, that upd:insertAttributes could inappropriately create a conflict with upd:rename. Here is a slightly different route you may have already considered. First, add two new definitions: [Definition: The implied namespace binding of a QName is the association of its namespace prefix (or absence thereof) with its namespace URI (or absence thereof).] <new> [Definition: The implied namespace binding of an element is the implied binding of its name. ] [Definition: The implied namespace binding of an attribute is the implied binding of its name unless the name has no prefix in which case the attribute does not have an implied binding. ] </new> Delete "QName of" text in the appropriate places. For example: 2.4.1 Insert (3) b. <old>No attribute node in $alist may have a QName whose implied namespace binding conflicts with a ...</old> <new>No attribute node in $alist may have an implied namespace binding that conflicts with a ...</new> (4) b (same) 2.4.3.1 Replacing a Node Bullet 4.b. <old>No attribute node in $rlist may have a QName whose implied namespace binding conflicts with a ...</old> <new>No attribute node in $rlist may have an implied namespace binding that conflicts with a ...</new> In my opinion, this solution is cleaner because it is more up front about the nature of conflicting implied bindings and it also eliminates the need for the special cases. Sorry in advance if I am missing something.
This comment is editorial, and we'll take your suggestions under consideration.
I decided to fix this by adding the following text to the definition of an implied namespace binding, in addition to taking the approach shown in comment #3: Definition: The implied namespace binding of a QName is the association of its namespace prefix (or absence thereof) with its namespace URI (or absence thereof).] [Definition: Two namespace bindings are said to conflict if their namespace prefixes (or absence thereof) are the same but their namespace URI's (or absence thereof) are different.] Update operations that result in conflicting namespace bindings generally raise errors, as described in this document. <add>However, if the namespace prefix of an attribute is absent, it is in no namespace, and an update operation can create such an attribute in an element even though its implied namespace binding conflicts with a namespace binding in the "namespaces" property of the element.</add>
This feels nearly right.... But I'm not sure the reader will spot the subtle difference between "implied namespace binding" in the first sentence, and "namespace binding" in the second. A QName has an implied namespace binding, and except in the case of a namespace binding ("", ?), the implied namespace binding of a QName used as an attribute or element name will become an (actual) namespace binding of the element, and a conflict between the (actual) namespace bindings of an element is ALWAYS (not "generally", unless you mean the term very pedantically) an error. The reason that the unprefixed attribute case doesn't cause an error is that the implied namespace binding of the attribute doesn't turn into an actual namespace binding on the element.
(In reply to comment #9) I agree. I changed the text to: However, if the namespace prefix of an attribute is absent, it is in no namespace, and its implied namespace binding is not added to the namespace bindings of its parent element. Therefore, an update operation can create such an attribute in an element even though its implied namespace binding conflicts with a namespace binding in the "namespaces" property of the element.