Please find attached a draft of a proposal. Thoughts? On Thu, Jul 05, 2001 at 08:39:43PM -0700, Mark Nottingham wrote: > > As many have noticed, one of the biggest problems with syndication is > locating feeds. Often, you'll find a resource you'd like to obtain a > feed for, only to spend minutes (or hours!) scanning the HTML source, > "about" section of the site, and the top and bottom of every page. > > This problem has been discussed before. I'd like to propose a > solution, and try to move something forward. > > To start, here are what I believe should be the core requirements for > such a mechanism: > > * It should be syndication format-agnostic > > * Futhermore, it should support the communication of multiple, > alternate feed formats for a particular resource > > * It should support discovery by both people who are browsing the > site (the 'find the feed for this page' scenario) and automated > processes (the 'syndication spider' and 'browser automatic feed > location' scenarios) > > * It should allow feeds to be sent to aggregators both on the client > machine, or located at an arbitrary URI on the network > > * It should be easy to integrate the mechanism into already deployed > web browsers > > * It should have a path to integration into next-generation web > browsers > > * It should not require the storage of state or preferences in a > centralized registry or location; the only participants in > interactions should be the server where the channel is hosted, the > browser, and the target aggregator (on the client or on the > network) > > Thoughts? I think I have a candidate for how to do this, but I want > to get feedback on the premises first... > > Cheers, > > > -- > Mark Nottingham > http://www.mnot.net/ > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > > -- Mark Nottingham http://www.mnot.net/Title: No title
As XML Syndication (making machine-readable Web content) grows, one of the problems facing its users is discovering the different forms of syndication available for their favourite source. Typically, current users must search a Web site, its HTML source and mail the Webmaster to find a syndicated form of its content.
This document proposes a method which allows Webmasters to signal what syndication formats are available in a manner that is easy for both humans and automated clients to use.
For more information about XML Syndication, please see [XXX].
Syndication Discovery aims to make three distinct scenarios possible;
These goals are achieved through the use of a two-step process; the publication of a channel list, and linking to the channel list from the resource which the channel (or channels) therein describes.
Note that this mechanism does NOT provide a means of discovering all of the syndication feeds a site offers through one central registry. Future developments in the Semantic Web [XXX], standardized metadata discovery (like the /w3c/ convention in P3P [XXX]), Web Services [XXX] (through Web Service discovery mechanisms like UDDI) or other areas may change or add to the ways that channel lists are discovered in the future.
A channel list is an XML file which identifies all of the representations of a particular resource that are available, along with their formats. All of the syndication channels contained in a channel list are considered equivalent; that is, although they may be in different formats, and although some may even contain data or metadata that others do not (for example, if a particular format supports image references, etc.), all channels in a channel list should contain basically the same information. If a site has a number of syndication feeds, a channel list should be identified for each separate feed.
Channel lists consist of a root channels element, which
contains any number of channel child elements. Each channel is
namespace-qualified to identify the format of the channel, and contains text
indicating the URI of the channel.
For example;
<?xml version="1.0"?>
<channels xmlns="http://www.purl.org/syndicationlist/1.0"
xmlns:rss1="http://www.purl.org/rss/1.0"
xmlns:rss092="http://www.scripting.com/rss0.92"
>
<rss092:channel>http://www.example.com/news.rss</rss092:channel>
<rss1:channel>http://www.example.com/news.rdf</rss1:channel>
</channels>
This indicates that the resource that links to it is available in two other formats; RSS 0.92 and RSS 1.0.
Channel Lists should be identifiable by a URI, and typically will be on the same server as the HTML representation of the channel content as well as the channels themselves, although this is not required.
Channel lists must be returned with the following Content-Type:
Content-Type: text/xml+syndicationlist
This allows the receiver to dispatch the channel list to the appropriate software, and is especially important to enable browsers to send the channel list to a helper application, which can then decide which format is most appropriate, and forward its URI to the user's chosen aggregator.
Once a channel list is created for a feed, it is linked to from the appropriate resource(s) on the site in two different ways. These links facilitate both human and machine discovery of syndication feeds, and should be used in conjunction.
The first form is with a LINK tag in the HEAD section of HTML;
<LINK REL="channelList" TYPE="text/xml+syndicationlist" HREF="">
The second form uses a traditional A link, with the HREF pointing to the channel list URI.
<A HREF="">syndication</A>
It is anticipated that the most immediately feasible form of syndication
discovery will be scenario #1, as above. To enable this, current browsers
will need to be configured to dispatch the
text/xml+syndicationlist Content-Type to a helper application,
which can then either redirect the appropriate channel or channel list URI to
a local program, or to a Web Service or similar function which represents the
user's chosen aggregator on the Web. This allows the <a>
style of linking to channel lists to function.
Browser implementors should consider integrating a UI hint which indicates
the presence of a syndication feed (by watching for the
<link> tag), and allow users to effect similar actions to
those outlined above.
revision 0.2