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: Aleksey Sanin <aleksey@aleksey.com>
Date: Tue, 04 Jun 2002 08:13:58 -0700
Message-ID: <3CFCD936.4050506@aleksey.com>
To: merlin <merlin@baltimore.ie>
Cc: w3c-ietf-xmldsig@w3.org

I have to disagree with you. The Specification you mentioned is C14N
specification and we are talking about Exc-C14N one and it describes the
transform in terms of ns_rendered list. I think that the ns_rendered list
makes a lot of sense and Exc-C14N namespace scheme is much more
simple than the scheme in C14N.  As you can see from this example,
the namespace node is rendered *only* if there is another namespace
node with same prefix and different value. I think this is correct behavior
and we should keep it.


Aleksey

>The sample implementation is explicitly non-normative, and
>it does not handle bizarre namespace constructions correctly;
>this is not the only instance of its misbehaviour. For
>instance, it never renders xmlns="".
>
>The Specification is where you need to look for the normative
>definition of what to do, and it says not to render the
>namespace node if the nearest output ancestor of its parent
>element that visibly utilizes the namespace prefix (line 6
>above) has a namespace node in the node set with the same
>prefix and value. I omit the default namespace node from
>foo:Nothing so the namespace node must be emitted on line 7.
>This is exactly equivalent to the c14n behaviour, which is
>how it should be.
>
>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.
>
>It can be made _more_ correct with the following change:
>
>3.1:
>  s/list/dictionary/
>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.
>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.
>
>We can make this algorithm yet more correct in more cases by
>going into yet more detail. Do we wish to do this?
>
>Aside: in the spec, section 3, the parameter is variously called:
>   InclusiveNamespace-PrefixList
>   InclusiveNamespacePrefix List
>   InclusiveNamespaces PrefixList
>   and, in my text above, 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.
>
>[1] http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2002AprJun/att-0199/01-merlin-c14n-two.tar.gz
>[2] http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2002AprJun/att-0228/01-merlin-c14n-three.tar.gz
>[3] http://www.w3.org/Signature/2002/02/01-exc-c14n-interop.html
>
>Merlin
>
>  
>
>>    --On Freitag, 31. Mai 2002 13:18 +0100 merlin
>>    [9]<merlin@baltimore.ie> wrote:
>>
>>    Hi Christian,
>>    I've tweaked the input document slightly to show a few more
>>    edge cases if you're interested; see attached:
>>    Merlin
>>
>>References
>>
>>  1. http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2002AprJun/att-0228
>>/01-merlin-c14n-three.tar.gz
>>  2. http://example.org/bar
>>  3. http://example.org/foo
>>  4. http://example.org/foo
>>  5. http://example.org/baz
>>  6. http://example.org/foo
>>  7. http://www.w3.org/TR/xml-exc-c14n/#sec-Specification
>>  8. http://example.org/foo
>>  9. mailto:merlin@baltimore.ie
>>    
>>
Received on Tuesday, 4 June 2002 11:12:09 GMT

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