RE: Canonical XML typo?

Thanks.  I didn't mean to indicate I thought 2.3 was incorrect - I just used
it to try to show that 4.6 was a bit unclear.

> -----Original Message-----
> From: John Boyer [mailto:jboyer@PureEdge.com]
> Sent: Tuesday, December 05, 2000 11:09 AM
> To: Jonathan Marsh
> Cc: w3c-ietf-xmldsig@w3.org
> Subject: RE: Canonical XML typo?
> 
> 
> 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:35:40 UTC