- From: Joseph Reagle <reagle@w3.org>
- Date: Wed, 9 Jan 2002 18:33:10 -0500
- 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 UTC