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

Ian
Received on Friday, 1 October 2010 15:05:26 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 1 October 2010 15:05:26 GMT