W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > October to December 2000

Canonical XML typo?

From: Jonathan Marsh <jmarsh@microsoft.com>
Date: Thu, 30 Nov 2000 15:49:14 -0800
Message-ID: <330564469BFEC046B84E591EB3D4D59C1621D2@red-msg-08.redmond.corp.microsoft.com>
To: <jboyer@PureEdge.com>
Cc: <w3c-ietf-xmldsig@w3.org>
Apologies for missing the CR deadline - this issue just surfaced in our
early implementation efforts.

-------------------
Section 2.3 Processing Model

* Namespace Nodes- A namespace node N is ignored if the nearest
[*]ancestor[*] element of the node's parent element that is in the
node-set has a namespace node in the node-set with the same local name
and value as N. Otherwise, process the namespace node N in the same way
as an attribute node, except assign the local name xmlns to the default
namespace node if it exists (in XPath, the default namespace node has an
empty URI and local name). 
-------------------
Section 4.6 Superfluous Namespace Declarations

Unnecessary namespace declarations are not made in the canonical form.
Whether for an empty default namespace, a non-empty default namespace,
or a namespace prefix binding, the XML canonicalization method omits a
declaration if it determines that the [*]immediate parent[*] element in
the canonical form contains an equivalent declaration.
--------------------

Given this input:

  <foo xmlns="http://www.example.org">
    <bar xmlns="">
      <foo xmlns="http://www.example.org">
        <bar xmlns="">
          <foo xmlns="http://www.example.org">
        </bar>
      </foo>
    </bar>
  </foo>

And a nodelist which strips the bar elements, something like:

  //.[not(self::bar)] | //namespace::*[not(parent::bar)]

The canonical output would appear to be:

  <foo xmlns="http://www.example.org">
    <foo>
      <foo xmlns="http://www.example.org"/>
    </foo>
  </foo>

(Please excuse any canonicalization errors or whitespace differences
here that aren't germain to my point.)

It appears that superfluous declarations can still squeak through.  In
other words, this example is so contrived to circumvent section 2.3, by
ensuring that no ancestor in the source document has a duplicate
namespace node.  And 4.6 only applies to immediate parents in the output
document, and not to ancestors, and thus applies to the first child foo,
but not the grandchild foo.

Should "immediate parent" in 4.6 instead be removed in favor of
something that more closely resembled the scoping rules of the Namespace
Spec?

Thanks, 

Jonathan Marsh
jmarsh@microsoft.com
Received on Thursday, 30 November 2000 18:50:04 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.29 : Thursday, 13 January 2005 12:10:11 GMT