Re: Tentative signature over C14N examples

Hi,

Attached is a gzipped tarchive containing a signature over the
seven C14N examples from the latest C14N draft, hopefully
conforming to the latest signature draft. Included is also
the raw C14N output. However, there is still one difference
between my signature and the "correct" output so this should
not yet be considered a valid test of canonicalization.

r/jboyer@PureEdge.com/2000.10.06/11:52:54

><john>
>I also notice that your example 4 did not strip out the leading and trailing
>whitespace for that attribute's value.  The example in c14n-20000907 is
>wrong for not doing that.
>By saying that your non-validating parser treats it no differently, are you
>saying that your non-validating processor does not realize that the
>attribute is identified as an ID attribute?
>If so, please see Section 5.1 of the XML specification regarding conformance
>of non-validating processors.
></john>

All becomes clear. I have a patch for the Apache XML parser,
I'll clean it up and submit it to their dev list.

><merlin>
>Neither do I concur with the spec for example 7: I do not see
>a justification for xmlns="".
></merlin>
>
><john>
>The justification is that e3 is not namespace qualified in the input, so it
>should not be namespace qualified in the output.  The problem is that,
>unfortunately, the XPath data model represents an empty default namespace
>with the absence of a node, not with the presence of a default namespace
>node having an empty value.  Thus, w.r.t. e3, we cannot tell the difference
>between <e2 xmlns=""><e3/></e2> versus <e2><e3 xmlns=""/></e2>.  All we know
>is that e3 was not be namespace qualified on input, so we preserve this
>information on output.
></john>

From the spec, wrt element nodes, their namespace axis and emission of
xmlns="" iff:

1. Yhe element E that owns the axis is in the node-set

Here, element E is in the node set.

2. Element E has a parent element

Here, element E has a parent element.

3. The nearest ancestor element of E in the node-set has a default namespace
   node in the node-set (default namespace nodes always have non-empty values
   in XPath) 

Here, element E has no ancestor element in the node set.

Thus I do not see why this case qualifies for xmlns="".

Incidentally, it would appear to me that condition 3 implies condition
2 and thus condition 2 is redundant?

><merlin>
>I tweaked the XPath on example 7 to suit signature processing.
></merlin>
>
><john>
>Perhaps you could provide the full XPath transform that you've used.  I'm
>pretty sure your tweak is fine, but I'd like to see the declaration of the
>ieft prefix.  BTW, is there some reason why you didn't use the subexpression
>inside the square brackets of example 7?
></john>

Yes, I was having ID problems. I've fixed them and attached a signature
using the standard expression.

I now only differ on example 7, as explained above.

Merlin