Versioned Namespaces (was Re: [standards-jig] Avatars)

Evan Prodromou evan at
Wed May 7 21:47:01 UTC 2003

>>>>> "JK" == Justin Karneges <justin-jdev at> writes:

      Me> If you _don't_ have versioning of namespaces, there's NO WAY
      Me> for any processor to know that a partner in a conversation
      Me> is _really_ aware of the latest version of the protocol.

      JK> Sure there is.  Everyone should just be using the final
      JK> protocol. ;-)

That sounds great. If _nobody_ _ever_ implements experimental
protocols, this should work fine.

If anyone does, then this isn't much of a solution.

      JK> Look, I understand why you would need versioning to retain
      JK> compatibility between older versions of a spec.

Actually, it's more about explicitly specifying INcompatibility. Like,
let's say you got a phone call from Geoffrey Chaucer:

        Chaucer: English?

        You: Of course.

        Chaucer: Whan Zephirus eek with his sweete breeth
        	 Inspired hath in every holt and heeth
                 The tendre croppes, and the yonge sonne
                 Hath in the Ram his halfe cours yronne...

        You: "Eek"? "Heeth"? "Yronne"? What the hell are you talking
             about? SEGFAULT

In Chaucer's mind, he's speaking English, and if you say you
understand English, you should be able to grok his point. If there
were a versioned namespace for English, though, he'd be able to ask:

        Chaucer: Middle English of around 1360?

        You: No, not really.

        Chaucer: Darnne.

...with no harm done to your brain. If for some reason you received a
_lot_ of phone calls from Chaucer, and you'd bothered to study up on
Middle English to understand him, you'd be able to do this:

        Chaucer: Middle English of around 1360?

        You: Yes, quite well.

        Chaucer: Whan Zephirus eek with his sweete breeth
        	 Inspired hath in every holt and heeth
                 The tendre croppes, and the yonge sonne
                 Hath in the Ram his halfe cours yronne...

        You: Ha ha! Oh, Geoff, you _slay_ me.

Nobody [except lit grad students] _has_ to learn Middle English. If
you have some pressing need to, you can. But you don't _have_ to.

      JK> My point is that you shouldn't be using experimental specs
      JK> in the first place.

Why not build in a poison pill to enforce that?  Publish a bogus
incompatible namespace for the experimental spec that will not work,
and cannot work, with implementations of the final protocol. That
enforces the rule. Folks who implement experimentals can cause no one
else any harm.

Anyways, the same issues occur with "Proposed", "Draft", "Active", and
"Final" versions of a spec. Saying that no one should implement
experimentals doesn't preclude the need for protocol versioning.

      JK> While developing software, one of the most annoying things
      JK> to deal with is retaining compatibility with older
      JK> baggage/cruft/etc when you'd really just like to throw it
      JK> all out the window.

Hmm. I coulda swore that I showed in my example how in a
versioned-namespace environment implementors would never have to deal
with old cruft (except by returning errors that they don't implement a
given namespace).

In fact, _NOT_ having versions means you _always_ have to deal with
old baggage. There's no way to tell what kind of crap people are
putting into a packet marked with a namespace you think you

      JK> Baggage is the leading inhibitor of progress, and generally
      JK> just gets in the author's way. I don't think JEP authors
      JK> should have to deal with their own baggage.

So, I don't see any reason whatsoever that a JEP author has to support
or document older versions of the protocol. The only onus on the JEP
author is to bump the version part of the protocol namespace, which I
believe could be easily handled with an ENTITY in the JEP:



      JK> Seriously, if your JEP hasn't been approved yet, don't be
      JK> afraid to throw your entire spec out the window.

Amen to that. But having versioned namespaces has nothing to do with
maintaining compatibility in the spec. It makes it _easier_ to throw
everything out the window.

      JK> Tough luck for those that have implemented an earlier revision.

Actually, the tough luck is for those of us who keep up with the final


Evan Prodromou
evan at

More information about the Standards mailing list