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

Re: SPARQL 1.1 Protocol: Format of fault messages

From: Steve Harris <steve.harris@garlik.com>
Date: Mon, 4 Oct 2010 07:50:47 +0100
Cc: Eric Prud'hommeaux <eric@w3.org>, Richard Cyganiak <richard@cyganiak.de>, "public-rdf-dawg-comments@w3.org" <public-rdf-dawg-comments@w3.org>
Message-Id: <FD783946-FEC6-4516-B072-B122843FC6FF@garlik.com>
To: Richard Newman <rnewman@twinql.com>
On 2010-10-03, at 19:48, Richard Newman wrote:

> 
>>> 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?

The problem with conneg is that I issue a SPARQL request and say I want Plain text, XML, Turtle in order, but I don't get to specify a different ordering for errors v's correct results.

> 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.

One option would be to reuse the SPARQL results format(s) to return errors. It tends to be what apache and co. do, after all (reuse the success format for error conditions).

I have a lot of 10 line (or less) shell scripts that call SPARQL processors/endpoints. I tend to conneg tsv or similar from the endpoint to make it easier to process in pipes, but when something goes wrong I just dump the error to stderr, and it's up to a human to figure out the problem. 10 line shell scripts don't often have sophisticated error recovery :) So in this case conneg will work, but perhaps some people want XML for their shell scripts.

- Steve

-- 
Steve Harris, CTO, Garlik Limited
1-3 Halford Road, Richmond, TW10 6AW, UK
+44 20 8439 8203  http://www.garlik.com/
Registered in England and Wales 535 7233 VAT # 849 0517 11
Registered office: Thames House, Portsmouth Road, Esher, Surrey, KT10 9AD
Received on Monday, 4 October 2010 07:21:44 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 4 October 2010 07:21:46 GMT