RE: Tentative signature over C14N examples

Hi Merlin,

<merlin>
The C14N of e3 should ?not? have xmlns:w3c.
</merlin>

<john>
Actually, it should have the w3c namespace.  Each node receives namespace
nodes for its entire namespace context, including those derived from its
ancestors.
</john>

<merlin>
Also, I do not believe that the XPath tests for (self|parent)::e(1|2)
are correct. The default namespace for those nodes is non-null, and I
think that 2.3 of REC-xpath suggests that if you want to capture this
in an XPath you must use a namespace prefix in scope for the expression.
Hence ietf:e(1|2) in my earlier version of the XPath. Which was...

  <Transform ...><XPath xmlns:ietf="http://www.ietf.org">...ietf:e1...

But I'm often wrong about namespaces, so I'm prepared again.
</merlin>

<john>
Drats!  In the example I did this morning, I forgot about that detail.  I
will tweak the document subset expression box as follows:

<!-- Evaluate with declaration xmlns:ietf="http://www.ietf.org" -->

(//. | //@* | //namespace::*)
[ 
   self::ietf:e1 or (parent::ietf:e1 and not(self::text() or self::e2)) 
   or 
   count(id("E3")|ancestor-or-self::node()) = count(ancestor-or-self::node()) 
] 

This should allow the intended output results to follow from the current input.  Nice work, Merlin!
</john>

<merlin>
I think that adding a regular attribute to e1 would be potentially
useful for this example (i.e., <e1 foo="bar">), just so the second
clause of your XPath can capture more than just namespace nodes
(which are probably treated differently to regular attributes).
</merlin>

<john>
This doesn't seem to matter.  Attributes and namespaces are equivalent with respect to the fact that they treat the containing element as parent.  So, I'd prefer not to change the example at this point.
</john>

<merlin>
Also, an example of C14N on the e3 element below would be interesting:

<e1 xmlns="http://foo" xmlns:bar="http://baz">
  <e2 xmlns="" xmlns:bar="">
    <e3 ID="E3" />
  </e2>
</e1>

This captures that empty xmlns namespaces are not really inherited,
but empty xmlns:* are. At least, I think they are.
</merlin>

<john>
Again, I'd really rather not add that example at this stage.  The examples are primarily intended to show where changes will occur since this is primarily where misinterpretation of the rules will occur.  Your point is well-taken, but given how hard it is to read this document and mistakenly come to the conclusion that xmlns="" is inherited rather than generated under specific conditions, I'd prefer to cut off additions at this time.

Fixes, like the one above, seem to be the principal order of the day...

Thanks,
John Boyer
</john>

Merlin

r/jboyer@PureEdge.com/2000.10.10/11:31:44
>Hi Merlin,
>
>I've changed example 3.7 as given below, and I am hoping you can provide
>feedback ASAP on whether you concur with the new version:
>
>Input:
>
><!DOCTYPE doc [
><!ATTLIST e2 xml:space (default|preserve) 'preserve'>
><!ATTLIST e3 id ID #IMPLIED>
>]>
><doc xmlns="http://www.ietf.org" xmlns:w3c="http://www.w3.org">
>   <e1>
>      <e2 xmlns="">
>         <e3 id="E3"/>
>      </e2>
>   </e1>
></doc>
>
>XPath:
>
>(//. | //@* | //namespace::*)
>[
>   self::e1 or (parent::e1 and not(self::text() or self::e2))
>   or
>   count(id("E3")|ancestor-or-self::node()) =
>count(ancestor-or-self::node())
>]
>
>Canonical Form:
>
><e1 xmlns="http://www.ietf.org" xmlns:w3c="http://www.w3.org"><e3 xmlns=""
>xmlns:w3c="http://www.w3.org" id="E3" xml:space="preserve"></e3></e1>
>
>============================
>Thanks,
>John Boyer
>Development Team Leader,
>Distributed Processing and XML
>PureEdge Solutions Inc.
>Creating Binding E-Commerce
>v: 250-479-8334, ext. 143  f: 250-479-3772
>1-888-517-2675   http://www.PureEdge.com <http://www.pureedge.com/>
>
>
>
>-----Original Message-----
>From: merlin@baltimore.ie [mailto:merlin@baltimore.ie]
>Sent: Saturday, October 07, 2000 8:52 AM
>To: John Boyer
>Cc: xmldsig-interop@pothole.com; XML DSig
>Subject: Re: Tentative signatur
e 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
>

Received on Tuesday, 10 October 2000 19:19:08 UTC