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

Re: Last call announcement for Namespaces 1.1

From: Joseph Reagle <reagle@w3.org>
Date: Wed, 11 Sep 2002 11:01:25 -0400
To: Richard Tobin <richard@cogsci.ed.ac.uk>, Paul Grosso <pgrosso@arbortext.com>
Cc: <w3c-xml-plenary@w3.org>, "XML Signature (W3C/IETF)" <w3c-ietf-xmldsig@w3.org>
Message-Id: <200209111101.25399.reagle@w3.org>

On Tuesday 10 September 2002 07:14 pm, Richard Tobin wrote:
> Namespaces 1.0 allowed the default namespace to be undeclared by
> using xmlns="".  Namespaces 1.1 in addition allows prefixes to be
> undeclared, e.g. xmlns:foo="".

Ah right, sorry for being so dense, and this is the source of my concern for 
c14n.

> It goes on to say:
>
>    [...] This means that an element will have a namespace node:
>
>     * for every attribute on the element whose name starts with xmlns:;
>
> this needs to be changed to "every attribute on the element whose
> name starts with xmlns: and has a value which is non-empty";

Yep.

>     * for every attribute on an ancestor element whose name starts xmlns:
>       unless the element itself or a nearer ancestor redeclares the
> prefix;
>
> this should be changed to say "... redeclares or undeclares";

The precedent of these statements is the conditions under which an element 
has a namespace nodes, so to recompose all of this:

"This means that an element will have a namespace node for every attribute 
on an ancestor element whose name starts xmlns: unless the element itself 
or a nearer ancestor redeclares or undeclares the prefix;"

So that sounds right.

>     * for an xmlns attribute, if the element or some ancestor has an
>       xmlns attribute, and the value of the xmlns attribute for the
>       nearest such element is non-empty;
>
> this remains true.

Yep.

> Essentially the XPath data model is unchanged; it's just possible to
> construct some values of the data model that couldn't previously be
> obtained by reading in an XML document, viz. ones in which a child
> element does not have a namespace node for a prefix that its parent
> has one for.

Right. However, I think this would also require changes to c14n and possibly 
exc-c14n. (I don't think exc-c14n would change because it only emits a 
namespace declaration if the prefix is utilized, and I doubt that an 
undeclared prefix will be utilized, so the results probably look the same.) 
By far, the most annoying part of those two specifications was the 
treatment of xmlns="": we had required special rules for emitting those 
declarations [a]. We might also need similar rules for the new undeclared 
prefixes too. However, since I now understand NS1.1 is for use with XML1.1, 
which would also require tweaks to XPath1.0, it's reasonable to think specs 
dependent on XPath1.0 also need tweaks... (BTW: I wonder if XPath2.0 is 
tracking these changes, or firmly rooted in XML1.0 with schema?)

[a] http://www.w3.org/TR/2001/REC-xml-c14n-20010315#PropagateDefaultNSDecl
Received on Wednesday, 11 September 2002 11:01:41 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:10:10 UTC