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