- From: merlin <merlin@baltimore.ie>
- Date: Wed, 05 Jun 2002 14:53:54 +0100
- To: reagle@w3.org
- Cc: w3c-ietf-xmldsig@w3.org
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 UTC