--On July 16, 2005 11:16:44 AM -0400 Robert Sayre <[EMAIL PROTECTED]> wrote:
> I found the criticism pathetic. A little lame, at least. You can't add precision and interoperability with innovation and extension. 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. 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. wunder -- Walter Underwood Principal Architect, Verity
