Re: SPARQL 1.1 Protocol: Format of fault messages

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