On Feb 3, 2005, at 6:37 PM, Tim Bray wrote:
On reflection, I am growing very negative on almost all of the "Organization" Paces, including FeedRecursive, PaceEntriesElement, PaceCollection. Here's why: they represent to increase the level of abstraction in Atom, and in my experience, when the goal is interoperability across the network, abstraction hurts.
Hmm, I am either suffering from a bad case of ennui at the moment or I have just completely lost track of why atom needs a syndication format in the first place, or perhaps both. I think your summary reflects the email discussion, not the content of those paces.
I would like it if the markup found in Atom documents was as close as possible to a typical human mental model.
... of what? Personally, I think that is the main problem with all of the syndication formats -- they reify an interaction model rather than a data model.
The word "feed" has entered the vocabulary, even the non-geek vocabulary, and the notion that there are "things" (entries, stories, items, whatever) in "feeds" likewise. Any attempt to abstract away and generalize along the lines of "well, a feed is really an entry" or "well, an entry is really a feed" or "really, they're all just web resources and collections" is dangerously close to verging on Architecture Astronautics.
Entry is a data model that easily fits the XML format, assuming we ignore (for the moment) that entries and entry summaries are actually quite different. It would be nice if atom would define a distinct data model for entry first, before it got tied up in the details of how feeds are supposed to work.
Feed is an interaction model. It has more to do with the pipe in pipe-and-filter and the slash in client/server than the actual data passed in syndication. It carries a lot of semantic baggage, which is fine when that is the baggage you want to define. Other than that, it is just data, and all data looks like an entry because (so far) entry is completely undefined.
The purpose of PaceFeedRecursive is to simplify the feed data format by specifying a particular method of answering the data relationship question via XML containment. With all due respect, that is far more concrete a solution than what is currently in the draft, much easier to specify, and easily implemented by existing XML tools without the need for (or conflict with) RDF/XML.
My interest is in simplification, not abstraction. For example, the draft wastes a lot of text talking in the abstract about various constructs rather than simply defining one element for each of those constructs. Likewise, it talks about documents in a very abstract way, whereas it really should define entry first (and completely) before even talking about feed documents. It defines an element, atom:head, that serves no useful purpose whatsoever (XML is ordered and there is nothing preventing the syndication format from requiring that entries be provided last) while at the same time making a mess out of atom extensibility.
Having said all that, I have no objection to withdrawing PaceFeedRecursive and replacing it with a PaceHeadless that simply removes atom:head. My interest in atom is almost all on the back-end (content management) and that is the one piece that dirties a clean implementation via Jackrabbit (or any CMS based on JSR 170).
I think one reason that Robert has been exploring various alternatives is because atom is not clear on what an entry should be, which is a separate issue that has very little to do with the organization paces, and yet that is the one capability that distinguishes atom from the other syndication formats. OTOH, if people really want just a syndication format containing typical blog entries, then I strongly recommend just using the proposed RSS 1.1 and move on to greener pastures.
Cheers,
Roy T. Fielding <http://roy.gbiv.com/> Chief Scientist, Day Software <http://www.day.com/>
