- From: Richard Cyganiak <richard@cyganiak.de>
- Date: Fri, 1 Oct 2010 20:38:09 +0100
- To: Ian Davis <lists@iandavis.com>
- Cc: public-rdf-dawg-comments@w3.org
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. 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 19:38:45 UTC