- From: Richard Newman <rnewman@twinql.com>
- Date: Sun, 3 Oct 2010 11:48:19 -0700
- To: Eric Prud'hommeaux <eric@w3.org>
- Cc: Richard Cyganiak <richard@cyganiak.de>, "public-rdf-dawg-comments@w3.org" <public-rdf-dawg-comments@w3.org>
>> And RDFa would be better than a magic class name. > > I'm afraid of demanding a generic RDFa parser for consumers of error > messages. (Of course, I'm happy to see that practice flourish on its > own.) Class was a poor choice, how about ID? New proposal: Call me old fashioned, but I think putting an RDFa parser in a client error handler is just as bad as putting in an HTML scraper! You want to invoke a parser and search for a magic ID or class within an arbitrarily large chunk of HTML whenever the server reports an error? Seriously, what's wrong with a modern, simple, structured format like: * JSON * form-encoded parameters * Turtle? I think that returning human-readable content for a machine request, OR VICE VERSA, is dumb. We have this magic technology called "content negotiation", so how about we use it? By all means put a header in the request which points to a resource that shows the error in a human readable form, or return multipart, but don't make everyone's ten-line shell scripts import an XSLT library to pull out an error line number.
Received on Sunday, 3 October 2010 23:08:44 UTC