RE: Significant W3C Confusion over Namespace Meaning and Policy

I think that the general issue of namespace evolution is currently
covered in the extensibility and versioning finding.  There is a section
on component version identification choices which lists 4 broad based
choices for ns management.  Further, the web arch v1 says that specs
should specify their namespace management policies.  

If you accept that the general ev part of your request is covered by
finding + web arch v1, then it seems to me you are asking the TAG to
examine which of the board based choices should be adopted for W3C
namespaces, including XML, XSLT, etc.  

If you don't accept that the general ev part of your request is covered
by finding/web arch, then can you elaborate on what is missing?  Seems
to me any general aspects of this issue should be in the finding/web


> -----Original Message-----
> From: [] On Behalf
> John Boyer
> Sent: Wednesday, February 09, 2005 1:35 PM
> To:
> 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},
> is not equal to
> ({lang, space, base, id},
> The W3C director directed the W3C to this interpretation in
>, 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
> 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 01:23:56 UTC