[Bug 22334] Expected results have an erroneous namespace declaration

https://www.w3.org/Bugs/Public/show_bug.cgi?id=22334

Michael Kay <mike@saxonica.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|XQuery 3 & XPath 3 Test     |XQuery 3.0
                   |Suite                       |
           Assignee|oneil@saxonica.com          |jonathan.robie@gmail.com

--- Comment #3 from Michael Kay <mike@saxonica.com> ---
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.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Friday, 21 June 2013 19:49:17 UTC