[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Atom Info Proposal
--- Danny Ayers <danny666@xxxxxxxxxxx> wrote:
> The basic TAG argument against using a new URI
> scheme for this purpose is
> that it's not what URI schemes are for:
> "Authors of specifications SHOULD NOT introduce a
> new URI scheme when an
> existing scheme provides the desired properties of
> identifiers and their
> relation to resources." 
If all you want is an identifier then you never need
more than one URI scheme which eventually leads to
"HTTP URIs are all you ever need" which is exactly the
position of a lot of members of the W3C TAG despite
the reality of the WWW today. I call it "crack talk"
for a reason, it shows a disconnection from reality.
The other part of that sentence is key 'relation to
resources', the HTTP scheme does not describe the
relation to the resource we are interested in.
Mailto == You send mail to this resource
Feed == You subsccribe to this resource
Actually the relevant part of the W3C TAG document I
was speaking of was
"The use of unregistered URI schemes is discouraged
for a number of reasons:
* There is no generally accepted way to locate the
* Someone else may be using the scheme for other
* One should not expect that general-purpose software
will do anything useful with URIs of this scheme; the
network effect is lost."
All of the above apply to cooking up a new MIME type
as well. These are the only concrete disadvantages
expressed in that document, the rest is philosophical
although as evidenced by this thread some people take
the "How many angels can dance on the head of a pin?"
arguments very seriously.
> The http: scheme provides the desired properties of
> identifiers and their
> relation to resources.
So "HTTP URIs are all you ever need"? You're one of
them? That explains it.
> On the other hand, it is what mime types are for:
> "Generally the interpretation of bits on the
> Internet is governed by a
> protocol specification (e.g., HTTP/1.1 and FTP). In
> the case of HTTP, that
> specification delegates the interpretation of the
> message entity to a format
> specification (e.g., XHTML, CSS, PNG, XLink,
> RDF/XML, and SMIL animation),
> identified by MIME type." 
> Is there something special about syndication feeds
> compared to other
It isn't about interpreting the contents of the file
but about specifying an action against a particular
resource in this case "subscribe".
> > Being that I'm a believer in Occam's Razor a new
> > scheme makes more sense than a new MIME type since
> > takes less effort to get it to work from clients &
> > servers and doesn't encourage the dubious practice
> > placing the location of the feed in the document.
> Judging by Joe's investigations, the amount of work
> isn't particularly great
> either way. Being as I'm believer in following
> established best practices,
> it makes more sense not to throw a spanner in the
> What on earth is "dubious" about placing the
> identifier of the feed source
> in the feed?
I find the practice of putting locations in a file to
seem particularly fragile on the face of it. Imagine
if HTML actually specified that you placed the URL of
the page in the actual content and that browsers
should treat that as being just as valid as the
location the page was fetched from.
> There are advantages to doing this
> anyway (portability of the
> data), and there is already a precendent with RSS
> If you've already done the work on supporting this
> in your app, fair enough,
> I understand why you're pushing this.
> But I believe the Atom project should follow
> existing best practices (such
> as those encapsulated in TAG recommendations), and
> at least until the day
> feed: is a registered URI scheme its use should not
> be encouraged.
THINGS TO DO IF I BECOME AN EVIL OVERLORD #95
My dungeon will have its own qualified medical staff complete with bodyguards. That way if a prisoner becomes sick and his cellmate tells the guard it's an emergency, the guard will fetch a trauma team instead of opening up the cell for a look.
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.