W3C home > Mailing lists > Public > public-rdf-dawg-comments@w3.org > January 2006

Re: [OK?] Re: SPARQL: Error handling

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
Message-Id: <1138596347.4991.959.camel@dirk.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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:14:50 GMT