W3C home > Mailing lists > Public > www-tag@w3.org > July 2009

Re: Proposed AWWW erratum on "information resources" [was Re: Fwd: Splitting vs. Interpreting]

From: Sean B. Palmer <sean@miscoranda.com>
Date: Mon, 13 Jul 2009 10:55:03 +0100
Message-ID: <b6bb4d890907130255l4197d69foea98fd92c279ed2d@mail.gmail.com>
To: David Booth <david@dbooth.org>
Cc: www-tag@w3.org
On Mon, Jul 13, 2009 at 3:24 AM, David Booth<david@dbooth.org> wrote:

> By design a URI identifies one resource.  The term "resource" is
> used in a general sense for whatever might be identified by a URI.

What would these sentences look like if they were written with
something more like the HTML 5 philosophy?

When you look at deployed usage, obviously you find that the http
scheme is used far more widely than any other scheme. What's the
second most commonly used scheme? mailto? file?

I'm sure TimBL now rues using mailto instead of mailbox or mbox or
some such. If you were to ask someone how many things a file URI
identifies, what would they say?

file:///tmp/example.txt

How many /tmp/example.txt files in the world? Okay, but it only refers
to the file on the current system. So in that case, is that a product
of behaviour or is it a reference system?

When browser manufacturers come up with new schemes, what kind of
things are they commonly making and why?

Safari redirects any http URI that returns application/atom+xml to the
same URI string only with feed in place of the http scheme. What the
heck is that all about? What is AWWW teaching us about this, or is
this not within AWWW's remit?

The most common use of a URI is clicking a link in HTML or pasting it
in your browser's address bar. And we're not talking most common by a
slight majority, of course.

So if we add up all the other uses of URIs, your mailboxes and your
file URIs and your XML namespaces and your URNs and tags and all kinds
of things, do they amount to the same body of usage as HTTP URIs used
in the browser?

And if we look at the commonalities amongst how these things are used
and implemented, what do we want to derive from that? What can we
learn, and what can we teach?

> An "information resource" is any resource that plays a role
> in the hypertext Web by producing "representations"

What server actually works on a model of resources producing
representations? What web framework works in this way? I've just been
through the Django tutorial, and I don't see resource being used in
there.

The simple use of current common servers is that files in directories
are exposed on the web, and maybe you can leave the file extensions
off. More complex use involves scripting. To someone coding the
backend to the latest Web 2.0 startup, does "information resources
produce representations" mean anything?

If not, where are the extents of the remit again?

If servers were commonly implemented in Analytica, Lusture, or Prolog,
that might be one thing. Heck, when I wrote an HTTP client
implementation in Python I tried to use all the right words from RFC
2616. What does your sentence tell me that RFC 2616 doesn't?

> Depending on one's perspective (or application) this may be
> viewed as a case in which the URI unambiguously identifies
> a resource that has multiple aspects or as a case of ambiguity,
> in which the artistic work and the web page are each deserving
> of their own distinct URIs.

Okay this, to me, is a very admirable attempt to resolve the current
peculiarities of the situation that we're working on here.

But why are you saying this? You're only saying this because of RDF,
not because of some common model of the web. And yet this is
Architecture of the World Wide Web.

So don't say that here. It's the wrong place!

Now there is an argument that the web was always like this, and that
the common and general model came first. But if that were so, we
wouldn't be having to define it now. And we wouldn't have "mailto".

-- 
Sean B. Palmer, http://inamidst.com/sbp/
Received on Monday, 13 July 2009 09:55:48 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:48:14 GMT