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

On Sun, 2006-01-29 at 21:05 +0100, Bjoern Hoehrmann wrote:
> * Dan Connolly wrote:
> >The SPARQL QL spec only defines conformance of strings to the language,
> >and defines the answers to queries.
> >
> >If you have a command-line tool, that's a concrete instantiation
> >of the SPARQL protocol.
> I looked at the conformance section for "SPARQL Protocol service" but
> that requires implementation of HTTP/SOAP bindings.

Which part of the spec gives that impression? It's not supposed to.

>  As I understand the
> command line tool scenario, this would be independent of HTTP/SOAP, so
> the tool might not actually implement the HTTP/SOAP bindings so the
> conformance requirements might not actually apply to it. Perhaps there
> should be a general purpose conformance definitions for any tool that
> implements the abstract SPARQL protocol and a more concrete level for
> services that implement HTTP/SOAP bindings, etc.?

Hmm... yes, that might be one way to make it more clear. I had
a similar thought before we published but didn't manage to suggest
specific text.

>  If the general purpose
> definition then gives such a simple command line tool as example for
> what implementations to conformance criteria apply, and along with
> >> I couldn't really find one, there are some suggestions that this
> >> situation should yield in a MalformedQuery or QueryRequestRefused
> >> fault, but this doesn't seem so well-connected to me at the moment.
> >
> >Exactly: the protocol prohibits returning
> >results in the case of a syntax error in the query:
> >
> >[[
> >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.
> >]]
> > --
> >
> >
> >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.
> >
> >?
> this change, then I think error handling would be defined to my
> satisfaction :-)
Dan Connolly, W3C
D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E

Received on Sunday, 29 January 2006 20:37:45 UTC