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

RE: Canonical XML typo?

From: John Boyer <jboyer@PureEdge.com>
Date: Tue, 5 Dec 2000 11:09:08 -0800
To: "Jonathan Marsh" <jmarsh@microsoft.com>
Cc: <w3c-ietf-xmldsig@w3.org>
Message-ID: <BFEDKCINEPLBDLODCODKEENBCGAA.jboyer@PureEdge.com>
Hi Jonathan,

As Donald and Gregor have indicated, the text in Section 4.6 needs to be
tweaked.  When I made the statement in 4.6, I was actually thinking about
the canonical form's node-set, so it's too bad I didn't say it that way :-(,
although Gregor's way of putting it seems better.

So, to be clear, Section 2.3 is correct, and the example does not circumvent
it.  Section 2.3 says that the namespace node 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.  When you
apply the Xpath expression, all of the bar elements and their namespace
declarations disappear from the node-set, which is then representative of
the canonical form's node-set, not the source document's node-set (which
would be a full node-set).

Thanks for bringing this up, and Section 4.6 will be fixed shortly.
John Boyer
Team Leader, Software Development
Distributed Processing and XML
PureEdge Solutions Inc.
Creating Binding E-Commerce
v: 250-479-8334, ext. 143  f: 250-479-3772
1-888-517-2675   http://www.PureEdge.com <http://www.pureedge.com/>


-----Original Message-----
From: w3c-ietf-xmldsig-request@w3.org
[mailto:w3c-ietf-xmldsig-request@w3.org]On Behalf Of Jonathan Marsh
Sent: Thursday, November 30, 2000 3:49 PM
To: jboyer@PureEdge.com
Cc: w3c-ietf-xmldsig@w3.org
Subject: Canonical XML typo?


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 Tuesday, 5 December 2000 14:09:24 GMT

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