Re: Usage Scenarios for Versioning and Extensibility

[James M Snell <jasnell@xxxxxxxxxx>]

owner-atom-syntax@xxxxxxxxxxxx wrote on 07/12/2004
09:01:49 PM:

> 
> owner-atom-syntax@xxxxxxxxxxxx wrote on 07/12/2004 06:03:25 PM:
> 
> > 
> > At 5:14 PM -0700 7/12/04, Mark Nottingham wrote:
> > >0) Let's imagine that Atom 1.0 has been released and finalised
in 
> > >all of its glory.
> > >
> > >1) And it was good... except for that nasty atom:title element;
> > >after wide deployment experience, it's agreed we need a new
version 
> > >of it. So, a new version of Atom is introduced. The new one
isn't 
> > >backwards-compatible with the old one.
> > >
> > >2) Then, we decide we want to add a new metadata element,
let's call 
> > >it "fog." So, a new version of Atom is introduced.
> > >
> > >3) After a while, someone comes up with a souped-up version
of 
> > >atom:title that is backwards-compatible, just *better*. It
gets 
> > >really popular, and yet another version of Atom is born.
> > >
> > >4) At the same time, a group of rogue Open Source Software
> > >programmers descends upon this idyllic scene and introduces
its own 
> > >extensions. Up until now, all of our extensions have been
approved 
> > >and incorporated by the WG, but these are destined to remain
> > >separate.
> > >
> > >5) Finally, in 2010, we realise that the Atom feed and entry
> > >containers aren't really doing the job, and we need to change
their 
> > >model. Yet Another Version of Atom (YAVA) comes into being.
> > >
> > >Any proposal for versioning should address at least these
> > >situations, show how the various extensions and changes are
> > >identified and disambiguated, and should explain how software
is to 
> > >handle them. They should also consider how combinations of
these 
> > >scenarios are handled.
> > 
> > +1 or more. This is an excellent mix and not at all far-fetched.
It 
> > should help us focus on what we need for versioning and extensibility.
> > 
> > --Paul Hoffman, Director
> > --Internet Mail Consortium
> > 
> 
> Agreed.  Fundamentally, the first and foremost thing that we
should 
> focus on is determining how difficult this WG wants to make it to
> allow such changes to occur and whether or not changes should be 
> defined so that they are backwards compatible.  I do not believe
it 
> would be too far fetched for this group to assert that changes 
> should be absolutely backwards compatible unless it can be 
> demonstrated that the a breaking change is absolutely required.  
> Let's set the bar high right from the beginning. 
> 
> Regarding #2, introducing an "extension namespace" where
such new 
> elements can be defined, experimented with, implementation 
> practice/experience gained, etc, would greatly enhance the process.
> When a new element is proposed, it would be put into the extension
> namespace initially.  Only after it has been implemented and
folks 
> agree that it is essential to have as part of the core would it be
> placed under the core namespace. 
> 
> Regarding #4, allow people to come up with whatever extension 
> elements they wish in their own namespace and define that all 
> elements in unknown namespaces are to be summarily ignored and 
> dismissed.  If the creators of those extensions wish to define
a 
> profile for their use, let them go through the work of writing up
an
> RFC that describes the appropriate semantics.  Once the RFC is
> published, Aggregators and other apps can choose whether or not to
> support that RFC. 
> 

You know, after going back and reading this and reading
the rest of the thread, I retract part of this.  The use of the MustUnderstand
attribute is a far better approach.  I would, however, definitely
like to see a tiered approach to changes made to the core namespace.

<atom:feed xmlns:atom="..." xmlns:atomex="...">
  <atom:title>...</atom:title>
  <atomex:core-extension atom:MustUnderstand="true"
/>
  <abc:other-extension atom:MustUnderstand="false"
/>
</atom:feed>

The creation and modification of elements in the abc
namespace are arbitrary.  Anybody can do that any time they wish.

The creation and modification of elements in the atomex
namespace would require that an RFC be submitted to this working group.
 As long as the RFC has been published and is available for discussion,
the element can automatically go into the atomex namespace.

The creation and modification of elements in the atom
namespace would require first that the changes be defined within the atomex
namespace (e.g. have an RFC submitted) and have achieved consensus within
this WG that the changes are critical to the core spec.

Following this approach *should* help to mitigate
the types of issues enumerated above.

> Whether or not Atom's versioning of the core spec gets out of 
> control is more a function of this groups philosophy towards 
> accepting changes of dubious or unproven utility. 
> 
> 
> - James M Snell
>  jasnell@xxxxxxxxxx
>  http://www.ibm.com
>  (877) 511-5082 / Office
>  930-1979 / Tie Line

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature