At 11:48 PM -0800 2/3/05, James Snell wrote:
I agree with this so long as there is a core mechanism that allows a
standalone entry to identify the feed to which it belongs. That
mechanism does not have to be atom:head, but it does need to be part
of the core.
What if an entry is part of many feeds
> I have heard interesting arguments "It's all about the Entries, stupid!"
> that made the opposite assessment: namely that the entries are what is
> important, and that what feed an Entry is part of, is a accident of
> life.
>
> The idea there is that Entries are the stand alone entities. They c
On 4/2/05 6:48 PM, "James Snell" <[EMAIL PROTECTED]> wrote:
> I agree with this so long as there is a core mechanism that allows a
> standalone entry to identify the feed to which it belongs. That
> mechanism does not have to be atom:head, but it does need to be part
> of the core.
hmmm ... i
On 4/2/05 6:14 PM, "Robert Sayre" <[EMAIL PROTECTED]> wrote:
>> 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.
>
> That's right.
On 4 Feb 2005, at 09:05, James Snell wrote:
Bottom line: In my opinion, the parent feed is just as core to the
entries metadata as is the date it was updated or any of the other
core elements. It *could* be defined as an extension, but I feel it
is better handled in the core.
I have heard interest
On Fri, 04 Feb 2005 02:51:28 -0500, Robert Sayre <[EMAIL PROTECTED]> wrote:
> James Snell wrote:
> >>
> >>That's right. Besides, HeadInEntry is trivial to do as an extension, so
> >>there's no reason to leave it in.
> >>
> >
> >
> > I agree with this so long as there is a core mechanism that allow
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/PaceAggregationInSepa
James Snell wrote:
That's right. Besides, HeadInEntry is trivial to do as an extension, so
there's no reason to leave it in.
I agree with this so long as there is a core mechanism that allows a
standalone entry to identify the feed to which it belongs. That
mechanism does not have to be atom:head
On Fri, 04 Feb 2005 02:14:14 -0500, Robert Sayre <[EMAIL PROTECTED]> wrote:
>
> Antone Roundy wrote:
> >
> > 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 pro
Antone Roundy wrote:
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.
That's right. Besides, HeadInEntry is trivial to do as an extension,
On 4/2/05 5:07 PM, "James Snell" <[EMAIL PROTECTED]> wrote:
> Defer the definition of solutions for aggregated feeds to a separate
> Internet-Draft that is not a part of the Atom core syntax
> specification.
+1
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 befo
Figured I would formalize what I've been evangelizing the past couple of days.
http://www.intertwingly.net/wiki/pie/PaceAggregationInSeparateSpec
== Abstract ==
Defer the definition of solutions for aggregated feeds to a separate
Internet-Draft that is not a part of the Atom core syntax
speci
13 matches
Mail list logo
