Re: Adressing more error cases ?

hello andy.

On 2012-10-01 08:10 , "Andy Seaborne" <andy.seaborne@epimorphics.com>
wrote:
>I think this is an issue worth adding to the issues list.

absolutely, i think you should go forward and add this as an open issue.

>SPARQL-WG had a comment asking for defined error responses over and
>above HTTP Status code and message.  e.g. query parse error details - be
>more helpful to the end user than "400 Bad Request".

that's a common requirement nowadays when you're designing and building
HTTP-based services. HTTP error codes are useful and absolutely should be
used, but there often is more that could be included in the response.

>A brief search of existing practice showed no common community approach
>(even of status code) and decided to do nothing about it due to time
>pressures and also not wanting to create a SPARQL-specific solution. It
>was recognized as a valid feature request though.

http://tools.ietf.org/html/draft-nottingham-http-problem-01 is where mark
nottingham (cc'ed) has started to work on this. this draft is JSON only,
but the problem is worth solving generically, and then other
representations can follow.
https://github.com/dret/I-D-1/blob/master/http-problem/http-problem-01.xsd
is where i have started a super-simple XSD based on mark's draft, and
there very well could be something along similar lines for RDF. mark's
main goal is to use JSON as the logical model, and then XSD (and
potentially RDF) can be based on that model.

there were some discussions as to whether the model should only allow to
point to error classes, or whether it should also allow to point to
specific error incidents, so that a server keeping logs could, for
example, return a link identifying a specific incident, and then clients
could follow up wit that. all of this is still under discussion, but as
you can see, there is some community approach for doing this under
development.

cheers,

dret.

Received on Monday, 1 October 2012 16:11:09 UTC