- From: Noah Slater <nslater@bytesexual.org>
- Date: Tue, 15 Jan 2008 16:29:00 +0000
- To: Elliotte Rusty Harold <elharo@metalab.unc.edu>
- Cc: uri@w3.org
> The problem is URIs are supposed to be UNIFORM Resource Identifiers. Yes, but there are two different type of resource, informational and non-informational. STDIN is a generic concept and would fall squarly into the non-information resource category. As such, it is perfectly OK to use one identifier to describe /all/ STDINs. That identifier could be "STDIN", "QWERTYUIOP", "CN0145" or "http://example.com/stdin" - it really doesn't matter. A rose by any other name... ... given that any name will do, you may as well choose a name that you can "follow with your nose" and GET some description of the resource. HTTP works perfectly for this. There is no instance were you can GET (in HTTP semantics) "a" STDIN or "the" STDIN. It is not a normal (information) resource like a web page. If you GET http://example.com/posix/stdin and you receive an RDF graph with a POSIX onology describing what STDIN /means/ then this is a major win. Saying that "std:in" looks nicer is not an objective technical argument and you would have, I am guessing, a hard time convinving IANA to register such a scheme. > I suspect the suggestion to use the file URI scheme might really be > the correct one. In fact, it might already work on Unix. No, this would not work. -- 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 16:29:03 UTC