On Thu, 3 Feb 2005 23:08:43 -0500, Bob Wyman <[EMAIL PROTECTED]> wrote:
> 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?)
>         -1...
>         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.

+1 to this -1.  The aggregation element is not a necessary part of the
core and adds complexity without adding *significant* benefit to the

>         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.

This is precisely why I don't think this belongs in the core.  For
those who need this type of functionality, the opportunity exists for
them to create a separate Internet-Draft that describes how to
aggregate feeds -- without adding complexity to the core syntax by
introducing elements that the vast majority of users will *likely*
never use.  (I obviously base this assumption on the reasoning that
most Atom users will use it as a drop in replacement for RSS).

>         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. 

Well, I wouldn't go this far.  There is obviously a requirement for it
for some folks and those folks are likely to make good use of it. 
What I would rather see the WG do is take a minimalist approach with
this.  Right now, I see aggregated feeds falling into that limited 20%
of use cases that could be done, but aren't necessarily critical to be
done.  Aggregation could be defined as an extension to Atom, and
later, based on an analysis of its implementation over time, can be
merged into the Atom core if deemed appropriate.  Merging it into the
core now does not guarantee that its adoption and use will be any
greater than if it were done as an extension.

>         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. Big +1.  

>         -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.

One point, HeadInEntry solves the problem of having a standalone Atom
Entry document be able to reference a feed of which it is a part. 
Unless I'm misreading something, if PaceAggregationDocument gets rid
of the ability to put Head elements in the entry, don't we lose this
capability?  (this is something that is important, for instance, in my
Atom Notification Protocol proposal)

> > 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"...

Aargh! VB... it burns!  (sorry, temporary flashback to past hell. 
Sorry Bob, VB was an excellent product, I just was forced to be
witness to some extremely bad uses of it.  Nightmares, I tell you,

>                 bob wyman
- James Snell

Reply via email to