Subject: Atom Versioning

From: Jan Algermissen <[email-masked]>
Date: Tue, 01 Sep 2009 07:34:18 -0400

RFC 4287 states this about the XML format it defines:

'For convenience, this data format may be referred to as "Atom  
1.0"' [Section 1.2]

Does this imply the intention that forward compatible changes to the  
Atom syntax will be referred to as Atom 1.x and that incompatible  
changes would be referred to as Atom 2.x , 3.x,...?

IOW, is there an implied versioning scheme?

Jan

---

From: Aristotle Pagaltzis <[email-masked]>
Date: Sat, 5 Sep 2009 21:40:56 +0200

* Jan Algermissen <[email-masked]> [2009-09-01 13:45]:
> 'For convenience, this data format may be referred to as "Atom 1.0"'
> [Section 1.2]
>
> Does this imply the intention that forward compatible changes
> to the Atom syntax will be referred to as Atom 1.x and that
> incompatible changes would be referred to as Atom 2.x, 3.x,...?

It’s a hat tip to the past, not the future. Unfinished versions
of Atom had been referred to as 0.2, 0.3, 0.5, etc. Early drafts
of the spec even had a `version` attribute, like most versions of
RSS. These ideas were both eventually rejected.

> IOW, is there an implied versioning scheme?

There was no intent to ever revise Atom.

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>

---

From: Jan Algermissen <[email-masked]>
Date: Mon, 07 Sep 2009 13:17:12 +0200

> There was no intent to ever revise Atom.

Ok.

...funny though that section 6.2 of the spec says:

"The Atom namespace is reserved for future forward-compatible  
revisions of Atom. Future versions of this specification could add new  
elements and attributes to the Atom markup vocabulary."

Jan

---

From: Aristotle Pagaltzis <[email-masked]>
Date: Mon, 7 Sep 2009 17:01:50 +0200

* Jan Algermissen <[email-masked]> [2009-09-07 13:25]:
>* Aristotle Pagaltzis <[email-masked]> [2009-09-05 21:50]:
> revisions of Atom. Future versions of this specification could
> add new elements and attributes to the Atom markup vocabulary."

That is a proviso in case a backwards-compatible revision ever
turns out to be good idea for a previously unfathomable reason.

Consider that a spec revision that doesn’t change the semantics
of elements or the MAY/SHOULD/MUST level of any requirements,
and doesn’t define new elements that cannot be ignored, would be
compatible with the existing spec to the point that any
implementation of RFC 4287 could just as well process this new
format (possibly with some loss of inessential functionality). So
in that case the revised spec could just reuse the namespace and
not carry a version identifier. But such new functionality
wouldn’t seem to require a complete revised spec – the extension
mechanisms of Atom should be adequate.

And if incompatible changes ever did become necessary, then
a change of namespace would ensure that consumers cannot mix up
the versions, like they do for the RSS versions. What such a
new spec would then be named is anyone’s guess, but an entirely
different name is just as likely as a revved version number.

Now, given those cases, there appears to be very little reason
to make a backwards-compatible revision, and very good reasons
not to make a backwards-incompatible one.

Hence, there was no intent to keep revising the format, at least
barring unforeseen and seemingly unlikely circumstances.

Of course it makes sense to have a hedge in case of contingencies
anyway – but that doesn’t mean it’s actually expected to be used.

Regards,

---

From: "James Holderness" <[email-masked]>
Date: Mon, 7 Sep 2009 21:48:29 +0100

> barring unforeseen and seemingly unlikely circumstances.

Is RFC 4287 still expected to progress to a Draft Standard at some point in 
the future? And, if so, would you expect it to make that progression in its 
current form with no revisions?

I've always wondered how that could be achieved with the current version of 
the spec. Where would you find two interoperable implementations that 
included *all* of the options and features in the specification?

Do libraries count? Say if you had an Atom parsing library that could parse 
any form of Atom, without necessarily doing anything with the parsed data. 
If yes, would a generic XML parser count? If not, what's the distinction?

Similarly for an Atom server: would a library that was capable of producing 
every form of Atom count as an implementation even if there was no actual 
server product that made full use of that library? If so, how would you go 
about testing its conformance?

How does the IETF usually go about establishing conforming implementations 
of a protocol? Curious minds what to know.

Regards
James