two flavors of atom extensions
first, there are two valid ways to extend an Atom document:
format extensions change the actual format of the Atom document. a good example is the proposed threading extension. format extensions are meant to handle cases where *all* Atom documents could benefit from the extension. makes sense.
content extensions take advantage of a feature built into Atom that allows you to make the actual content element of the document contain another document. in this case, you can either embed the extension data within the content element or add a
src attribute to the
content element that points to the actual extension data. kinda makes sense.
i like that format extensions are meant to be somewhat limited. it can help keep Atom from spinning out of control. but the content-type extension has pitfalls. first, (using the
src attribute) the Atom document is just a pointer to the real thing. that means you need an additional GET in order to do anything useful. or the Atom document is now a 'compound' document. one that includes another document inside. and this document might have another mime type within it, too (see the
type attribute for the content element). that seems really scary. having to dig *into* the document to get the mime-type of the information within that document is just plain scary.
so i can see why the folks who build GData skipped the notion of content extensions and when right to format extensions - even though most all of what GData is doing with Atom *should* fall into the content extension model.
so i'm kinda at a tough spot here. i can see how Atom is very powerful as a standard mime-type that lots of folks can use. but i also see how it it very limited. as structured data, the Atom entry is simple, clean and portable. but most any extension of it will make it more complex, brittle, and less portable.