On Thursday, February 3, 2005, at 09:08 PM, Bob Wyman wrote:
I see two non-compelling benefits to PaceAggregationDocument overIn the past few days, I've been reading people talking about different ways emerging for people to combine or divide the content of their own feeds based on what's going to end up in our <category> element and by other methods. (See http://www.mezzoblue.com/archives/2005/02/03/information_/index.php). This kind of thinking could very well point the way to the emergence of more feeds being aggregated from a small number of sources. Time will tell.
PaceHeadInEntry:
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 sinceWhen you remove HeadInEntry, do you remove from the start of the <head> tag to the end of the </head> tag, or do you also take out the newline after the </head> tag...? We'd have to be certain we defined the process precisely and that people followed it precisely. The benefit of avoiding that complexity may be a little greater than it appears at first blush.
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:You could always have a feed in the aggregation for the "native" entries. But you do have a point--the thing that would be more difficult would be to occasionally import external content into a feed that is not always an aggregation--you'd either have to temporarily become an aggregation, refer to it rather than importing it, or forget it. Out of curiosity though, how common is it to import entries wholesale from external sources as opposed to referring to them?
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 ofCurrent aggregators don't have the concept of HeadInEntry either. With HeadInEntry, it's easier because you don't have to deal with one more level of hierarchy--if you don't know about HeadInEntry and just ignore it, you can still function. However, that leads to erroneously attributing an entry to the wrong feed. To get it right, aggregators are going to have to understand SOMETHING new. The containment in an aggregation document would be more intuitively obvious in meaning than seeing a head in an entry and figuring out that it was the head from the feed that used to surround the entry.
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.
4. Massive changes need to be made to the specification when weIf we don't want to reorganize the spec to do this, we can create PaceAggregationDocument2 which does it more simply by making only four changes:
don't have a great deal of time left before we're supposed to be doing a
"Last Call." This is dangerous.
1) add an aggregation element 2) state that it requires an atom:head 3) state that it can contain any number of atom:feeds 4) state that it can be the document element
