[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [syndication] RFC: myPublicFeeds.opml
I'll second Joe's comment on not using a default document. This opens up the
door to all sorts of useless requests for documents that probably won't be
there.
Like, if there's a site at http://hosting.provider.example.com/user/joe/myblog
should http://hosting.provider.example.com/default.opml exist? Because you can
count on naive (or deliberate) queries against it. Just like favicon.ico. Ick.
If an app can't make a query into a <head> section <link> tag then how much
should we be trying to help it? What favors are we doing it? How are we
helping anything? Making it easier? To what end? I'm all for making the find
of feeds an easier process but I don't see using a default, fixed-name URI as
anything close to being correct.
Better to decide on something like a <link> tag with robust and extensible MIME
types (or a like idea).
<link> works, let's not reinvent it... badly.
Then there's the issue of not using opml. Attributes only? Puh-leeze.
-Bill Kearney
Syndic8.com
----- Original Message -----
From: "Joe Gregorio" <joe@bitworking.org>
To: <syndication@yahoogroups.com>
Sent: Monday, October 13, 2003 10:54 PM
Subject: Re: [syndication] RFC: myPublicFeeds.opml
> Dave Winer wrote:
> > A few weeks back, a question was raised by Jeremy Zawodny on behalf of
> > Yahoo. They have a large number of RSS feeds that they want to make
> > available to aggregators. They need a machine-readable format and a default
> > location for the file. Further, this file should be able to contain links to
> > other files in this format so that directories can be distributed.
> >
> > A format and location is proposed in this document.
> >
> > http://blogs.law.harvard.edu/tech/myPublicFeedsOpml
>
> Please reconsider your use of a fixed URI for the location
> of the OPML file. While this is the same mechanism
> that 'favicon.ico' and 'robots.txt' files use, the use
> of hardcoded URIs isn't a good idea. Tim Berners-Lee
> outlines some of the problems with such an approach
> in this message[1] and this issue is currently under
> consideration of the W3C Tag[2].
>
> Thanks,
> -joe
>
> [1] http://lists.w3.org/Archives/Public/www-tag/2003Feb/0093.html
> [2] http://www.w3.org/2001/tag/ilist#siteData-36