- From: Aleksey Sanin <aleksey@aleksey.com>
- Date: Tue, 04 Jun 2002 08:13:58 -0700
- 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 UTC