Subject: Re: PaceIntrospection: Is another file format really needed?

From: Robert Sayre <[email-masked]>
Date: Thu, 01 Jul 2004 06:42:35 -0400

On 7/1/04 6:16 AM, "[email-masked]"
<[email-masked]> wrote:

> 
> Big +1 to Beechers proposal to reuse the <feed> format for introspection.
> 
> 
> As he has clearly demonstrated there is no conceptual difference between
> a feed format and an introspection format [1].
> 
> "When it smells like it,
> feels like it and looks like it, you call it what it is: <feed>".
> 

Should be obvious that it's not a feed. A feed is a frame of a pushed
stream. Introspection is comprehensive.

What problem is solved by making feed the root element for both purposes?
Why does it matter?

> I see <feed>
> as a general container for a list/bag of items.

I see WebDAV collections as the general case.

Robert Sayre

---

From: [email-masked]
Date: 1 Jul 2004 10:16:21 -0000

"When it smells like it,

Some
people argue that <feed> SHOULD be reserved exclusively for syndication [2]
and that urls pointing to <feed> documents SHOULD be subscribable.
Newsflash:
in the current API proposal, <feed> is already reused for browsing a list
of editable entries (draft and/or published posts). This type of <feed> can
even contain special <link> tags with @rel="start", "next" or "prev", which
are clearly browsing oriented. It makes no sense to subscribe to such a "next"
url.

Also, one of the original requirements, that has gotten this whole
atom thing started, was to come up with an archival format for weblogs. If
we follow the arguments of some of Beechers opponents, we should not use <feed>
format for this, but come up with another format, f.e. <archive>, because
an archive is clearly not intended for syndication.

Not limiting <feed>
for non-syndication related stuff, comes with an additional advantage, comparable
with view-sourceability. You can easily drop the non-syndicated <feed> in
your aggregator and have it parsed and rendered for you. Using a different
format requires your aggregator to explicitly support it.

I see <feed>
as a general container for a list/bag of items.
I don't want any restrictions
on the type of items in the feed: classic weblog posts, uploaded images, favorite
songs, description of API endpoints, classic linklog to other content. 
I
also don't want any semantic restrictions on <feed> itself. Whether it represents
a classical syndicated list of the latest reverse chronological weblog posts,
a list search results implicitly ordered by relevance, a list of my favorite
songs (top10) or a list of my API endpoints (no significant order) does not
matter.

If we really want to reserve <feed> for a classical syndicated
list, then we should write up a pace to change the spec and also be consistent
and come up with a different container element for the API post browsing format
and the archive browsing format.

It looks more to me that some people would
like to be able to differentiate between different types of lists.
I see
two possibilities:
1) extend <feed> with a @type attribute. This has the
same problems/benefits as link@rel: will the list of possible types be closed
or extensible?
2) introduce a base <list> or <collection> tag and have other
tags inherit from it: <feed>, <introspection>, <archive>, ... like in OO systems.

Not that I'm in favor of any of these suggestions. 
Locking down the semantics
of <feed> too much, negatively impacts future innovation 

Regards,

Peter

[1] http://www.imc.org/atom-syntax/mail-archive/msg06104.html
[2] http://www.imc.org/atom-syntax/mail-archive/msg06059.html