W3C home > Mailing lists > Public > uri@w3.org > January 2008

Re: URIs for the standard output and input streams

From: Tony Hammond <tony.hammond@gmail.com>
Date: Tue, 15 Jan 2008 13:32:54 +0000
Message-ID: <c107aff50801150532p65939165h6d2e09d036e644d0@mail.gmail.com>
To: uri@w3.org

Well, maybe the Rolling Stones had it right some time back:

    "I said, Hey! You! Get off of my cloud
    Hey! You! Get off of my cloud
    Hey! You! Get off of my cloud
    Don't hang around 'cause two's a crowd
    On my cloud, baby"

But sincerely, this HTTP-at-all-costs advocacy is not only very, very
silly - it's just plain boorish. If there is to be a preferred
identifier scheme for Web-based resource identifiers and a preferred
intent for those identifiers (i.e. dereference), then maybe the we
should be restricting ourselves to HRLs alone instead of URIs. Maybe
URI is too lofty a conceit.

As for the "more URI schemes considered harmful" line of argument,
well that is just a total canard. The primary rationale for URIs is to
fulfill an identification role for resources. It is not for
"dispatching" onto some network retrieval action. (Although that is a
jolly useful piece of functionality which none would deny.) A web
app's first duty is to recognize a string *in context* as being a
valid URI, i.e. as conforming to the URI syntax. (If it recognizes the
URI scheme as an IANA registered scheme then that is a bonus though
the registry is dynamically updated.) The decision to dispatch on a
given URI scheme will depend on local knowledge built into the app.
There is nothing, however, that prevents an app from recognizing the
context and syntax of a string as marking it out as a URI. There is
nothing, therefore, that should impede or otherwise restrict the
number of URI schemes that may be registered.



On Tue, Jan 15, 2008 at 11:52:54AM +0000, Jeremy Carroll wrote:
> stdin, stdout and stderr are OS provided protocols, and not the network
> protocol HTTP - hence an HTTP uri seems wholly inappropriate.

STDIN isn't a protocol like http:// is, it's a feature of POSIX
systems that applications can hook into natively without having to
dereference anything. All that is needed is an identifier.

> While say the geoloc vs http argument has merits on both sides - the "HTTP
> is the only necessary protocol" argument is taken to absurdity with
> http://purl.org/std/in

I disagree. URIs are opaque and "http://purl.org/std/in" is just an
identifier for the concept of STDIN, which is it's self a
non-information resource.

The "http://" is not important, it's /just/ a name.

Additionally, by using http:// we get to place a metadata profile at a
network resolvable location so that clients who do attempt to
derefference it will get a description of the resource.

Noah Slater <http://bytesexual.org/>

"Creativity can be a social contribution, but only in so far as
society is free to use the results." - R. Stallman
Received on Tuesday, 15 January 2008 13:33:23 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:11 UTC