- From: merlin <merlin@baltimore.ie>
- Date: Tue, 04 Jun 2002 16:55:45 +0100
- To: Aleksey Sanin <aleksey@aleksey.com>
- Cc: w3c-ietf-xmldsig@w3.org
r/aleksey@aleksey.com/2002.06.04/08:13:58 >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. No, the Specification I mention is the normative Specification of Exclusive XML Canonicalization: http://www.w3.org/Signature/Drafts/xml-exc-c14n.html Section 3, the first numbered list. This is the definition of exc-c14n. The Method that follows is "non-normative", which means that it is not the official definition. In case of an inconsistency between the normative Specification and the non-normative Method, the Specification takes precedence. If you consider the Method to be normative, then the following document: <A xmlns="http://example.org/"><B xmlns=""/ ></A> Will be rendered by exc-c14n as: <A xmlns="http://example.org/"><B></B></A> This is clearly incorrect. Similarly, the Method does not handle namespace nodes in the InclusiveNamespaces.PrefixList correctly when some are omitted from the namespace axis, nor does it render such namespace nodes if their parent element is absent. These are all at divergence with the normative Specification, and are not correct and not normative. Merlin >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-022 >8 >>>/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:56:18 UTC