RE: exc c14n bugs

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.

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. 

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.

Naturally, if this change, the implementation in 3.1 would have to be
tweaked.

Cheers,
John Boyer

Received on Wednesday, 5 June 2002 12:37:12 UTC