[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: AD Evaluation of draft-ietf-atompub-protocol-11
On 12/16/06, A. Pagaltzis <pagaltzis@xxxxxx> wrote:
Extending the Atom envelope is a strategy of last resort.
It is important to remember that not all processors of Atom data will know what to do with unexpected metadata in the envelope. Thus, unexpected envelope fields will often simply be stripped off and thrown to the bit bucket. If you want data to stay with your "content," it is best to put it in the <content/>... Sometimes, it may be appropriate to extend the envelope, however, one should not do so without a really compelling case.
Envelope extensions typically require "fetching time" or database structure modifications in consuming applications if those extensions are to be supported. This is because many feed consumers have distinct fields in their databases or internal structures for each of the envelope elements and then just have a single field for content. Also, the code for manipulating envelope fields is usually distinctly different from the code used to manipulate and process <content/>. So, if you create a new envelope field, you require a great deal of code to be modified for that field to be supported. On the other hand, if something can be slipped into <content/> you'll see it being stored immediately and have the opportunity for downstream consumers (display routines, etc.) to provide support for the additional data. (For instance, you might write a GreaseMonkey script to do interesting things with stuff encoded in <content/> even though the "backend" of the application knows nothing about it.)
My personal feeling is that many of the proposals (but not all) for envelope extensions are derived from what I consider to be unfortunate precedent set in the RSS world where all sorts of random stuff has been pushed into the envelope since in RSS the <description/> field is so under-specified that it isn't really possible to think of it as something which can be structured. Fortunately, the field has moved forward since legacy RSS was defined and we've got better methods that can be used with Atom. There are undoubtedly still things that might go in the envelope, but not as many as some folk might think.