Re: Principled Reasoning. was: PaceAggregationDocument posted

[Antone Roundy]

On Tuesday, February 1, 2005, at 01:05  PM, Antone Roundy wrote:
-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.

Having looked at PaceEntriesElement, my perspective on this has changed 
slightly--indirection at atom:feed would be good, but by using link, 
not recursive feeds.  The blog post and comments use case is indeed one 
that isn't addressed by the current draft.  I think that building the 
ability to stuff a whole hierarchical forum into a recursive feed into 
the core format would add an unnecessary burden of complexity for 
people who  just want flat feeds like what we've been working with to 
this point.  Linking to a feed of comments from an entry (whether a 
blog or forum post) would be a simple way to enable such hierarchical 
organization without making the format more complex.  So, rather than 
this:

<feed>
        <id>1</id>
        <entries>
                <feed>
                        <id>2</id>
                        <content />
                        <entries>
                                <entry />
                                <entry />
                        </entries>
                </feed>
                <entry />
                <entry />
        </entries>
</feed>
You could do this:
<feed>
        <id>1</id>
        <entry>
                <content />
                <link rel="comments" type="application/atom+xml" ... />
        </entry>
        <entry />
        <entry />
</feed>
and:
<feed>
        <id>2</td>
        <entry />
        <entry />
</feed>
That's been suggested before, but for some reason hasn't been pursued 
vigorously enough to get into the current draft.  What's missing is 
that the content of the entry that's at the top of the second feed is 
missing from the feed.  According to my mental model of a feed, the 
correct thing to do would be to put something like <link rel="about" 
href="URL of entry" /> into feed 2's head.  But that would be too 
inconvenient, so I'd rather allow atom:content and atom:summary in 
atom:feed for these cases.

And lest anyone say "See! A feed is an entry!", I still don't see it 
that way.  Instead, I see this as a convenient way to spawn a feed 
related to an entry when appropriate, and a feed has been given some of 
the attributes of an entry for convenience.