Tuesday, May 16, 2006, 4:50:03 AM, James M Snell wrote:
> A few of the individuals on the WG had a problem with the placement of > the attributes due to various limitations of a few existing Atom 1.0 > implementations. That doesn't accurately state my problem with FTE. My concern is more general than the compatibility with a specific Atom implementations. The fact that the MS feed platform exhibits the issue is just a confirmation that the issue is more than a theoretical concern. An implementor that wants to /consume/ Atom (such as a feed API, or store), ought to be able to create an accurate implementation just by reading RFC4287. That document describes what properties entries, feeds, links, and extension elements have, and how they are represented in an Atom document. Using this it is possible to create a database schema or OO API that can represent feed data. My problem with FTE is that rather than using Atom's extension-point: the "Extension Element" (which an implementor of RFC4287 is likely to be capable of preserving), it uses the fact that Atom doesn't prohibit extra attributes to be included anywhere in the document. Is an API, feed store, or Atom Protocol implementation expected to preserve every attribute on every element, in addition to the core elements, and extension points? This might be practical on a few green-field Atom implementations, but it wouldn't be practical on systems than need to be retrofitted to support Atom. What I see as a problem is that reasonable implementations will not preserve Atom documents bit-for-bit, so they will need to explicitly support this draft if they don't want to corrupt data by dropping the thr:count attributes. By the letter of RFC4287 there is no problem with the draft, but practically there is something like a layering concern if an extension requires existing conformant implementations to be changed. Atom implementations with generic support for links and extensions, will find that this draft moves the goalposts of what a reasonable implementation is expected to handle, and I firmly believe that it should be possible for implementations to provide generic support for extensions in order to assist their adoption. Part of the problem might be caused by flaws in Atom's extensibility model, but that is all the more reason for extensions to be conservative in its use. > None of the folks I know of that have actually > implemented support for the extension has had any problems with them. Does that include any stateful feed APIs, or APP servers that aren't based on native XML back-ends? I notice that you said "implemented support" - that is fine for user-agents etc, but I don't believe that Atom infrastructure should be required to "implement support" for each new bit of content that publishers put into their feeds. -- Dave
