W3C home > Mailing lists > Public > public-ldp-wg@w3.org > October 2012

Re: Adressing more error cases ?

From: Wilde, Erik <Erik.Wilde@emc.com>
Date: Mon, 1 Oct 2012 12:09:35 -0400
To: Andy Seaborne <andy.seaborne@epimorphics.com>, "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>
CC: "mnot@mnot.net" <mnot@mnot.net>
Message-ID: <CC8F0C2F.8C37%erik.wilde@emc.com>
hello andy.

On 2012-10-01 08:10 , "Andy Seaborne" <andy.seaborne@epimorphics.com>
>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.
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


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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:17:32 UTC