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 22334 - Expected results have an erroneous namespace declaration
Summary: Expected results have an erroneous namespace declaration
Status: RESOLVED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XQuery 3 & XPath 3 Test Suite (show other bugs)
Version: Working drafts
Hardware: PC Linux
: P2 normal
Target Milestone: ---
Assignee: Michael Kay
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-06-12 15:16 UTC by O'Neil Delpratt
Modified: 2013-07-02 21:52 UTC (History)
1 user (show)

See Also:


Attachments

Description O'Neil Delpratt 2013-06-12 15:16:10 UTC
Please see the bug 11443 for details. This is an unresolved bug that has been transferred to the QT3.
Comment 1 Michael Kay 2013-06-21 14:31:29 UTC
I have reviewed the bug and the tests. The problem is still there. I think that Josh is right in saying that the current results do not match what the spec should happen, and I remain of the view that the spec should change to make the test results correct: essentially, copy-namespace mode "inherit" should apply to constructed element nodes, not only to copied element nodes. The fact that many implementations are reporting passes against these tests suggests that the spec is out of line with implementations on this one.
Comment 2 O'Neil Delpratt 2013-06-21 14:50:55 UTC
I am adding this test to the WG agenda for further discussion
Comment 3 Michael Kay 2013-06-21 19:49:15 UTC
This was an unresolved bug on the XQ 1.0 test suite. The expected result of the test appears to be in violation of the spec.

There are three affected tests:

K2-NameTest-30
K2-NameTest-31
K2-InScopePrefixesFunc-25

Currently, of the results received so far, for the first two tests Saxon and XMLPrime are claiming to pass the test, while EMC and Zorba are claiming to fail it. For the third test, Saxon, XMLPrime, and Zorba claim to pass, while EMC claims to fail. If the tests are changed as suggested in the bug report, these results will presumably be reversed. It would be useful to have input from other vendors for these three tests to see if there is any pattern.

The technical issue concerns namespace inheritance. The specification as written has the effect that the query

declare namespace p="http://p.uri/";
<p:a>
  <b xsi:type="p:int"/>
</p:a>

produces a tree in which the <b/> element has no "in-scope namespace" for the namespace (p, http://p.uri/), and the xsi:type attribute is therefore not a valid QName.

The cause of the problem is that namespace inheritance, as controlled using the copy namespaces declaration, applies only to elements that are copied, and the b element in this example is never copied. (The Note in 3.9.4 is explicit on this point.) If curly braces were used, thus:

<p:a>
  {<b xsi:type="p:int">12</b>}
</p:a>

then the outcome would be different.

Implementations may have difficulty supporting a data model in which the namespace (p, http://p.uri/) is in scope for the parent element a, but not for the child element b. Many external data models, such as DOM, have no way of representing this. It is needed only to support XML Namespaces 1.1, and our general position is that support for XML Namespaces 1.1 is optional. (Having said that, an implementation that cannot support this will also have difficulty conforming to the semantics of copy-namespaces no-inherit.) 

A change to the spec to fix this problem would be to add the following clause to 3.9.1.3 1.d.iii: If copy-namespaces mode specifies inherit, the resulting node inherits all in-scope namespaces of the newly constructed nodes, excluding any that would conflict with its existing in-scope namespaces.
Comment 4 Michael Kay 2013-06-23 07:49:56 UTC
The other thing that occurred to me about these tests is that using assert-xml is not ideal for this kind of test. If namespaces are not inherited, then the only way to serialize the tree accurately is by using XML 1.1 namespace undeclarations, and many test drivers may have difficulty with that. So there's a high risk that we're seeing spurious results for these tests (at least the two NameTest tests) due to test driver limitations. They should be changed to use more specific XPath assertions to determine the in-scope namespaces on the tree more robustly.
Comment 5 Jonathan Robie 2013-07-02 16:24:40 UTC
We decided not to change the spec. This should be fixed in the tests.
Comment 6 Michael Kay 2013-07-02 21:11:04 UTC
I have fixed the three tests in question, and have modified Saxon to conform to the specification and generate the expected results for these three tests. The modified Saxon fails on four tests:

qischema064
qischema065
qischema070
qischema083

In each case the serialized result of running the tests, serialized as XML 1.0, matches the result asserted using assert-xml; but the test does not pass because the result tree produced by the query contains "namespace holes" (namespace bindings that are present on a parent element and absent from its children) that are revealed when the tree is serialized as XML 1.1

In the first three cases I propose to modify the test to ensure that the xsi namespace is in-scope throughout the result tree by including a namespace declaration for this namespace in the outermost element constructor of the query.

In the final case I propose to modify the test assertions to ensure that the result tree has the correct namespace bindings. This test case - which requires validation of a tree containing "namespace holes" to produce a new tree with the same "namespace holes" - is worth testing because it may cause difficulties for some processors that use off-the-shelf schema processors.
Comment 7 Michael Kay 2013-07-02 21:52:03 UTC
Changes to tests have been committed.