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

On Jan 29, 2006, at 11:45 PM, Dan Connolly wrote:

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

Okay, I think this is the point where I disagree or don't understand.  
I very much do *not* agree with the suggestion here that there should  
be or that there is unspecified no man's land between returning a  
fault and returning Out. IMO that should be the *only* two conditions  
the spec contemplates or recommends.

It seems to me that we should just replace SHOULD return  
MalformedQuery with MUST return MalformedQuery. That implies MUST NOT  
return Out Message, but then so does the existing fault propagation  
rule.

I don't think there should be a third option of "crashing" -- that's  
just odd, IMO, to specify by silence. It's not our business to  
"permit" a server to crash. No one needs any help from us to do that.

And I thought the clear intent of having a more specific fault,  
MalformedQuery, was so that it would be returned on malformed queries  
rather than QueryRequestRefused.

One point I do agree with is the concrete layer was leaking up into  
the abstract with the language about HTTP 2xx. That's been removed in  
the latest draft, which now reads like this:
MalformedQuery

When the value of the query type is not a legal sequence of  
characters in the language defined by the SPARQL grammar, the  
MalformedQuery fault message should be returned. According to the  
Fault Replaces Message Rule, if a WSDL fault is returned, including  
MalformedQuery, an Out Message <strong>must not</strong> be returned.

When the MalformedQuery fault message is returned, query processing  
services must include explanatory, debugging, or other additional  
information for human consumption via the fault-details type defined  
in Excerpt 1.3.

Cheers,
Kendall

Received on Monday, 30 January 2006 14:12:38 UTC