Re: exc c14n bugs

Hi John,

r/JBoyer@pureedge.com/2002.06.05/09:36:41
>Hi Merlin,
>
>OK, now the confluence of features leading to the problem is clear to
>me.  Thanks for your patience.  Sorry I didn't have a chance to return
>to this thread yesterday.

You're welcome. I think these are all points that you've
explained in detail to me in the past.

>On Joseph's point today that any substantive change made in the PR stage
>has to be justified, I think that a clear case can be made.  I think
>some changes to the new text may also be needed.
>
>We have a core definition called 'visibly utilizes' which refers
>specifically to namespace declarations, not to Xpath data model nodes.
>In other words, the definition does not care about what could be
>characterized as a "quirk" of the XPath data model that an empty default
>namespace is not represented by a node. (Incidentally, I think XPath
>does it this way because of some wording in the Namespaces Rec, so my
>use of 'quirk' should not be construed as derogatory; I primarily mean
>'easily forgotten detail'.).
>
>The point of the definition was to provide the intuitive understanding
>that a namespace declaration is ignored if it is not visibly utilized.
>In Section 3, we switched from namespace declarations to namespace nodes
>because the nodes are supposed to be representative of the declarations.
>At the time section 3 was written, we overlooked the XPath data model
>quirk and the resulting patch we previously made to c14n.  But the
>oversight doesn't change the original intent.
>
>To comply with intent of the definition, Section 3 must be patched to
>account for the special representation of the empty default namespace
>declaration, which is what the new text does. 

I agree. I believe the spirit of the spec is unchanged by
these alterations; we are just correcting its letter.

>Anyway, 3.3.3 seems to need a tiny bit of clarification.  The first part
>says "it has not been rendered by any output ancestor".  Based on what
>happens in 3.3.2, one could read 'it' as being the namespace prefix, or
>one could and probably should interpret 'it' as meaning the namespace
>node N.  Neither of these is right.  The first part should be "no output
>ancestor has rendered a namespace prefix and value equal to those in N".
>
>Also, in 3.4.3, it seems that we should be emitting xmlns="" slightly
>more often than the current rule suggests.  If an element E has no
>output ancestor that visibly utilizes the default namespace and E meets
>the first two conditions, then xmlns="" should be emitted.  This ensures
>E cannot change in meaning if its exclusive canonicalization is
>transferred from one enveloping element to another.  This also makes the
>handling of xmlns="" consistent with the first part of 3.3.3.

I would disagree here. C14n does not emit xmlns="" in this
case, and we don't need to either. It is not the canonical
form that will be reparented, but the node set from which
the canonical form is generated. If the input node set is
reparented correctly, even into a document that uses the
default namespace, it will carry its (null) namespace URI
with it; For example, take the following document:
  <Foo />

Reparent it into this:
  <Bar xmlns="http://example.org/bar />

The result will be:
  <Bar xmlns="http://example.org/bar><Foo xmlns="" /></Bar>

And the (exclusive) canonical form, in either case will be:
  <Foo></Foo>

Merlin

>Naturally, if this change, the implementation in 3.1 would have to be
>tweaked.
>
>Cheers,
>John Boyer
>

Received on Wednesday, 5 June 2002 12:51:17 UTC