- From: Ian Davis <lists@iandavis.com>
- Date: Fri, 1 Oct 2010 15:59:00 +0100
- 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 UTC