Atom In-lining

another Atom Landscape update, this time concerning draft-mehta-atom-inline: In-lining Extensions for Atom, which defines mechanisms for in-lining representations of linked resources in Atom documents.

there is an ongoing discussion whether this is Right or Wrong, because it extends Atom in a way which is not clearly allowed by the Atom spec, but it also is not disallowed. Atom's extension model leaves something to be desired, and because it is underspecified, it is impossible to predict how implementations will behave when encountering certain extensions. the basic question is which of these two policies are followed by an implementation:

• everything that is not allowed is forbidden.
• everything that is not forbidden is allowed.

both are not unreasonable assumptions to make (feel free to make your own fun associations with religions here), but in the absence of detailed instructions for every possible syntax variation, they are mutually exclusive and lead to different implementations. thus it is a bit unfortunate that Atom is not entirely clear about its general approach to this problem.

the draft as it currently stands has two problematic extensions: the first extension is that it introduces a child element for atom's <link> element, which usually is an empty element; this looks strange, but may not derail most implementations because they probably only access the <link> elements' attributes anyway. the second extension suggests that the extension element contained in the <link> element may contain atom markup (a complete <feed>); this will probably derail more implementations, because they may assume that atom markup only appears in the feed/entry structure defined in the atom spec, and not in other places as well.

all things considered, this draft seems to address a niche (optimizing pre-fetching of linked resources) and does so in a problematic way. in the end, it is a matter of taste whether people like it or not, so it remains to be seen how well this draft does. but whatever the outcome for that draft will be, it has sparked some useful discussions around the general question of Atom extensibility and best practices around that, and this might eventually lead to a new IETF Atom WG looking into these issues.

Comments

[Subbu Allamaraju]

Looks like a convoluted and misguided extension. Good luck to the proponents :)

Subbu