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

On Sun, 2006-01-29 at 03:06 +0100, Bjoern Hoehrmann wrote:
> * Eric Prud'hommeaux wrote:
> >> >>   http://www.w3.org/TR/2005/WD-rdf-sparql-query-20050721/ 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.
]]
 -- 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.

?


-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/
D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E

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