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: merlin <merlin@baltimore.ie>
Date: Wed, 05 Jun 2002 14:53:54 +0100
To: reagle@w3.org
Cc: w3c-ietf-xmldsig@w3.org
Message-Id: <20020605135355.098334432D@yog-sothoth.ie.baltimore.com>


Hi Joseph,

r/reagle@w3.org/2002.06.04/16:50:16
>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]

Perfect.

>> 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.)

Much of the text I suggested is unnecessary subject to our
precondition on the input.

3.2
  Peek a copy of the dictionary ns_rendered from the state
  stack and insert all the rendered namespace nodes (including
  xmlns=""), replacing any existing entries. Push ns_rendered
  onto the state stack and recurse.

The existing text is just not explicit that a copy is
needed, and shouldn't say 'list'; that's all.

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

Agreed.

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

BTW, the interop report says Excl[ui]sve.

Merlin
Received on Wednesday, 5 June 2002 09:54:36 GMT

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