Re: exc c14n bugs

r/reagle@w3.org/2002.06.04/
> On Tuesday 04 June 2002 12:03 pm, merlin wrote:
> > 1) Bug in the Specification
> >
> > Consider the following document:
> >   <A xmlns="http://example.org/">
> >     <b:B xmlns:b="http://example.org/b" xmlns="">
> >       <C xmlns="http://example.org/">
> >     </b:B>
> >   </A>
> 
> You're missing a clsoing "/" in C. I noted that because when I ran it 
> through my code it complained of it, and once fixed output the intuitive 
> result that you suggest:

You're right.

> > This is wrong (C is now in the wrong namespace). It should
> > be rendered:
> >   <A xmlns="http://example.org/">
> >     <b:B xmlns:b="http://example.org/b">
> >       <C></C>
> >     </b:B>
> >   </A>
> 
> So now we're presented with a situation in which many of us incorecctly 
> read the speak to produce correct and intuitive results by the (false) 
> assumption that 'xmlns=""' is processed like the namespace declarations.

That is correct.

> > The following addition to the Specification would correct
> > this:
> >
> > 4. If the token representing the default namespace is
> >    not present in InclusiveNamespace.PrefixList, then
> >    xmlns="" is rendered with a namespace axis iff:
> >      1. The element E that owns the namespace axis is in the
> >         node set, visibly utilizes the default namespace, and
> >         has no default namespace node in the node set
> >      2. The nearest output ancestor of E that visibly
> >         utilizes the default namespace has a default namespace
> >         node in the node set.
> 
> Step 3 is written as *any* of the subsequent conditions permit the 
> namespace to be ignored. You are proposing an *any* too (I think, or is
> it *and*) for rendering, it'd be easier to understand if it was also
> written as an ignore. (It's an exception to c14n.) I'm thinking this
> because I'm wondering if we can address this issue by simply saying:

I mean *and*; it could be written as just one long run-on
sentence.

>   A namespace node N (or the empty default namespace 
>   declaration xmlns="") with a prefix (or default namespace token) 
>   that does not appear in the InclusiveNamespacePrefix List is ignored 
>   if any of the following conditions are met:
>
> To rewrite 4 in light of that:
>  4. If the default namespace declaration is present and the token 
> representing the default namespace is not present in 
> InclusiveNamespace.PrefixList, then it is ignored if any of the
> following conditions are met:
>       1. The parent element E is not in the node set, 
>       2.  The default namespace is not visibly utilized.
>       3. The nearest output ancestor of E that visibly
>          utilizes the default namespace has the same value.

I'm not sure this is right; we're not interested in making
a special case of default namespace declarations, just
its undeclaration.

> So that's pretty close to the wording in 3. (If I did this correctly.)
> So it might be possible to say to include this in step 3 ...?

I'd like this to be the case. However, if we preclude the
inherited c14n behaviour from emitting the xmlns="" at the
'wrong' point, it will not emit it at the 'right' point;
for example:
  <A xmlns="http://example.org/">
    <b:B xmlns:b="http://example.org/b" xmlns="">
      <C />
    </b:B>
  </A>

If we suppress xmlns="" on b:B then it will not get placed
on C in the exc-c14n form so we'll get:
  <A xmlns="http://example.org/">
    <b:B xmlns:b="http://example.org/b">
      <C></C>
    </b:B>
  </A>

It seems to me that we have no alternative but to override
the c14n xmlns="" behaviour:

4. If the token representing the default namespace is
   not present in InclusiveNamespace.PrefixList, then the
   rules for generation of xmlns="" are changed as follows:
   When canonicalizing the namespace axis of an element E that
   is in the node set, output xmlns="" iff E visibly utilizes
   the default namespace (i.e., it has no namespace prefix),
   and it has no default namespace node in the node set,
   and the nearest output ancestor of E that visibly utilizes
   the default namespace has a default namespace node in the
   node set. This special case is necessary because xmlns=""
   is not represented in the XPath info set as a namespace
   node, but instead as the absence of a namespace node;
   see [C14N] §4.7.

I'm sure it's possible to write this more clearly.

Merlin

Received on Tuesday, 4 June 2002 15:47:57 UTC