This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The description in 3.7.4 In-scope Namespaces of a Constructed Element looks buggy. The following paragraph should be made conditional on copy-namespaces mode. A namespace binding is created for each namespace that is declared in a namespace declaration attribute of an enclosing direct element constructor and not overridden by the current element constructor or an intermediate constructor. The revised sentence reads as follows: If copy-namespaces mode specifies preserve, a namespace binding is created for each namespace that is declared in a namespace declaration attribute of an enclosing direct element constructor and not overridden by the current element constructor or an intermediate constructor. The following note is no longer true, and should be removed. Note: Copy-namespaces mode does not affect the namespace bindings of a newly constructed element node. It applies only to existing nodes that are copied by a constructor expression.
This is not a bug fix: the spec as written is consistent, and is the way it is by design, not by accident. Hence the note which you cite, which is there to emphasize that it is intentional that copy-namespaces only affects copied elements and not constructed elements. The effect of your change would be that with copy-namespaces=no, the query <a xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xs="http://www.w3.org/2001/XMLSchema> <p xsi:type="xs:decimal">3.14156</p> </a> will produce the result <a xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" <p xsi:type="xs:decimal">3.14156</p> </a> which people didn't think was a good idea. Why would the user declare the namespace if they didn't want it included in the result? Michael Kay
Let me check my understanding with a few queries. Example 1: <e1 xmlns:p="abc">{<e2/>}</e1>//e2 When <e2/> is constructed, the rules of 3.7.4 apply, so <e2/> does indeed inherit the namespaces of the enclosing element constructors. When <e2/> is copied into <e1/>, the rules of 3.7.1.3 apply, so these namespaces are preserved. So the result of the above query is: <e2 xmls:p="abc"/> Example 2: declare copy-namespaces preserve,no-inherit; let $e := <e/> return <ee xmlns:p="abc"><e/>{$e, <e/>}</ee>//* In the let clause, there is no enclosing element constructor, so the element does not inherit the xmlns:p binding. The other two do. So the result is: <e xmlns:p="abc"/> <e/> <e xmlns:p="abc"/> Does that match your understanding? Namespaces are way too complicated in XQuery - this is mostly a problem for the implementor, rather than the user, but it definitely makes the language more complex... Jonathan
I think both your examples are correct: though example 2 depends on how one reads the serialization spec as well as the XQuery spec. "Namespaces are way too complicated in XQuery". True. But sadly, they still aren't complicated enough to meet all requirements. For example there is currently no way of copying namespaces from the source document to the result document except when making an exact copy of the containing element. So if you want to transform a schema into an equivalent schema that drops all the <xs:annotation>s, you're stuck. What we have may be complicated, but it's all driven by real use cases. Michael Kay
After discussion in the Query working group meeting on May 4, 2005, the originator agreed that this comment can be closed with no action.