Subject: PaceAggregationDocument posted

From: Antone Roundy <[email-masked]>
Date: Mon, 31 Jan 2005 15:23:38 -0700

http://www.intertwingly.net/wiki/pie/PaceAggregationDocument

PaceAggregationDocument is an alternative to PaceFeedRecursive (and was 
largely cloned from PaceFeedRecursive).  Both replace head-in-entry as 
a way to carry an entry's original context with it when aggregating 
feeds.  The primary differences between the two are:

1) PaceFeedRecursive enables aggregation by allowing the document 
element feed to contain other feeds (but those feeds may not contain 
yet other feeds).  PaceAggregationDocument instead creates a new 
element--atom:aggregation--to act as a container for multiple feeds.

2) The outermost feed as defined by PaceFeedRecursive has its own 
metadata (everything that currently appears as a child of atom:head).  
PaceAggregationDocument's document element doesn't have its own 
metadata--it's just a container.  We can discuss whether it should have 
it's own metadata.

3) PaceFeedRecursive allows atom:entry to appear as a sibling of 
atom:feed in an aggregate feed.  PaceAggregationDocument only allows 
atom:feed as a child of atom:aggregation, so an aggregation is only an 
aggregation--not also the original source of entries.

4) PaceFeedRecursive eliminates atom:head.  PaceAggregationDocument 
does not, though it leaves the door open for discussing whether to do 
so.

My current position on the question: I am undecided between 
PaceAggregationDocument and PaceHeadInEntry.  I prefer 
PaceAggregationDocument over PaceFeedRecursive, but not strongly.

---

From: Antone Roundy <[email-masked]>
Date: Mon, 31 Jan 2005 15:55:30 -0700

On Monday, January 31, 2005, at 03:23  PM, Antone Roundy wrote:
> yet other feeds).

Correction: PaceFeedRecursive doesn't contain any language limiting the 
depth of recursion.

---

From: "Roy T. Fielding" <[email-masked]>
Date: Mon, 31 Jan 2005 16:19:55 -0800

> does not, though it leaves the door open for discussing whether to do 

That is kind of pointless. The main purpose of PaceFeedRecursive
is to use XML hierarchy to clearly define the association between
mark-up and what is being marked, thus answering the extensibility
question and defining the Atom->RDF mapping.  The main obstacle
to that is atom:head.

Recursive is just the simplest way to implement (and visualize)
the solution, at least for those folks who understand that it is
okay to limit the rendering of recursive feeds to some
implementation-defined number of levels.  If not recursive,
then it makes far more sense to simply remove atom:head and
either add a peer to atom:entry (e.g., atom:feedptr) or
simply add an attribute to atom:entry that indicates whether
it refers to an instance of entry or another feed.

....Roy

---

From: Graham <[email-masked]>
Date: Tue, 1 Feb 2005 00:52:21 +0000

Both proposals suck equally. HeadInEntry is surprisingly elegant when 
you get to thinking about it.

Graham

---

From: Robert Sayre <[email-masked]>
Date: Mon, 31 Jan 2005 22:51:00 -0500

> you get to thinking about it.

My preferences are as follows:

1.) PaceFeedRecursive w/ indirection at atom:feed, atom:entry, and 
atom:content
2.) RDF (instead of the fake RDF in #4)
3.) "add an attribute to atom:entry that indicates whether it refers to 
an instance of entry or another feed"
4.) current draft (head in entry and all that)
5.) PaceAggregationDocument

Robert Sayre

---

From: Antone Roundy <[email-masked]>
Date: Mon, 31 Jan 2005 21:16:42 -0700

On Monday, January 31, 2005, at 08:51  PM, Robert Sayre wrote:
> 3.) "add an attribute to atom:entry that indicates whether it refers 
> to an instance of entry or another feed"
My preferences:

+1: Current draft or PaceAggregationDocument (with or without 
atom:feed/atom:head and with or without metadata for atom:aggregation 
(atom:aggregation/atom:head?))
+0.5: PaceFeedRecursive without any more indirection than we already 
have, and only one level of recursion
-0.8: Real RDF
-1: PaceFeedRecursive as it stands (no extra indirection, but unlimited 
levels of recursion)
-1.5: "add an attribute to atom:entry that indicates whether it refers 
to an instance of entry or another feed"
-2: PaceFeedRecursive w/ indirection at atom:feed, atom:entry, and 
atom:content

---

From: Robert Sayre <[email-masked]>
Date: Mon, 31 Jan 2005 23:24:51 -0500

Antone Roundy wrote:

> -1: PaceFeedRecursive as it stands (no extra indirection, but 
> unlimited levels of recursion)

Cool, great to getting to know you better.

I'd like to add the following:

vi and Emacs suck equally. Visual Studio is surprisingly elegant when 
you get to thinking about it.

Scheme and Java suck equally. Common Lisp is surprisingly elegant when 
you get to thinking about it.

Python and Perl suck equally. Ruby is surprisingly elegant when you get 
to thinking about it.

OS X and Windows suck equally. Linux is surprisingly elegant when you 
get to thinking about it.

Robert Sayre