On Thu, 3 Feb 2005 23:39:51 -0700, Antone Roundy <[EMAIL PROTECTED]> wrote: > > On Thursday, February 3, 2005, at 11:07 PM, James Snell wrote: > > Figured I would formalize what I've been evangelizing the past couple > > of days. > > > > http://www.intertwingly.net/wiki/pie/PaceAggregationInSeparateSpec > > > The only reason why I'm not in favor of this (in fact, it occurred to > me a little before I saw this message) is that leaving things as they > are and deferring deciding how to handle aggregation would irreversibly > enshrine HeadInEntry into the format, which all of the current > organizational proposals are trying to replace. Deciding to > defer==deciding to do it HeadInEntry style. > >
I don't agree. HeadInEntry can be debated seprately on its own merits (or lack thereof). For Atom Entry Documents, there MUST be a way of providing some set of Feed metadata identifying a feed to which this entry belongs or is related. HeadInEntry accomplishes that goal, but is not the only way to achieve it. If HeadInEntry's primary motivator is to act as a support for aggregated feeds, then it to is affected by the PaceAggregationInSeparateSpec proposal and should likely also be removed from the core and deferred so long as the requirement stated above is still met (somehow) For example, it would be possible to achieve the linking requirement for entry documents using the link element rather than head, which could allow us to remove HeadInEntry. <Entry> <link rel="feed" href="..." /> </Entry> This, obviously, is not the only solution, but the point remains the same. If HeadInEntry doesn't make sense, PaceAggregationInSeparateSpec does nothing to require that it stay in the core spec. -- - James Snell http://www.snellspace.com [EMAIL PROTECTED]
