On Sun, 6 Jan 2008, Brian Smith wrote:
[snip]
Could you please give an example of such harm. The rationale for James's design is that it is the least harmful of all the alternatives, especially the FeedSync design.
Because the "feed abstraction" is that much more complicated. Why is a bit of metadata as a child of an "entry" element a non-starter? "deleted","moved", etc. are just attributes of an entry (and there IS a category element available...). Obviously I don't believe that a tomstone is anything but another kind (or state) of (an) entry.
The feed abstraction for Atom and RSS is one of a feed+metadata and a stream of entries+metadata - this has been the case for the last 10 years, and it isn't going to change now. The model is not, as would be required if were to mix entry and feed metadata, a feed+metadata and a stream of entries+metadata + associations with every feed document that that entry entries+has ever been part of just in case there is some sort of misplaced entry metadata hidden at feed level, so that clients looking at an entry can manually reimplement the sliding window mechanism for tombstones or whatever. Urgh.Implementations are free to ignore the tombstones and have the exact same behavior that they have now. That is the primary benefit of this design over the FeedSync one.
Yes, and then what sort of extension will be proposed for the folks who want a "deleted" feature, but need/want to keep the deleted entry AS an entry.
--peter
- Brian