Once there is substantial deployment, a change in namespace 2 to 4
times a year would be a non-started and would guarantee that either
the bulk of the implementors would ignore the change and stick to and
recognize only one earlier namespace or the bulk of the implementors
would use wildcards.
A change every two to four years might just barely be tolerable.
Note that the wildcard I said I would use included the fixed year 2000
and thus matched only past namespaces all of which are actually known
and would not match any new namespaces generated in the future.
Donald
From: Rich Salz <rsalz@caveosystems.com>
Message-ID: <3A6842C0.4C813FD4@caveosystems.com>
Date: Fri, 19 Jan 2001 08:36:00 -0500
To: "Joseph M. Reagle Jr." <reagle@w3.org>
CC: w3c-ietf-xmldsig@w3.org
References: <4.3.2.7.2.20010118231722.0209ff08@rpcp.mit.edu>
>> As Don pointed out, we change the namespace when we've made a substantive
>> change to the specification -- rather than clarification. Also, as we get
>> more mature one would hope the specification and namespace doesn't have to
>> change as often
>
>This is an important point that's not explicitly addressed.
>
>Namespaces let us change the spec at any moment, but that doesn't mean
>we should. Changes (even if fixes) should be limited to a coarse
>granularity, like a two-four times per year. Otherwise folks will be
>tempted to use a wildcard like Don suggested and that could have real
>bad effects. This 'slushifying' of the namespace (not a complete
>freeze) should probably happen as soon as the recommendation gets final
>approval.
> /r$