Re: Y5 Exclusive C145n interop; was Re: c14n/exc-c14n interop samples

Hi Aleksey,

r/aleksey@aleksey.com/2002.06.03/22:33:41
>   One more question about tests from [1]merlin-c14n-three.tar.gz
>   The result of 11th transform in c14n-10.txt after Exc-C14N looks as
>   follows:
>    1 <bar:Something xmlns:bar=[2]"http://example.org/bar">
>    2     <foo:Nothing>
>    3       <foo:Something xmlns:foo=[3]"http://example.org/foo">
>    4         <bar:Something>
>    5           <foo:Something>
>    6             <foo:Nothing>
>    7               <foo:Something xmlns:foo=[4]"http://example.org/foo">
>    8                 <baz:Something
>   xmlns:baz=[5]"http://example.org/baz"></baz:Something>
>    9               </foo:Something>
>   10             </foo:Nothing>
>   11           </foo:Something>
>   12         </bar:Something>
>   13       </foo:Something>
>   14     </foo:Nothing>
>   15   </bar:Something>
>   and I wonder why do we have xmlns:foo=[6]"http://example.org/foo"
>   declaration on line 7?
>   According to [7]http://www.w3.org/TR/xml-exc-c14n/#sec-Specification
>   the namespace
>   node is rendered if and only if it is visibly utilized and it's prefix
>   and value do not appear
>   in the ns_rendered list. In this case,
>   xmlns:foo=[8]"http://example.org/foo" is already
>   added to the ns_rendered list by line 3 and from my point of view it
>   should not be
>   rendered on line 7.

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 10:03:37 UTC