[Bug 6517] New: Default namespace undeclarations

http://www.w3.org/Bugs/Public/show_bug.cgi?id=6517

           Summary: Default namespace undeclarations
           Product: XPath / XQuery / XSLT
           Version: Recommendation
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: normal
          Priority: P2
         Component: XQuery
        AssignedTo: jonathan.robie@redhat.com
        ReportedBy: mike@saxonica.com
         QAContact: public-qt-comments@w3.org


An equivalent bug was raised some time ago against XSLT 2.0 - see bug #5857.
This arose "in real life" from a user trying to generate an XML Schema as the
output of a transformation.

Consider the following query:

<s:complexType xmlns:s="http://www.w3.org/2001/XMLSchema"
xmlns="http://t.com/">
  <s:element ref="abcd" xmlns=""/>
</s:complexType>

Intuitively, one might imagine that the output would be the same:

<s:complexType xmlns:s="http://www.w3.org/2001/XMLSchema"
xmlns="http://t.com/">
  <s:element ref="abcd" xmlns=""/>
</s:complexType>

But it is not. The correct output is:

<s:complexType xmlns:s="http://www.w3.org/2001/XMLSchema"
xmlns="http://t.com/">
  <s:element ref="abcd"/>
</s:complexType>

Which is not what the user wants: the xmlns="" is there to ensure that the
QName-valued ref attribute is a QName in the null namespace, not in namespace
http://t/com/. 

(As it happens, Saxon produces the output the user would like, which is
incorrect against the current spec.)

The reason is that we construct the result tree bottom-up. First we construct
the s:element element, with a single in-scope namespace
xmlns:s="http://www.w3.org/2001/XMLSchema". Then we construct the s:complexType
element with two in-scope namespaces corresponding to those declared in the
source. Then the child element is copied, and namespace inheritance is in
force, so the copied child acquires a namespace binding for http://t.com/ from
its new parent.

The solution being proposed (not yet approved) for XSLT is that the default
namespace should never be inherited. Specifically, change 3.7.1.3 rule
1.e.ii.D.II to read:

If copy-namespaces mode specifies inherit, the copied node inherits all the
in-scope namespaces of the constructed node *other than any binding for the
default namespace*, augmented and overridden by the in-scope namespaces of the
original element that were preserved by the preceding rule. If copy-namespaces
mode specifies no-inherit, the copied node does not inherit any in-scope
namespaces from the constructed node.

The justification for treating the default namespace differently from other
namespaces is that the semantics of a namespace undeclaration are different.
Whereas the undeclaration xmlns:p="" makes the prefix p unavailable for use,
the undeclaration xmlns="" causes the prefix "" to refer to the null namespace
"" - so in many ways it behaves more like a redeclaration than an
undeclaration. In particular, in the example under study, the user wrote
xmlns="" because they wanted to define a specific binding between the empty
prefix and the null namespace.

(Another approach that might work is to treat xmlns="" as creating a namespace
binding. But that would create compatibility problems for applications using
the namespace axis, or its equivalent in-scope-prefixes().)


-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Monday, 2 February 2009 14:55:51 UTC