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

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

From: Bjoern Hoehrmann <derhoermi@gmx.net>
Date: Sun, 29 Jan 2006 03:06:32 +0100
To: Eric Prud'hommeaux <eric@w3.org>
Cc: public-rdf-dawg-comments@w3.org
Message-ID: <8p7ot1pocfmrbnou76mmmamc0e64edlksc@hive.bjoern.hoehrmann.de>

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

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.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 
Received on Sunday, 29 January 2006 02:05:45 GMT

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