W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > April to June 2002

Re: Y5 Exclusive C145n interop; was Re: c14n/exc-c14n interop samples

From: Joseph Reagle <reagle@w3.org>
Date: Tue, 4 Jun 2002 16:50:16 -0400
To: merlin <merlin@baltimore.ie>, Aleksey Sanin <aleksey@aleksey.com>
Cc: w3c-ietf-xmldsig@w3.org
Message-Id: <20020604205017.DD13E675@policy.w3.org>

On Tuesday 04 June 2002 10:03 am, merlin wrote:
> Joseph, perhaps the non-normative implementation should
> state that it is not 100% correct when parts of the namespace
> axis are omitted, or when elements are omitted but not parts
> of their namespace axis.

How about:
   The following is a (non-normative) method for implementing the
   Exclusive XML Canonicalization method [INS: for many straightforward
   cases -- it assumes a well-formed subset and that if an element is in
   the nodeset, so is all of its namespace axis; if the element is not in
   the subset, neither is its namespace axis. :INS]

> It can be made _more_ correct with the following change:
> 3.1:
>   s/list/dictionary/

Ok.

> 3.:
>   Render xmlns="" iff:
>   1. The default namespace is visibly utilized by the element
>      node, or the default prefix token is present in
>      InclusiveNamespaces.PrefixList.
>   2. The element does not have a namespace node in the node
>      set declaring a value for the default namespace.
>   3. The default namespace prefix is present in the
>      dictionary ns_rendered.

Ok.

> 3.2:
>   Push a copy of the dictionary ns_rendered onto the state
>   stack. Add the rendered namespace nodes to ns_rendered,
>   replacing any existing entries. Remove every prefix that
>   is visibly utilized by the element node, but does not have
>   a namespace node in the node set. Remove every prefix that
>   is present in InclusiveNamespaces.PrefixList but does not
>   have a namespace node in the node set. Recurse.

I'm not sure about this. What is this text addressing? (In my code I don't 
do these things at this point, but I might not be supporting some of the 
cases you are. And, when you push the copy on the state stack, are these 
additions and removals you are doing to that copy? In that case, I'd rather 
make a copy, make the changes to the copy, the push and recurse.)

> We can make this algorithm yet more correct in more cases by
> going into yet more detail. Do we wish to do this?

Well, not even the spec says *exactly* how far interop can go, it just 
warns as you go beyond well-formed and then well-balanced, things get 
hairy-er. It might have been nicer to say exactly what form the input 
XML... Regardless, as long as we give the warning for what this 
non-normative implementation does, I'm relative satisfied -- at this point 
in the spec development.

> Aside: in the spec, section 3, the parameter is variously called:
>    InclusiveNamespace-PrefixList
>    InclusiveNamespacePrefix List
>    InclusiveNamespaces PrefixList
>    and, in my text above, InclusiveNamespaces.PrefixList

Ok, the text now states  InclusiveNamespaces PrefixList.

> I would also suggest replacing merlin-c14n-two.tar.gz[1]
> with merlin-c14n-three.tar.gz[2] in exc-x14-interop[3];
> it is a better test of more edge cases.

http://www.w3.org/Signature/2002/02/01-exc-c14n-interop.html
new revision: 1.22
Received on Tuesday, 4 June 2002 16:50:18 GMT

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