- 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