3808 2006-10-05 23:22:46 +0000 Constr-namespace-13.xml seems to missing namespace undeclaration 2007-01-11 23:59:41 +0000 1 1 1 Unclassified XML Query Test Suite XML Query Test Suite unspecified PC Linux CLOSED INVALID P2 normal --- 1 per andrew.eisenberg public-qt-comments oldest_to_newest 12326 0 per 2006-10-05 23:22:46 +0000 Test Constr-namespace-13 results in either err:XQST0085 if XML Names 1.1 is not supported or Constr-namespace-13.xml is XML Names 1.1 is supported. The latter file consists of: <foo:elem xmlns:foo="http://www.example.com/parent"><child/></foo:elem> Shouldn't the child include the namespace unclaratation attribute as in: <foo:elem xmlns:foo="http://www.example.com/parent"><child xmlns:foo=""/></foo:elem> I'm not sure if this is required by a literal reading of the Spec, but it seems implied by "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". This does lead to the question of the behavior of fn:in-scope-prefixes and fn:namespace-uri-for-prefix for the child node. I would assume the former should return ("foo", "xml") and the latter should map "foo" to "". 13453 1 andrew.eisenberg 2007-01-11 20:10:12 +0000 I interpret our specifications differently than you have, Per. The first bullet of section 3.7.1.2, Namespace Declaration Attributes, says: "If the namespace URI is a zero-length string and the implementation supports [XML Names 1.1], any existing namespace binding for the given prefix is removed from the in-scope namespaces of the constructed element and from the statically known namespaces of the constructor expression." So, if XML Names 1.1 is supported, then foo:elem contains a binding for foo and child does not contain a binding for foo. In section C.3, Serialization Parameters, XQuery says that the value of the undeclare-prefixes serialization parameters is "no". In section 5.1.7, XML Output Method: the undeclare-prefixes Parameter, of Serialization, we say: "If the undeclare-prefixes parameter has the value no and the output method is XML or XHTML, then the undeclaration of prefixes MUST NOT occur." For these reasons, I believe that the test case result is correct. Please close this bug report if you agree with this resolution. 13456 2 per 2007-01-11 22:23:22 +0000 I buy your logic. The problem is: why is Constr-namespace-13 different from Constr-namespace-22, whose result contains <child xmlns=""/> ? The test results Constr-inscope-10.xml and Constr-inscope-12.xml also contain undeclare attributes. 13457 3 davidc 2007-01-11 22:34:20 +0000 (In reply to comment #2) > I buy your logic. The problem is: why is Constr-namespace-13 different from > Constr-namespace-22, whose result contains <child xmlns=""/> ? > > The test results Constr-inscope-10.xml and Constr-inscope-12.xml also contain > undeclare attributes. > that's different as xmlns="" is legal Namespace 1.0 syntax and is therefore required to be supported, it's just undeclaration of prefixes that was added in namespaces 1.1 David 13458 4 per 2007-01-11 22:53:53 +0000 (In reply to comment #3) > that's different as xmlns="" is legal Namespace 1.0 syntax and is therefore > required to be supported, it's just undeclaration of prefixes that was added in > namespaces 1.1 I didn't realize that. Thanks for the explanation. 13461 5 mike 2007-01-11 23:59:41 +0000 >why is Constr-namespace-13 different from Constr-namespace-22, whose result contains <child xmlns=""/> ? Because undeclaring of the default namespace is possible in XML 1.0, and therefore happens whether or not you enable undeclare-prefixes in the serializer. We've made the assumption that undeclaring of non-default prefixes is something that should only happen if you really need it, it shouldn't happen by accident because for most people it's just unnecessary clutter. (Apart from the history, there's also a semantic difference between xmlns="" and xmlns:p="". Writing xmlns="" doesn't just undeclare the binding of prefix "" to some namespace, it also establishes a new binding of prefix "" to the non-namespace. So it has a positive effect, not just a negative effect. By contrast, the only real effect of writing xmlns:p="" is to make any reference to p an error.)