David Powell wrote: > > What practical implications does this have? This is just a > distinction without a difference. > > If you start putting entry metadata elements at <feed> level > this simply won't work. Perhaps Windows Feed Platform is > faulty for not anticipating James's latest proposal, but I > don't think so.
If Windows Feed Platform ignores the tombstones it will be working just as James intended. If Windows Feed Platform chokes on the tombstones then it isn't compliant with the atom specification. > No there isn't, and practically anything is syntactically > valid according to the spec. But, I'm not replying to these > posts to save people from reading the spec, but to highlight > the harmful effects of these extensions. I believe that > violating the separation between entry and feed metadata > breaks a large and useful category of applications and that > approving such behaviour would be extremely damaging to the > Atom community. 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. > 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. - Brian
