- From: Paul Prescod <paul@prescod.net>
- Date: Thu, 17 Jan 2008 17:06:51 -0800
- 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 UTC