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: Sun, 3 Oct 2010 16:26:21 +0100
Cc: "public-rdf-dawg-comments@w3.org" <public-rdf-dawg-comments@w3.org>
Message-Id: <8840286A-DCAB-4318-A45F-1D45DE097C81@cyganiak.de>
To: Ian Davis <lists@iandavis.com>

On 1 Oct 2010, at 21:26, Ian Davis wrote:
>> Reliable communication of error conditions to protocol clients is  
>> in scope of any protocol.
>>
> That is not what I am saying. What the client does with an error is
> out of scope

What the client does is the client's business. But when server  
implementors are encouraged to withhold critical information that many  
clients happen to need, then something is broken in the protocol.

> and i am suggesting that overconstraining output formats
> is not desireable.

You say that the only possible options are “deliberately  
underconstraining” and “overconstraining”?

Richard




>
>
>> 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 Sunday, 3 October 2010 15:32:00 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 3 October 2010 15:32:01 GMT