W3C home > Mailing lists > Public > www-tag@w3.org > February 2005

RE: Significant W3C Confusion over Namespace Meaning and Policy

From: <paul.downey@bt.com>
Date: Thu, 10 Feb 2005 10:04:28 -0000
Message-ID: <2B7789AAED12954AAD214AEAC13ACCEF2709DFE6@i2km02-ukbr.domain1.systemhost.net>
To: <JBoyer@PureEdge.com>, <www-tag@w3.org>
Cc: <derhoermi@gmx.net>

John wrote:

> Although I was unaware of this directive in particular,
> I was familiar with what a namespace means according to
> definition, and one aspect of C14N for XML 1.0 assumes
> that further features would be added to a version of XML
> whose namespace had changed.

I'm puzzled how XML base should change it's namespace given 
it's the addition of a name into the reserved set of names 
beginning with the characters 'x' 'm' 'l' that's at stake. 

Following the idea that a change in anything requires a new 
namespace would mean conjuring up a new prefix 'y' 'm' 'l'
or going to <?xml version='1.2' ?> which would defeat the 
tactical purpose of this otherwise excellent specification.

With 20-20 hindsight the original XML Recommendation could have 
been clearer in regard to its own evolution, and prevented c14n 
from making the wrong (IMO) 'assumption' wrt to inheritance of 
attributes, but it would be more helpful if generic principle 
of how XML languages may evolve was set out by the W3C. 
 
Paul


-----Original Message-----
From: www-tag-request@w3.org [mailto:www-tag-request@w3.org]On Behalf Of
John Boyer
Sent: 09 February 2005 21:35
To: www-tag@w3.org
Cc: Bjoern Hoehrmann
Subject: Significant W3C Confusion over Namespace Meaning and Policy



Dear TAG,

Some of you may be aware that an issue with the 
xml:id specification began erupting the day 
before it became a CR.

The issue has flowered nicely into a more general
discussion of what namespaces mean and what is
the W3C policy regarding their assignment in
recommendation track documents.

I've been asked to provide this information to you,
and as PureEdge AC rep I'd like to please request that 
the TAG make a formal statement to all working groups 
regarding these issues as soon as possible.

The kernel of the issue is my interpretation of 
the definition of namespace as it appears in the
Namespaces recommendation.  The definition is that 
a namespace is a collection of names *identified* 
by a URI. So, for example, the namespace
({lang, space}, http://www.w3.org/XML/1998/namespace)

is not equal to 

({lang, space, base, id}, http://www.w3.org/XML/1998/namespace)

The W3C director directed the W3C to this interpretation in
http://www.w3.org/1999/10/nsuri, which states that a recommendation
cannot add more than clarifications and bug fixes without changing
the namespace URI.

Although I was unaware of this directive in particular,
I was familiar with what a namespace means according to
definition, and one aspect of C14N for XML 1.0 assumes
that further features would be added to a version of XML
whose namespace had changed.

More recently, we in the XForms working group were presented
with "W3C Policy choices" on namespaces for our next version, 
in which keeping the same namespace was not an option.  Although 
it had become clear to me that there was therefore a policy, I 
didn't know where the document was and didn't really look
(because it was in accord with my understanding).  
XHTML 2 seems to be taking the same approach.  Bjoern was nice
enough to send the link, though I will not speak for whether or
not he agrees with the policy.

Anyway, despite the director's directive, it is almost universally
not being followed in the past (e.g. xml:base, xslt, svg, etc.).

I seek direction from the TAG, or whomever is in authority to
make such a decision for the W3C, as to whether the
http://www.w3.org/1999/10/nsuri is repealed and recommendations
are encouraged to reuse namespaces or whether the W3C intends
to require correction of this problem going forward.

Thanks,
John Boyer, Ph.D.
Senior Product Architect and Research Scientist
PureEdge Solutions Inc.
Received on Thursday, 10 February 2005 10:03:25 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:47:32 GMT