Re: versioning...

On Tuesday 05 March 2002 14:16, Granqvist, Hans wrote:
> The namespace URIs many times become sacred untouchables
> and therefore impede changes to specs for fear of
> interoperability (rightly so). Isn't it so?

The "untouchability" of a namespace is merely a reflection of the 
untouchability of a particular spec and implementations, as you allude to. 
However, rev'ing namespaces is no problem. At the start of xmldsig I rev'd 
the namespaces through the WD stage with no ill effects:

http://www.w3.org/1999/10/signature-core/
http://www.w3.org/2000/01/xmldsig/
http://www.w3.org/2000/02/xmldsig#
http://www.w3.org/2000/07/xmldsig#
http://www.w3.org/2000/09/xmldsig#

When we got to CR it calcified because a substantive change in the spec 
might require inter-institution process hang-ups and recycling which we 
wanted to avoid. But again, that's the process that calcified, the 
namespace is just an accurate reflection of that.

Updating your namespaces because of a substantive change is actually nice 
to users and implementors of the spec. I got very annoyed when my published 
schemas which normatively referenced a dated version of a particular draft 
of the schema spec, that used to work, broke because schema made a 
substantive change to the old namespace. That led to a "compromise" of 
sorts on the W3C namespace policy [1] which states you can break folks 
usage *if* you warn them, *until* you get to CR.

[1] http://www.w3.org/1999/10/nsuri

In XENC I haven't been creating new namespaces for every substantive change 
for the same reason that the Schema WG didn't in that original case: no 
grand architectural arguments, just plain old editorial laziness. <smile/> 
But at least we've warned people:

  The Working Group will try to use a new namespace when changes
  in its syntax or processing are substantive. However, this
  namespace might be reused (prior to reaching Candidate Recommendation)
  by subsequent drafts in such a way as to cause instances using the
  namespace to become invalid or to change in meaning or affect the
  operation of existing software. Requests for a more stringent level of
  namespace stability should be made to the Working Group.
  http://www.w3.org/TR/2001/WD-xmlenc-core-20011018/

Regardless, if a user or implementor of a spec needs to go and tweak their 
code or instance for a new namespace, it also means they need to go and 
tweak some code or instance syntax too. As I said, it's a useful thing to 
do.

> When I implement these fine XML standards, I often think
> it'd be most excellent to have greater (optional)
> granularity than the URI. I don't care much how, as long
> as the mechanism is there somewhere.

I wonder if this is because the namespaces your using aren't being cycled? 
Regardless, if we have these attributes I want to be clear that (a) they 
mean nothing from the point of view of processing and semantics, they are 
purely advisory; or (b) they do mean something and be *very* clear what it 
means. My preference is no attribute versioning, followed by (a).

-- 

Joseph Reagle Jr.                 http://www.w3.org/People/Reagle/
W3C Policy Analyst                mailto:reagle@w3.org
IETF/W3C XML-Signature Co-Chair   http://www.w3.org/Signature/
W3C XML Encryption Chair          http://www.w3.org/Encryption/2001/

Received on Tuesday, 5 March 2002 14:38:04 UTC