[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [syndication] site-wide metadata [was: RFC: myPublicFeeds.opml]
- To: syndication@yahoogroups.com
- Subject: Re: [syndication] site-wide metadata [was: RFC: myPublicFeeds.opml]
- From: Mark Nottingham <mnot@mnot.net>
- Date: Wed, 15 Oct 2003 13:23:41 -0700
- In-reply-to: <213701c3934f$d8d038d0$6401a8c0@murphy3>
On Wednesday, October 15, 2003, at 12:09 PM, Dave Winer wrote:
1. I work at Harvard, not UserLand. And I just work there, I can't
make them
do anything in particular.
Sorry, old habit; I saw this linked from http://www.scripting.com/
which also has a lot of UserLand references, etc. How's academia
treating you?
2. The train left the station on this with robots.txt. The world
survived.
Sorry, I noticed. I wasn't supposed to, I guess, but I did.
It's all fine and good if robots.txt is the only thing that does this;
the problem comes in when everybody and their brother wants a mechanism
for site-wide metadata as well.
Question of clarification - do you intend for your mechanism to only be
at the top level of a site (i.e., one-per-authority) or for each
directory (i.e., one-per-path-segment)?
3. Instead of impeding growth, it would be great if the W3C did things
to
foster growth, like declare one top-level name to be reserved, and then
establish a web app to reserve names within that folder. It would take
a
weekend to write and deploy. I'll help.
They don't want to encourage what they (and many others) consider a bad
practice (and always have, BTW; P3P was allowed to go ahead with a
well-known location because no-one had a better answer, and there was a
lot of pressure for us to finish).
So, they won't do it until a workable option is available. Considering
that approaches that doesn't use a well-known location (e.g., Tim
Bray's HTTP header or my OPTIONS * approach) will AFAIK require Web
server configurations and perhaps software to change, I'm not too
optimistic, but if the community makes enough noise about this, you
never know what will be accomplished.
4.Further, only optional functionality should depend on these names,
nothing
mission critical (as previous applications have done).
One person's optional is another's mission-critical. Also, it doesn't
help for server-side load issues.
That's about all I want to say on this. I've noticed how much effort
one has
to put in to innovate here. This mail list is broken. Sorry, I forgot.
;->
I think it's working quite well; the purpose of this list is to foster
discussion, and that's what's happening. Indeed, more ground has been
covered here and on a few blogs than has in more formal settings in a
much larger amount of time. OTOH, if you want people to accept what you
want unquestioningly, I agree that you'll have problems on this list.
What if you said that you'd use the well-known location trick
temporarily, until something better is standardised and widely
available? Win-win.
Cheers,
--
Mark Nottingham http://www.mnot.net/