Re: Significant W3C Confusion over Namespace Meaning and Policy

On Feb 9, 2005, at 1:34 PM, John Boyer wrote:
> 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)

Which would be equivalent to saying that the state of a resource
cannot change without also changing its URI.  We know that is false
in the general case, so I hope you forgive me for rejecting
*identified* as having the meaning you suggest.  Naturally, that
doesn't prevent W3C-allocated namespace resources from having
the property you suggest.

> 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.

No, it says that groups *should* use a template in the original
namespace-defining document that specifies either that no updates
will be made or that updates will be made only for clarification
or bug fixes.  It does not say whether adding a new name to the
namespace is considered an update, nor whether such an update
shall be considered major or minor.

In my opinion, you should put aside the process issues and state
clearly what the technical benefits/drawbacks are of allowing a
new name to be added to an existing namespace.  Merely claiming
"it is defined that way in Namespaces" doesn't really argue for
anything more than changing the Namespaces recommendation to
better suit the architecture.  What is important to us is to get
the definition right for the future.

+1 to making the technical question a TAG issue or adding it to
the existing E&V issue.  What the Director chooses to do in terms
of W3C policy is really a separate issue, even after the TAG
comes to a conclusion (if any).


Cheers,

Roy T. Fielding                            <http://roy.gbiv.com/>
Chief Scientist, Day Software              <http://www.day.com/>

Received on Wednesday, 9 February 2005 23:59:29 UTC