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

On Sun, 2006-01-29 at 03:06 +0100, Bjoern Hoehrmann wrote:
> * Eric Prud'hommeaux wrote:
> >> >> seems
> >> >> to be quite unclear about error handling. There is some discussion
> >> >> about handling type errors in 11.2 but that refers to XQuery for
> >> >> the definition of type errors and otherwise just says when they
> >> >> occur, not what implementations must do when they encounter them.
> >> >> 
> >> >> For syntax errors (i.e., queries that do not match the production
> >> >> rules) no error handling seems to be defined either.
> >> >
> >> >Strings that do not match the production rules are not part
> >> >of the SPARQL query language; why would you expect the specification
> >> >to say anything about them?
> >> 
> >> I expect the specification to define conformance requirements for
> >> implementations and SPARQL implementations will have to deal with
> >> illegal input. This is not uncommon in fact, XML 1.0 for example
> >> defines this in detail. I am not sure why it would be useful to
> >> allow SPARQL implementations to handle illegal input in different
> >> ways but if that is intended, it should be very clear from the
> >> draft.
> >
> >Do you feel that resolving the "W3C QA Guidelines conformance" thread
> >will resolve this thread?
> 11.2.1 has "If any of these steps fails, the invocation generates an
> error. The effects of type errors are defined in Filter Evaluation."
> There seems to be a disconnect here, either the invocation generates
> a type error in which case it should say that instead of just "error"
> or it does not generate a type in which case the reference to type
> errors seems odd.
> 11.3 has "Note that per the xpath definitions, fn:not and
> op:numeric-equal produce an error if their argument is an error."
> s/xpath/XPath/; I'm not sure whether you can pass "an error" as
> argument to these functions?
> 11.4.8 has "Note: see section 11.2, Filter Evaluation, for the the ||
> operator's treatment type errors." Should this say "... of type errors"?
> same for the next section.
> Now I have a command line tool that takes two arguments, some
> application/rdf+xml resource and some application/sparql-query
> resource. The application/sparql-query resource has a malformed
> SPARQL query (say it lacks a " to terminate a string literal);
> the command line tool now recovers from this error and returns
> results as application/sparql-results+xml resource. Is there any
> conformance criteria in the SPARQL drafts this tool violates?

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 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

Kendall, how about making that

  ... a query Out Message message must not be returned.


Dan Connolly, W3C
D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E

Received on Sunday, 29 January 2006 19:51:52 UTC