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: Sun, 3 Oct 2010 21:55:48 +0100
Cc: Eric Prud'hommeaux <eric@w3.org>, "public-rdf-dawg-comments@w3.org" <public-rdf-dawg-comments@w3.org>
Message-Id: <4075A190-7123-4416-90A8-BBC9912BD0DC@cyganiak.de>
To: Richard Newman <rnewman@twinql.com>

On 3 Oct 2010, at 19:48, Richard Newman wrote:
> Seriously, what's wrong with a modern, simple, structured format like:
> * JSON
> * form-encoded parameters
> * Turtle?

* XML?

The SPARQL Result Format already is XML, so clients already have a  
parser and are using it.

Clients don't necessarily have a JSON or Turtle parser on board, and  
while especially JSON parsers are easy to get by these days, and are  
just a few K of code, demanding one just for error messages would be a  
bit strange IMO.

Form-encoded parameters would be fine with me; they are sufficiently  
human-readable for debugging, are easily parsed, and are nicely  
extensible towards line/column numbers and similar.

> We have this magic technology called "content negotiation", so how  
> about we use it?

+1. The spec could recommend one of the simple machine-readable  
options as the normal format, and mention that implementors MAY offer  
other options via content negotiation.


> 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 21:02:55 UTC

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