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 following tests: K2-NameTest-30 K2-NameTest-31 K2-InScopePrefixesFunc-25 have an erroneous namespace declaration. For example, consider test K2-NameTest-31: declare namespace a = "http://example.com/1"; declare namespace b = "http://example.com/2"; let $e := <e a:n1="content" b:n1="content"> <a:n1/> <b:n1/> <?n1 ?> <n1/> </e> return $e/a:* The current expected result is: <a:n1 xmlns:b="http://example.com/2" xmlns:a="http://example.com/1"/> However, we think the expected result should be: <a:n1 xmlns:a="http://example.com/1"/> See section 3.7.4 (http://www.w3.org/TR/2009/PER-xquery-20090421/#id-ns-nodes-on-elements). Bullet 1: doesn't apply as <a:n1> has no namespace declaration attributes Bullet 2: doesn't apply as the enclosing <e> has no namespace declaration attributes Bullet 3: "xml" is always added Bullet 4: causes "a" to be added as it is used in the element name of <a:n1>. Therefore, we think the declaration for "b" should not be part of the in-scope namespaces of <a:n1> Note, K2-InScopePrefixesFunc-25 only returns the prefix but the essential problem is the same.
For the <e> element, bullet 4 of 3.7.4 causes the element to have a namespace declaration for b on the grounds that the element has an attribute whose name uses the prefix b. The question is whether the child <a:n1/> element inherits this namespace. Assuming construction mode includes inherit, then if the <a:n1/> were part of an enclosed expression, it would inherit the namespace under 3.7.1.3 clause 1.e.ii.D.II. However, it isn't in an enclosed expression, so it seems namespace inheritance doesn't happen - which means that if the <e> element were returned and serialized, it's <a:n1/> child should in principle contain a namespace undeclaration for b. To me the spec seems wrong. I've never understood why <e><a/></e> is treated differently from <e>{<a/>}</e> from the point of view of namespace inheritance. My memory was that we had fixed this - but I can't see any evidence of it.
This appears to be fixed now.