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.


Roy T. Fielding                            <http://roy.gbiv.com/>
Chief Scientist, Day Software              <http://www.day.com/>

Reply via email to