On Sunday, December 17, 2006, at 11:02PM, "Bob Wyman" <[EMAIL PROTECTED]> wrote:
>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. I think the distinction to make is whether the information in question is necessary for whatever process the entries participate in. Processes should be able to work with the entries without having to dig into the actual content. Jan > >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. > >bob wyman >
