Brian Smith wrote: > Peter Keane wrote: > > James Snell wrote: > > > I disagree. Feeds already contain several sets of things... > > > entries, authors, contributors, links, and categories. Adding a > > > new set of things is not a "huge" change by any stretch of > > > the imagination. > > > > But those are all clearly "metadata about the feed" i.e. they > > have a well-defined relationship with the feed. Same with > > entries -- the conceptual model (although not spelled out in > > the spec) is easy to grok. > > Being able to abstract out a conceptual model is *really* > > important and it's what makes Atom so useful. What sort of > > things are these tombstones? > > Well, their most obvious relationship is to an entry not the > > feed itself. > > What practical implications does this have? This is just a distinction > without a difference.
No. What a metadata element is "about" has no direct implications on implementations, but the implied life-cycle of the metadata and entities involved (entry and feed) do. Say you poll a feed URI twice, you might get back entry 1,2,3 in the first poll, and entry 2,3,4 in the second poll. Stateful Atom implementations will need to store entries that aren't in the most recent polling of the feed URI. This requires entry and feed state to be decoupled. A good example is Microsoft's Feed Platform, which downloads feeds, and presents them to client applications via an API that allows the entries of a feed (including metadata elements) to be accessed as XML structures. 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. > The specification says: > > Child elements of atom:entry, atom:feed, > atom:source, and Person constructs are considered Metadata elements > and are described below. Child elements of Person constructs are > considered to apply to the construct. The role of other foreign > markup is undefined by this specification. > > There is no "about the feed" there. 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. 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 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. -- Dave
