- From: Richard Cyganiak <richard@cyganiak.de>
- Date: Sun, 3 Oct 2010 21:55:48 +0100
- To: Richard Newman <rnewman@twinql.com>
- Cc: Eric Prud'hommeaux <eric@w3.org>, "public-rdf-dawg-comments@w3.org" <public-rdf-dawg-comments@w3.org>
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