- From: <paul.downey@bt.com>
- Date: Thu, 10 Feb 2005 10:04:28 -0000
- 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 UTC