Re: The changing DSIG name space

At 17:29 1/18/2001 -0500, Ken Goldman wrote:
>How does this work in the real world?  Assuming that the spec will not
>be frozen forever, does the name space keep changing?  Doesn't this
>affect interoperability?  Does the specification change, but the name
>space stays the same?

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, however, at that time more people are likely to be tracking 
it and if something does change, they're better off stubbing their toe on 
the change in the namespace instead of a more subtle alteration in the DTD 
or schema that they don't notice for 70% of their instances. The namespace 
should reflect reality instead of keeping it the same while changing the 
spec/dtd/schema behind it and pretending because the namespace hasn't 
changed, everything is stable.

>Would the software have to keep an ever growing list of name spaces it 
>supports, and run down the list every time it's looking for an element in 
>the DOM tree?  Is basing the name on the date typical?

A dated (or versioned, or RFC allocated) specification has a specific and 
frozen meaning. Prior to clarification of W3C's policies, I had written 
instances using schema that were valid at a given time for a given 
namespace. The WG then changed the DTD behind that namespace invalidating 
the examples I wrote that used to work! My examples should've continued to 
be valid under that namespace, and they should've created a new one.

>Is there a name space naming guidelines document at W3C which could
>give me some insight?

Yep, have a look at [1].

>[This namespace name may be reused in any update of the specification which 
>is made for the purpose of clarification or bug fixes. These changes will 
>be minor in that they do not (a) change the meaning or validity of existing 
>documents written using the namespace, or (b) affect the operation of 
>existing software written to process such documents.]

Joseph Reagle Jr.
W3C Policy Analyst      
IETF/W3C XML-Signature Co-Chair

Received on Thursday, 18 January 2001 23:29:17 UTC