* Jan Algermissen <[email protected]> [2009-09-07 13:25]: >* Aristotle Pagaltzis <[email protected]> [2009-09-05 21:50]: >> 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."
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, -- Aristotle Pagaltzis // <http://plasmasturm.org/>
