[Bug 6517] New: Default namespace undeclarations


           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"
  <s:element ref="abcd" xmlns=""/>

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

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

But it is not. The correct output is:

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

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

(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 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