Re: Principled Reasoning. was: PaceAggregationDocument posted

[Antone Roundy]

On Tuesday, February 1, 2005, at 06:08  AM, Henry Story wrote:
...
Without taking the trouble to purchase and read the book you pointed 
to, here is my reasoning:

Antone Roundy wrote:
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?))
Stable paths to the elements of a feed.  Greatest simplicity--certainly 
the way that I implement my code, these are the simplest.

+0.5: PaceFeedRecursive without any more indirection than we already 
have, and only one level of recursion
Less stable paths to elements since you don't know in advance whether 
the entries will be in the outermost feed, or whether some or all of 
them will be inside another feed layer.

-0.8: Real RDF
I think we've discussed this one enough--RDF adds overhead that I don't 
value.  Others do.  I don't.

-1: PaceFeedRecursive as it stands (no extra indirection, but 
unlimited levels of recursion)
I don't want to have to deal with the added complexity of potentially 
unlimited recursion, nor do I see value in allowing it.  Sure, it can 
show you the long list of feeds that an entry traversed to get from its 
original feed to the current feed, but for those who value that more 
than I do, there MUST be a better way to do it.

-1.5: "add an attribute to atom:entry that indicates whether it 
refers to an instance of entry or another feed"
I'm not entirely sure what is intended by this, but it sounds like a 
combination of unlimited recursion and not even knowing whether and 
entry is an entry or a feed without examining it's attributes.  I 
assume this is basically "a feed is an entry, so let's use the same 
element for both"?

-2: PaceFeedRecursive w/ indirection at atom:feed, atom:entry, and 
atom:content
Potentially unlimited recursion, and potentially significantly more 
connections required to get a feed.  This may not be a big deal to 
applications that don't hand of HTML content to some widget for 
handling, and thus have to handle the details of loading images and 
such themselves, but for applications that do, it's much simpler to be 
able to get everything that they need to manipulate with one request 
and be done with it. We already have indirection for <content>, which I 
personally would be happier without. I'd like to avoid adding more.