Roy T. Fielding wrote:
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.
Agree. *looks for the well-formed log entry.
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.
Now that you've written PaceRemoveHeadElement (Note to Bob: it still does what you want), I think that is what will probably happen. Secondly, it would be easy to turn it into PaceFeedRecursive at some point in the future.
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.
Person, Date, and Text constructs all save space because they avoid repetitive requirements, and they match up nicely with the Relax NG. I'm pretty sure the group has agreed to drop Service constructs, and mnot has already moved atom:id into an element definition for -06.
Robert Sayre
