- From: Richard Cyganiak <richard@cyganiak.de>
- Date: Sun, 3 Oct 2010 16:26:21 +0100
- To: Ian Davis <lists@iandavis.com>
- Cc: "public-rdf-dawg-comments@w3.org" <public-rdf-dawg-comments@w3.org>
On 1 Oct 2010, at 21:26, Ian Davis wrote: >> 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 What the client does is the client's business. But when server implementors are encouraged to withhold critical information that many clients happen to need, then something is broken in the protocol. > and i am suggesting that overconstraining output formats > is not desireable. You say that the only possible options are “deliberately underconstraining” and “overconstraining”? Richard > > >> 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 Sunday, 3 October 2010 15:32:00 UTC