[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Usage Scenarios for Versioning and Extensibility



On Jul 12, 2004, at 2:47 PM, Dare Obasanjo wrote:

My primary use case for versioning is simple. How can
an aggregator which encounters a different version of
Atom from one its seen before know whether it is
backwards compatible or not? With RSS, the assumption
I use in RSS Bandit is that all feeds are RSS 2.0 and
the version attribute is ignored.

I'd like to make this a bit more concrete.

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.


I'd like Atom to
have something formal about what aggregators like RSS
Bandit should do to be able to distinguish Atom 0.3
from Atom 1.0 [for example].

That is a problem that we should not attempt to address; pre-draft versions of Atom are not for deployment, and anyone who does so in a non-experimental manner is taking all of the risk upon themselves. The final release of Atom will, at least, be identified by a different namespace URI, so that should be sufficient.


--
Mark Nottingham     http://www.mnot.net/