Re: [syndication] RFC: myPublicFeeds.opml

[Dan Brickley <daniel.brickley@bristol.ac.uk>]

* Bill Kearney <ml_yahoo@ideaspace.net> [2003-10-14 08:21-0400]
> > You say it "isn't a good idea" and don't explain why.
> 
> But explain why it is a good idea.  There's already a well-established practice
> of using <link> tags.  Why not make use of this already well engineered idea?
> Why reinvent it?

+1

inventing names and persuading the world to use them isn't going to
scale, for all the kinds of things we'll want "config files" for. Better
to go with the long-term trend of hyperlinking. We know how to read a
page and find LINK RELs.

At the moment, only robots.txt (pretty ancient) and favicons.ico buck
this trend, hmm maybe some P3P stuff as well. But with each new spec
that does this it becomes seemingly more acceptable. I fear this'll get 
us into a situation where I no longer get to choose how to manage my 
own Web namespaces. Eg. I might decide to map /sitemap to a page about 
sitemaps, only to discover that in 2005 the sitemapping community
declare this to be the 'discovery page' for XML sitemap formats. Ditto 
/mp3 or whatever.

Another against is the management of larger sites, where access to the
root directory for some domain is strongly controlled. Linking
facilitates decentralisation. We can cascade control of XML config files 
down into site subsections by cross-referencing them amongst themselves,
LINK REL'ing them from appropriate HTML pages, and rdfs:seeAlso'ing them
from RDF descriptions.
> 
> > TBL says it isn't a good idea because the owner of the site owns the
> > namespace, which makes sense, but robots.txt et al already offer features
> > based on common file names.

robots.txt was the wrong way to do it. If folk _really_ want to go this
route I'd suggest using the bit of the namespace already grabbed by
robots.txt, ie. robots.feeds.txt etc., to keep things in the same
"area". But it's still pretty gross.

> > Unless the architecture anticipates this, and has a single config file that
> > can be used by multiple applications (the Registry on Windows, for example)
> > then you end up with multiple files. Not much mystery to this. Even then
> > it's the same solution, just moved down one level.

But we defer decisions about where/how to put this data to the sites
hosting, rather than impose a decision from above. We don't need a
single location, just some conventions for discoverying those locations.

[...]

Dan