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

Re: SPARQL 1.1 Protocol: Format of fault messages

From: Richard Cyganiak <richard@cyganiak.de>
Date: Mon, 4 Oct 2010 12:58:51 +0100
Cc: Richard Newman <rnewman@twinql.com>, Eric Prud'hommeaux <eric@w3.org>, "public-rdf-dawg-comments@w3.org" <public-rdf-dawg-comments@w3.org>
Message-Id: <EBAC0CE4-F242-4714-A652-7C04464999BE@cyganiak.de>
To: Steve Harris <steve.harris@garlik.com>

On 4 Oct 2010, at 07:50, Steve Harris wrote:
> 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.

That's a fair point.

>> 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 find that idea quite compelling.

Maybe something like:

<?xml version="1.0"?>
<sparql xmlns="http://www.w3.org/2005/sparql-results#">
   <head>
     <malformedQuery>Parse error at [5:17], unexpected ' '</ 
malformedQuery>
   </head>
</sparql>

This would require a small extension of the XML result format.

One could still say that this format is a SHOULD; and that  
specifications for other result formats (e.g., the JSON result format)  
MAY bring their own error formats; and that processors MAY use any  
other format as well, but then they MUST include the X-Malformed-Query  
HTTP header (so that Ian can send text/plain and Eric can send  
application/xhtml+xml).

Best,
Richard



> 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 12:01:11 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 4 October 2010 12:01:11 GMT