This seems similar to what exists in Really Simply Discoverability in the
individual <api.../> element [1].
-----
# <api> has 4 required attributes.
* "preferred" is a boolean and takes either "true" or "false". The point is
to allow weblog software to list all the APIs supported, but choose which one
to "recommend" to the client software. Only one API should set as prefered.
-----
This couldn't be another/new attribute on the site feed autodiscovery links? As
opposed to the link rel types proposed below.
-David
[1] - http://archipelago.phrasewise.com/rsd#ODoxNjozMSBBTQdbdb
Quoting Bob Wyman <[EMAIL PROTECTED]>:
<snip>
> One thing that we could do in the short term to reduce the number of
> duplicate feeds is to define metadata that would allow feed publishers to
> describe the relationships between feeds and describe the content of
> different feeds. If, when reading a feed, I could be informed that this feed
> was a duplicate of another "preferred" feed, I could switch to the preferred
> feed and stop reading the duplicate. I could use this knowledge to map
> subscriptions to the duplicate feeds to their equivalents. This would be
> wonderful in the transition from Atom .03 to Atom V1.0... (i.e. if the old
> format feed could point to the newer version, we'd all eventually stop
> reading the old format feed.)
> For instance:
>
> <link rel="preferred-feed" type="application/atom+xml"
> href="http://example.org/feed.xml"/>
> <link rel="subset-of" type="application/atom+xml"
> href="http://example.org/fullfeed.xml"/>
>
> If these link rel types are acceptable to people, we should probably
> define equivelant syntax to be inserted into old Atom feeds to allow the
> transition to the new atom as well as define extensions to the various
> flavors of RSS. If we can implement this minor extension, we may see many
> fewer duplicate feeds being consumed and thus fewer duplicate entries.
> Comments?
>
> bob wyman
>
> [1] http://www.tbray.org/ongoing/When/200x/2005/04/03/Atom-Now
>
>
