Re: SPARQL 1.1 Protocol: Format of fault messages

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.

Richard



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