Sorry, Bob I disagree. I tried to introduce a rigid concept of what a
feed is much earlier, and people pushed back; as a result, Atom
doesn't have a firm definition of the nature of a feed. As a result,
we can't go and say what it can't be at a later date.
Besides which, I think the use cases for Atom-as-list are powerful,
and just beginning to be seen. E.g., Netflix allows you to subscribe
to your Queue:
http://www.netflix.com/RSSFeeds
Are you saying that when/if Netflix switches over to Atom, they
shouldn't use it for the Queue?
It sounds like you've got use cases for Atom that other use cases
(e.g., lists) make difficult to work with. Banning those other use
cases makes things easier for you, but I don't think it's good for
Atom overall.
Cheers,
On 29/08/2005, at 10:49 PM, Bob Wyman wrote:
I’m sorry, but I can’t go on without complaining. Microsoft has
proposed extensions which turn RSS V2.0 feeds into lists and we’ve
got folk who are proposing much the same for Atom (i.e. stateful,
incremental or partitioned feeds)… I think they are wrong. Feeds
aren’t lists and Lists aren’t feeds. It seems to me that if you
want a “Top 10” list, then you should simply create an entry that
provides your Top 10. Then, insert that entry in your feed so that
the rest of us can read it. If you update the list, then just
replace the entry in your feed. If you create a new list (Top 34?)
then insert that in the feed along with the “Top10” list.
What is the problem? Why don’t folk see that lists are the stuff of
entries – not feeds? Remember, “It’s about the entries, Stupid…”
I think the reason we’ve got this pull to turn feeds into Lists is
simply because we don’t have a commonly accepted “list” schema. So,
the idea is to repurpose what we’ve got. Folk are too scared or
tired to try to get a new thing defined and through the process, so
they figure that they will just overload the definition of
something that already exists. I think that’s wrong. If we want
“Lists” then we should define lists and not muck about with Atom.
If everyone is too tired to do the job properly and define a real
list as a well defined schema for something that can be the payload
of a content element, then why not just use OPML as the list format?
What is a search engine or a matching engine supposed to return as
a result if it find a match for a user query in an entry that comes
from a list-feed? Should it return the entire feed or should it
return just the entry/item that contained the stuff in the users’
query? What should an aggregating intermediary like PubSub do when
it finds a match in an element of a list-feed? Is there some way to
return an entire feed without building a feed of feeds? Given that
no existing aggregator supports feeds as entries, how can an
intermediary aggregator/filter return something the client will
understand?
You might say that the search/matching engine should only present
the matching entry in its results. But, if you do that what happens
is that you lose the important semantic data that comes from
knowing the position the matched entry had in the original list-
feed. There is no way to preserve that order-dependence information
without private extensions at present.
I’m sorry but I simply can’t see that it makes sense to encourage
folk to break important rules of Atom by redefining feeds to be
lists. If we want “lists” we should define what they look like and
put them in entries. Keep your hands off the feeds. Feeds aren’t
lists – they are feeds.
bob wyman
--
Mark Nottingham Principal Technologist
Office of the CTO BEA Systems
--
Mark Nottingham http://www.mnot.net/
