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 21:26:35 +0100
Message-ID: <AANLkTim2Qsk_UtuX=jmdnpgKsRWwAb6jnpYq4KOzzPRF@mail.gmail.com>
To: Richard Cyganiak <richard@cyganiak.de>
Cc: Ian Davis <lists@iandavis.com>, "public-rdf-dawg-comments@w3.org" <public-rdf-dawg-comments@w3.org>
On Friday, October 1, 2010, Richard Cyganiak <richard@cyganiak.de> wrote:
>
> 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.
>
That is not what I am saying. What the client does with an error is
out of scope and i am suggesting that overconstraining output formats
is not desireable.


> 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 20:27:18 GMT

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