This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 3808 - Constr-namespace-13.xml seems to missing namespace undeclaration
Summary: Constr-namespace-13.xml seems to missing namespace undeclaration
Status: CLOSED INVALID
Alias: None
Product: XML Query Test Suite
Classification: Unclassified
Component: XML Query Test Suite (show other bugs)
Version: unspecified
Hardware: PC Linux
: P2 normal
Target Milestone: ---
Assignee: Andrew Eisenberg
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-10-05 23:22 UTC by Per Bothner
Modified: 2007-01-11 23:59 UTC (History)
0 users

See Also:


Attachments

Description Per Bothner 2006-10-05 23:22:46 UTC
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 "".
Comment 1 Andrew Eisenberg 2007-01-11 20:10:12 UTC
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.
Comment 2 Per Bothner 2007-01-11 22:23:22 UTC
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.
Comment 3 David Carlisle 2007-01-11 22:34:20 UTC
(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
Comment 4 Per Bothner 2007-01-11 22:53:53 UTC
(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.
Comment 5 Michael Kay 2007-01-11 23:59:41 UTC
>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.)