Tim Bray wrote:
> So I think I'm +1 on PaceAggregationDocument.  (And I think 
> if we adopted that we could certainly lose PaceHeadInEntry, right Bob?)
        PaceAggregationDocument does not seem to me to add much benefit for
all the costs that it entails. I'm particularly concerned that adding a new
type of root document "aggregation" is likely to add enough to the
complexity of Atom that only a subset of developers will actually get around
to supporting this third type of document -- a type which doesn't exist in
the simple RSS aggregators that exist today.
        I see two non-compelling benefits to PaceAggregationDocument over
        1. In the case where a feed will contain more than one entry from a
"foreign" feed, you only have to include the atom:head data once. Thus,
there would be some increase in efficiency of encoding... However, as I've
pointed out on numerous occasions, this is a rare case. Typically, at
PubSub, we DO NOT see many cases where atom:head information is repeated in
a single instance of a feed.
        2. It is easier to see how one would sign an aggregated entry since
you don't muck with the contents of entry by inserting the HeadInEntry. This
problem, however, would be solved by canonicalization rules that said that
you should remove HeadInEntry before processing signatures, or, rules that
said that you had to insert HeadInEntry before signing anything, or filter
rules that allowed one to flag HeadInEntry as not part of the signed
content. (i.e. alternative solutions exist...)

        But, there are tremendous problems with the proposal:
        1. It looks like I can't intersperse "native" entries with
aggregated entries. This is a nuisance. I would like to see people insert
entries with "HeadInEntry" when they copy something from another feed into
their own feed. PaceAggregationDocument says that your feed must have either
"native" entries or "foreign" entries, but it can't have both. This seems
like an unnecessary constraint.
        2. As mentioned before, the introduction of a new level of
abstraction (i.e. aggregation) is likely to scare off a good proportion of
the aggregator developers. Current aggregators don't have the concept of
"aggregation" in them. Thus, new design and new architecture will be
required to address this Pace. On the other hand, staying with HeadInEntry
is much more gentle on the existing systems and thus much more likely to be
useful in the field.
        3. Since there will be at least some subset of aggregators that
won't understand the "aggregation" thing, it is likely that we'll have a
chicken and egg problem. No one will produce "aggregation" documents since
not everyone supports them. Thus, no one will support them since no one
generates them. On the other hand, HeadInEntry will slide past minimally
updated aggregators with no trouble -- i.e. folk who don't want to do the
work of handling the stuff properly will simply ignore the Head element...
(i.e. it would be suicide for producers like PubSub to support
        4. Massive changes need to be made to the specification when we
don't have a great deal of time left before we're supposed to be doing a
"Last Call." This is dangerous.
        -1. I really don't see any compelling benefit in exchange for the
tremendous risk and cost of accepting PaceAggregationDocument and dropping
HeadInEntry. Let's avoid adding to the levels of abstraction here and keep
it simple. We should have feeds and entries -- nothing else.

> I would like Atom to be more like Visual Basic and less like Lisp.
        As an ex-Visual Basic Product Manager, I think this would be a good
idea! Let's keep it simple and NOT accept PaceAggregationDocument. (Note to
reader: "Visual Basic .NET" is .NOT "Visual Basic"...

                bob wyman

-----Original Message-----
On Behalf Of Tim Bray
Sent: Thursday, February 03, 2005 9:38 PM
To: Atom Syntax
Subject: On organization and abstraction

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.  I would like 
it if the markup found in Atom documents was as close as possible to a 
typical human mental 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.

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.

Put another way, starting in 1986 there was a system called SGML, an 
ISO standard for marking up documents, which was awesome in its 
generality; the notion of what a delimiter was, what a character was, 
what an element was, all these things were entirely abstract.   So, it 
was almost impossible to implement and never really caught on.

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?)


Reply via email to