Re: New Pace: PaceAggregationInSeparateSpec
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? What if someone takes an entry and puts it into a new feed? It seems like the WG has coalesced on the idea that entries can stand alone, and can also be combined into one or (many) more feeds. Any pointer from an entry to a feed would be almost instantly out-of-date, wouldn't it? The outward pointer or pointer mechanism doesn't feel like part of the core of describing entries and how to create a feed of entries. --Paul Hoffman, Director --Internet Mail Consortium
Re: New Pace: PaceAggregationInSeparateSpec
> 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 can > be made to be part of any feed whatsoever. A feed in this > conceptualization, > is a little like a search engine result listing where the pages they > refer > to are like entries (notice that search engine results pages are just a > type of web page too). Which feed your entry appears in will depend very > much on the type of query the user of the search engine made. > OK, I can buy that, as long as that is indeed how things are supposed to be defined. Note, however, that the Atom syntax spec focuses on feeds as resources and that entries just happen to be contained in feeds. e.g. from Section 1: "Atom is an XML-based document format which describes lists of related information known as "feeds". Feeds are composed of a number of items, known as "entries", each with an extensible set of attached metadata." If the assertion that the entries are the standalone entities is correct, then the text in the spec needs to be changed to reflect that assertion. Granting the assumption that the entries are the standalone entities and feeds are merely just a convenient container for entries, the identification of containing parent-feed becomes less important. The need to identify where the entity came from, however, obviously still remains.. although not necessarily as a core requirement. Back to the original point about HeadInEntry: HeadInEntry is not required to achieve the origin/container identification, regardless of whether or not origin/container identification should be part of the core. If there are no other reasons why HeadInEntry should remain in the core, then by all means, rip that sucker out of there. PaceAggregationInSeparateSpec by no means locks it in place. > Of course if an entry has a tag such as "origin" (which used to be on > the > table) then the entry it points to would be part of the metadata of the > entry and so be a legitimate way of creating special selection of > entries. > > > Henry Story > > -- - James Snell http://www.snellspace.com [EMAIL PROTECTED]
Re: New Pace: PaceAggregationInSeparateSpec
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 ... it could even be: e.
Re: New Pace: PaceAggregationInSeparateSpec
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. Besides, HeadInEntry is trivial to do as an extension, so > there's no reason to leave it in. +1 to HeadInEntry being removed from the 1.0 spec. e.
Re: New Pace: PaceAggregationInSeparateSpec
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 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 can be made to be part of any feed whatsoever. A feed in this conceptualization, is a little like a search engine result listing where the pages they refer to are like entries (notice that search engine results pages are just a type of web page too). Which feed your entry appears in will depend very much on the type of query the user of the search engine made. Of course if an entry has a tag such as "origin" (which used to be on the table) then the entry it points to would be part of the metadata of the entry and so be a legitimate way of creating special selection of entries. Henry Story
Re: New Pace: PaceAggregationInSeparateSpec
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 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. > > Why? > As soon as I posted I knew you were going to come back and ask that :-) As defined by the spec, entries exist either independently or within the context of a feed. The state of being associated with a feed is a part of the core metadata about an entry given this definition. In standalone entries, absent HeadInEntry, there is no mechanism of expressing whether or not the entry is associated with a feed. The only assumption that can be made in that case, is that a standalone entry is not associated with any feed. As examples, the Atom-XMPP-Notify and Atom-HTTP-Notify proposals both illustrate cases where this assumption is not acceptable. Granted, however, both of these proposals could just as easily use some shared non-core extension element to identify the parent feed. 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. > Robert Sayre > -- - James Snell http://www.snellspace.com [EMAIL PROTECTED]
Re: New Pace: PaceAggregationInSeparateSpec
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. 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]
Re: New Pace: PaceAggregationInSeparateSpec
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, but it does need to be part of the core. Why? Robert Sayre
Re: New Pace: PaceAggregationInSeparateSpec
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 proposals are trying to replace. > > 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, but it does need to be part of the core. > Robert Sayre > > -- - James Snell http://www.snellspace.com [EMAIL PROTECTED]
Re: New Pace: PaceAggregationInSeparateSpec
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, so there's no reason to leave it in. Robert Sayre
Re: New Pace: PaceAggregationInSeparateSpec
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
Re: New Pace: PaceAggregationInSeparateSpec
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.
New Pace: PaceAggregationInSeparateSpec
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 specification. == Status == Proposed (by [JamesSnell]) == Rationale == Aggregated feeds, while important, are currently not supported by the existing RSS mechanisms and are relatively rare in comparison to their single feed cousins. Given the guidelines for proposals set forth in this Wiki, this alone would justify moving the aggregation stuff off to a separate document, at least for now. * The 80/20 rule: If a feature will only be used by a small number of people, and will create extra work and headaches for everyone else, it probably doesn't belong in the core spec. * Pick stuff that's already been proven to work and be interoperable, and writing it down in a clean, clear way * Keep it simple: The simplest thing that can possibly work tends to be preferred over more complex solutions. I absolutely acknowledge that there are a subset of folks for whom aggregated feeds are very important. But this is a subset. Let that subset document their ideas in a separate Internet-Draft; let them implement those ideas and build momentum for them; then let us later come back later and discuss the merits of merging those ideas into the core. == Proposal == (see abstract) == Impacts == Defers PageAggregationDocument and PageFeedRecursive to a separate Internet-Draft * Lets Atom 1.0 get out the door faster. * Lets folks gain valuable implementation experience before committing to major changes to the Atom core spec to support what is currently an edge case * Keeps the Atom core simple == Notes == -- - James Snell http://www.snellspace.com [EMAIL PROTECTED]
