W3C home > Mailing lists > Public > public-rdf-dawg-comments@w3.org > October 2010

Re: SPARQL 1.1 Protocol: Format of fault messages

From: Richard Newman <rnewman@twinql.com>
Date: Sun, 3 Oct 2010 11:48:19 -0700
Message-Id: <E5A46A40-A0A4-49D9-8BFC-03A51442D09B@twinql.com>
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:

* 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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:52:11 UTC