- From: Dan Connolly <connolly@w3.org>
- Date: Sun, 29 Jan 2006 22:45:46 -0600
- To: Kendall Clark <kendall@monkeyfist.com>
- Cc: Bjoern Hoehrmann <derhoermi@gmx.net>, Eric Prud'hommeaux <eric@w3.org>, public-rdf-dawg-comments@w3.org
On Sun, 2006-01-29 at 18:12 -0500, Kendall Clark wrote: > On Jan 29, 2006, at 2:51 PM, Dan Connolly wrote: > > > [[ > > When a SPARQL query string is not a legal sequence of characters in > > the > > language defined by the SPARQL grammar, this fault message should be > > returned. An HTTP 2xx status code must not be returned. > > ]] > > -- http://www.w3.org/TR/rdf-sparql-protocol/ > > > > > > Hmm... perhaps the mention of HTTP 2xx is a bit of the HTTP concrete > > binding slipping in where we should be speaking of the abstract > > protocol. > > > > Kendall, how about making that > > > > ... a query Out Message message must not be returned. > > The spec already says that; it says clearly that our fault > propagation model is Fault Replaces Message. So if we say "must > return MalformedQuery" then that means that "Out Message must not be > returned". But "must return MalformedQuery" is stronger than "must not return Out Message". A server is allowed to refuse the query, or crash, or anything on a syntax error; the only thing it's _not_ allowed to do is to treat it like there was no syntax error. > One change I'd make is something like, s/"An HTTP 2xx status code > must not be returned."/"In the case of HTTP bindings, an HTTP 2xx > status code must not be returned."/ > > Is there any reason to state the fault propagation rule redundantly? I'm having trouble seeing the redundancy; where does it already say that Out Message must not be returned in the case of syntax errors? > At any rate, in 1.108 I've updated this section in response to this > discussion. -- Dan Connolly, W3C http://www.w3.org/People/Connolly/ D3C2 887B 0F92 6005 C541 0875 0F91 96DE 6E52 C29E
Received on Monday, 30 January 2006 04:45:51 UTC