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

Re: URIs for the standard output and input streams

From: Paul Prescod <paul@prescod.net>
Date: Thu, 17 Jan 2008 17:06:51 -0800
Message-ID: <1cb725390801171706k2d7e1358pc6282ce9307f5d04@mail.gmail.com>
To: "Paul Prescod" <paul@prescod.net>, "James M Snell" <jasnell@gmail.com>, "Erik Wilde" <dret@berkeley.edu>, uri@w3.org

On Jan 15, 2008 3:28 PM, Noah Slater <nslater@bytesexual.org> wrote:
>
> On Tue, Jan 15, 2008 at 01:45:50PM -0800, Paul Prescod wrote:
> > As a practical note: if one asks one of today's XSLT to read stdin and
> > output it to stdout, would you rather it complained: "I've never heard
> > of the posix URI protocol scheme" or "http://purl.org/posix/stdin
> > returned 404"?
>
> This is misleading, the respective errors messages would be:
>
>   Could not resolve http://purl.org/posix/stdin.
>   Could not resolve std:in.
>
> Both are pretty "wrong" from a users POV and pretty horrendous either
> way.

I am too lazy to fire up various XSLT engines, but I have a few
URL-resolving tools on my desktop that give explicit error messages
for unknown protocols.

> ... The real question you should be asking in this situation is of
> the application designer, "why on earth are you using URIs for
> STDIN/STDOUT/STDERR when these things have a long and solid foundation
> in Unix history of being expressed using shell redirection or special
> devices on the local filesystem?"

That's hardly an argument for using HTTP URIs. Using file:/// URIs
seems fine to me, especially if it were put into an RFC somewhere.

 Paul Prescod
Received on Friday, 18 January 2008 01:07:01 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 13 January 2011 12:15:40 GMT