W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > January to March 2002

Re: Notes on xml-exc-c14n rev 1.21

From: Joseph Reagle <reagle@w3.org>
Date: Wed, 9 Jan 2002 18:33:10 -0500
Message-Id: <200201092333.SAA30121@tux.w3.org>
To: "Thomas Maslen" <tmaslen@wedgetail.com>, w3c-ietf-xmldsig@w3.org, "John Boyer" <JBoyer@PureEdge.com>
OPEN

On Wednesday 09 January 2002 04:28, Thomas Maslen wrote:
>     (e)	A paragraph in section 1.1 says "The namespace axis of an element
> 	contains nodes for all namespace declarations [...]".  If this is
> 	meant to be consistent with XPath semantics, it should mention the
> 	absence of a node for xmlns="".

John, can you confirm and provide text?

>     (2)	Where is the exc-c14n behaviour of the default namespace
> specified?
>
> 	The default namespace ("xmlns") has various funny properties that
> 	have to be dealt with in definitions, particularly
>
> 	      -	since the default namespace doesn't have a namespace prefix,
> 		phrases like "For namespace prefixes ..." don't apply to it,
>
> 	      -	since XPath very thoughtfully indicates xmlns="" by the
> 		absence of a namespace node, phrases like "each namespace
> 		node" don't do the job either.
>
> 	The Canonical XML recommendation jumped through the appropriate
> 	hoops to correctly define the behaviour of the default namespace
> 	(despite XPath), but I don't think that the exc-c14n draft does.
>
> 	Section 1.1 of exc-c14n is fine:  the definition of "visibly
> 	utilizes" does have a sentence that accounts for the default
> 	namespace [well, assuming that it is *not* using XPath semantics,
> 	i.e. the incredible disappearing xmlns="" node].

Right, that's this bit, "which occurs if E has no namespace prefix".

> 	Section 3 contains two definitions of exc-c14n, and I don't think
> 	that either of them really addresses the default namespace:
>
>
> 	      -	the first definition is "Canonical XML, with these three
> 		exceptions".
>
> 		The wording in the exceptions (2 and 3) talks about
> 		"namespace prefixes", so it doesn't include the default
> 		namespace -- so presumably the default namespace just
> 		inherits the Canonical XML behaviour, i.e. it uses
> 		inclusive c14n?
>
> 		Is that the intent?  (I would have guessed that the
> 		default namespace was meant to be handled exclusively).
>
>
> 	      -	the second definition is the pseudocode algorithm.
>
> 		Step 3 of the pseudocode talks about "namespace nodes"
> 		in the XPath sense, so implicitly [accidentally?  Or
> 		deliberately?] it applies to xmlns="mumble" and will
> 		treat it exclusively -- c.f. the first definition,
> 		above -- but it does not handle xmlns="" at all.
>
>
> 	I think that there are two options for the spec that would give
> 	consistent results:
>
> 	    (I)	state that the default namespace is always treated
> 		inclusively, i.e. effectively the InclusiveNamespaces
> 		PrefixList invisibly contains the default namespace
> 		(which, of course, doesn't have a prefix)
>
> 	   (II)	modify Section 3 (I haven't figured out how) so that both
> 		xmlns="mumble" and xmlns="" are canonicalized exclusively,
> 		i.e. they only show up when they are visibly utilized
>
> 	Of these, I definitely prefer (II), because I think it produces
> 	the less surprising behaviour.
>
> 	[Or is there something I haven't realized about exc-c14n that
> 	makes this all a silly question, e.g. element names are always
> 	prefixed?]

No, I think you identified a blind spot. I've modified 3.1.3 to read:

  For every /+namespace node with a+/ prefix that does not appear in
 the InclusiveNamespacePrefix List, a namespace declaration is output
 at every output element where that prefix is visibly utilized and that
 prefix and its value is not already in an output ancestor.

However, I wonder what if their is a semantic difference between a missing 
InclusiveNamespace PrefixList and one equal to "" ?
Received on Wednesday, 9 January 2002 18:33:24 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.29 : Thursday, 13 January 2005 12:10:14 GMT