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

Re: SPARQL 1.1 Protocol: Format of fault messages

From: Richard Cyganiak <richard@cyganiak.de>
Date: Fri, 1 Oct 2010 20:38:09 +0100
Cc: public-rdf-dawg-comments@w3.org
Message-Id: <FDA8EC72-59D2-4B7F-A5E6-EC3FB2231D7F@cyganiak.de>
To: Ian Davis <lists@iandavis.com>

On 1 Oct 2010, at 15:59, Ian Davis wrote:
>> 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.

Reliable communication of error conditions to protocol clients is in  
scope of any protocol.

Richard



>
>
>>
>>> 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 19:38:45 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 1 October 2010 19:38:45 GMT