Re: URIs for the standard output and input streams

Well stated. std:in, std:out and std:err are perfect; using 
http://whatever is ugly and buys us little

- James

Tony Hammond wrote:
> 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.
> 
> Cheers,
> 
> Tony
> 
> 
> 
> 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.
>

Received on Tuesday, 15 January 2008 15:26:15 UTC