On 7/16/05, Walter Underwood <[EMAIL PROTECTED]> wrote: > But there is a point buried under all that. What are the changes required > to support Atom? It looks complicated, but how hard is it? Here is a shot > at that information.
Thanks Walter, this is good... > For publishers, you need to be precise about the content. There are fallbacks, > where if it is any sort of HTML, send it as HTML, and if it isn't, send it > as text. The XHTML and XML options are there for extra control. > > Also, add an ID. It is OK for this to be a URL to the article as long as > it doesn't change later. That is, the article can move to a different URL, > but keep the ID the same. > > Add a modified date. The software probably already has this, and you can > fall back to the file last-modified if you have to. But if there is a > better date available, use it. > > The ID and date are required because they allows Atom clients and aggregators > to "get it right" when tracking entries, either in the same feed or when the > same entry shows up in multiple feeds. > > Extending Atom is different from extending RSS, because there are more > options. > The mechanical part of extensions are covered in the spec, to guarantee that > an Atom feed is still interoperable when it includes extensions. The political > part of extensions has two options: free innovation and standardization. > Anyone > can write an extension to Atom and use it. Or, they can propose a standard to > the IETF (or another body). The standards process usually means more review, > more interoperability, and more delay in deploying it. Sometimes, the delay > is worth it, and we hope that is true for Atom. Cheers, Danny. -- http://dannyayers.com
