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
This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:52:11 UTC