Re: exc c14n bugs

On Tuesday 11 June 2002 05:47 pm, John Boyer wrote:
> The only problem with the proposed limitation is that, zen of the empty
> default namespace, explicitly declaring it at the apex node doesn't work
> because it is not represented by a node.

I'm not sure what you mean "zen of the" and if that implies not emitting it 
"doesn't work" but I agree it's an awkward position to be in. However, I 
also agree with Merlin and feel that our goal was to isolate the fragment 
from the ancestor context, not perfectly insulate it from the target 
context for removal/insertions. At this point, I'd rather defer node-set 
manipulations ("fixing up" relative URIs, xml:base, xml:lang, xml:space, 
default namespaces, etc.) to the application. (This is the same argument 
[1] I made a year ago! <smile/>) 

Once people have experience in those applications (XInclude, XML 
Encryption, and XML Protocol) and maybe XPath 2.0 (Infoset based), it'll be 
time for a new transform, or maybe even xmldsig 2.0, but until then I'd 
prefer we be consistent.

I've written some text in the spec that I hope addresses this [2].

[1] http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2001AprJun/0271
[2] http://www.w3.org/Signature/Drafts/xml-exc-c14n.html#sec-Target-Context
  5.1 Target Context

   The requirement of this specification is to satisfy some applications
   that "require a method which, to the extent practical, excludes
   ancestor context from a canonicalized subdocument." Given a fragment
   being removed from its source instance, this specification satisfies
   this requirement by excluding from the fragment any context from its
   ancestors that is not utilized. Consequently, a signature [XML-DSig]
   over that fragment will remain valid in its source context, removed
   from the source context, and even in a new target context. However,
   this specification does not itself insulate the fragment against
   confused interpretation in a target context.

   For example, if the <Foo/> element is signed in its source instance of
   <Bar/><Foo/></Bar> and then removed and placed in the target instance
   <Baz xmlns="http://example.org/bar"/><Foo/></Baz>, the signature can
   still be valid while <Foo/> can be interprated as belonging to the
   http://example.org/bar namespace: this is dependent on how the nodes
   are processed.

   This specification does not define mechanisms of removing, inserting,
   and "fixing up" a node-set. (For an example of this sort of
   specification, see the processing required of Creating the Result
   Infoset (section 4.5) when an [XInclude] is performed.) Instead,
   applications must carefully specify the XML (i.e., source, fragment,
   and target) or define the node-set processing (i.e., removal,
   replacement, and insertion) with respect to default namespace
   declarations (e.g., xmlns="") and xml attributes (e.g., xml:lang,
   xml:space, and xml:base).

> Merlin, on this point I'd prefer it if you continued to 'argue' the point
> if there is indeed more to consider.  Right now, I think the xmlns=""
> warrants special-case handling because of the weird way it is
> represented, but I am prepared to be convinced otherwise (or even to
> continue with a minority opinion that doesn't become part of the spec). I
> have no vested interest in either approach, just a desire to have all
> points considered before a decision is made so that we can avoid making a
> bad choice if possible (or at least to make the least bad choice given
> what is currently known).  Regardless of the outcome, your
> thought-provoking insights are always welcome :-)

Received on Wednesday, 12 June 2002 16:48:07 UTC