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.
There's a diff of your feed in PaceEntriesElement. It's pushing it to claim one is more interoperable than the other. You just asked for examples 15 minutes ago, why don't you wait for them?
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.
None of the "feed formats" out there use the term "feed" in their vocabularies.
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.
OK, define "Feed" and "Entry". We haven't done it yet.
I think calling other designs "astronautics" is unjustified. HeadInEntry is astronautics in the worst way--just nest them. But hey that's just my opinion. Also, atom:content is architecture astronautics. Base64? Please. HTML in atom:copyright? architecture astronautics.
Put another way, Adam Bosworth, likely one of the best computer programmers in the world, said "every time I add abstraction to an interface I lose 90% of the audience." I would like Atom to be more like Visual Basic and less like Lisp.
This is not a meaningful comparison to me.
On the other hand, the notion that sometimes you have collections of feeds is easy to understand, easy to verbalize, and widely evidenced in practice (cf PubSub & friends), if not perhaps widely seen outside of geekland. So I think I'm +1 on PaceAggregationDocument. (And I think if we adopted that we could certainly lose PaceHeadInEntry, right Bob?)
I think you should wait for examples.
Robert Sayre
