W3C home > Mailing lists > Public > public-rdf-dawg-comments@w3.org > October 2010

Re: SPARQL 1.1 Protocol: Format of fault messages

From: Ian Davis <lists@iandavis.com>
Date: Fri, 1 Oct 2010 15:59:00 +0100
Message-ID: <AANLkTikOBe0_1Wx7_KGEUZV2hekEZBj2O93DPCaZn5cr@mail.gmail.com>
To: Richard Cyganiak <richard@cyganiak.de>
Cc: public-rdf-dawg-comments@w3.org
On Fri, Oct 1, 2010 at 3:53 PM, Richard Cyganiak <richard@cyganiak.de> wrote:
> Ian,
> On 1 Oct 2010, at 15:22, Ian Davis wrote:
>> On Wed, Sep 29, 2010 at 2:42 PM, Richard Cyganiak <richard@cyganiak.de>
>> wrote:
>>> My proposal would be:
>>> 1. To state in the HTTP binding that clients SHOULD use the XML fault
>>> message format when reporting faults.
>> I disagree with this position. A principle I adhere to is that errors
>> are debugged by humans not machines
> I agree with this principle. But a human cannot debug the error message if
> it isn't passed through all layers of the system up to the user.

That is outside the scope of the sparql protocol and is client
application dependent.

>> so therefore I favour plain text
>> error messages.
> Plain text is certainly one step forward from an HTML error page containing
> a Java stack trace.
>> Underconstraining the spec in this case is a better option.
> Underconstraining means that some implementations will continue to use HTML
> error pages, which do not allow reliable reporting of error messages to a
> human if the human uses a SPARQL library or SPARQL client to interact with
> the endpoint.
> Hence, the position you advocate makes it less likely that a user will
> actually see an error message.

That is up to the client application. Constraining the output puts
restrictions on the client applications that I don't think are

Received on Friday, 1 October 2010 15:05:26 UTC

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