[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: One reason we have duplicates entries is that we have duplicate feeds...


Bob Wyman wrote:
Robert Sayre wrote:

You can point to an alternate feed like this
<link rel="alternate" type="some/feed" href="..." />
Of course, you can't have two alternates with the same media type...


	Yes, you can point to an alternate. However, all you are doing at
that point is establishing equivalence between the two. The "alternate"
mechanism doesn't provide you with a way to say which feed is preferred.

Well, if you publish Atom 1.0, RSS 1.0 and RSS 2.0 feeds, they should all be equivalent. Which is "preferred" is on the end-user's hands.

Say you publish an interview as text/plain, text/html and application/msword. Each end-user will choose his/her preferred version. What you can do to indicate your preferred version (otherwise putting up some web page that links to each version and tell the end-user which one you prefer) is to put them all at the same location (URI) and use content negotiation, associating q-values on the server side; but client provided q-values and accepted media types will be used to serve the *client's* preferred version anyway.

> It also does not allow you to establish that one feed is a sub-set of another
(as in the case of "category" feeds.).

Well, actually yes: use atom:source in your entries.
Either you consider "category" feeds to be the "primary feeds" and use atom:source in the "whole site" feed (and you'll have to choose a "primary category" as well for entries belonging to two or more categories); or you treat the "whole site" feed as the primary feed and put atom:source elements in your "category" feeds.

However, I'm +1 on defining some new kind of link@rel. They don't have to be put in the spec, they could only be some "generally used values", defined and encouraged by the Atom WG without begin in the Atom 1.0 spec (and maybe be added to a future Atom version)

	If you provide an old-format Atom feed today, will you continue to
do so after Atom V1.0 is released? If not, how will automated readers or
crawlers discover that it is no longer necessary to seek your old feed or
that you have a new feed that replaces it? If you had supported an RSS feed
in the past but now decided to switch to an Atom feed, how would the
aggregators discover that this was your intention without causing a break in
their ability to process your posts?

If you keep the same URI, I think there won't be much problem, many readers/aggregators handling several syndication formats.
You might eventually continue to serve RSS as well and use content negotiation for a while, waiting for the Atom 1.0 format to be widely used.

If you change the URI (say you used to have http://example.net/myfeed.rss and now move to http://example.net/myfeed.atom), send an HTTP "301 Moved Permanently" status to redirect clients to the new URI.

Anyway, if you stop delivering some content in some media type, you can't expect not to "cause a break in their ability to process your [content]".

So in a few words: +1 for what you propose, not necessarily to be added to the Atom spec, but the problem you pointed out is not /that/ grave.

--
Thomas Broyer