Subject: RE: Extensbility and Versioning Paces

From: "David Orchard" <[email-masked]>
Date: Fri, 17 Sep 2004 10:34:02 -0700

Actually, I expect that the definition of some-optional-element has a
reasonable likelihood of tweaked in a compatible way.

Let's assume that you've got V1.0 of atom sans optional-element.  Then
optional-element is added in the namespace.  You do the look up and get
the definition of optional-element.  Then the optional-element is
modified in a compatible way.  Your software still works even if you
don't know the latest and greatest tweak to optional-element.  

In the case of an incompatible change, then the namespace or the name
would have to change, the same way that a version identifier would have
to move to 2.0 if version ids were used.

Whether a refinement, expansion, clarification is a compatible or
incompatible change is the tricky part.  

Cheers,
Dave  

> -----Original Message-----
> From: [email-masked] [mailto:owner-atom-
> [email-masked]] On Behalf Of Eric Scheid
> Sent: Thursday, September 16, 2004 2:14 PM
> To: Atom Syntax
> Subject: Re: Extensbility and Versioning Paces
> 
> 
> On 17/9/04 3:24 AM, "David Orchard" <[email-masked]> wrote:
> 
> > In both cases, you look up the atom spec for the definition of
> > some-optional-element.
> 
> This assumes that the definition of some-optional-element doesn't get
> refined, clarified, expanded or otherwise tweaked in successive
versions
> of
> the spec texts. Sure, it's mostly a safe bet because of the process
we're
> going through here, but there's no guarantee.
> 
> e.

---

From: Dare Obasanjo <[email-masked]>
Date: Sun, 19 Sep 2004 13:44:04 -0700 (PDT)

> don't know the latest and greatest tweak to

The world does not work in such a black or white
manner. Assuming that you can always replace an older
version of a spec with a newer one in place hardly
ever works in the real world. If the W3C did this, it
would be a disaster. I already face all sorts of
issues in my day job because specs at well known URLs
differ from the version that the code was written
against due to errata to the spec. Let alone believing
that you can just replace the version 1.0 spec with
the version 1.1 spec and so on. 

> to move to 2.0 if version ids were used.

How about a backwards incompatible clarification? I
see this all the time in W3C specs. Clarification on
empty string in namespace names in the XML namespaces
REC, clarificiation on what ###other in wildcards
really means and the changing the value space of
xsd:gMonth in the XML Schema REC are all examples of
backwards incompatible clarifications in W3C specs. 

Are you putting a stake in the ground and claiming
that Atom will not have any backwards incompatible
errata. 

Speaking of which, what is the IETF policy on errata? 

> incompatible change is the tricky part.  

It isn't just the tricky part, it is THE MOST
IMPORTANT PART from the perspective of implementers. 

=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #23
I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks.

		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Sun, 19 Sep 2004 14:33:40 -0700

>that Atom will not have any backwards incompatible

That is an option. It may or may not be a good prediction, but it is 
an option for this WG.

>Speaking of which, what is the IETF policy on errata?

There is no policy. If you look at what has been done in the past in 
different WGs, it's all over the map. Change the version number. 
Don't change the version number, just clarify. Add a version number 
to the new version because we forgot it in the old version. 
Mumble/pray a lot.

The advantage that the IETF has over the W3C is that we've been 
around much longer to make many more mistakes. Poor versioning is a 
great example, right up there with poor extensibility.

>IMPORTANT PART from the perspective of implementers.

+1

--Paul Hoffman, Director
--Internet Mail Consortium