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

On Jan 30, 2006, at 9:22 AM, Dan Connolly wrote:

>> Well, it used to say "must not return 2xx", but, as you pointed out,
>> that's a bad leakage from the concrete into the abstract.
>>
>> What did we *mean* when we said "must not return 2xx"? Did we mean
>> "must not return Out Message"?
>
> I thought so, but if it's not clear enough from records, we'll
> have to discuss it again.

I draw another conclusion from the relevant available evidence (which  
includes two bits: the precise language we approved, and that that  
language constitutes an abstraction leakage): that we didn't mean  
anything nearly so crisp or definite. We've discovered now, or some  
of us seem to have, that we wanted to say "must not return Out", but  
that needs further ratification.

So I agree with yr next practical step, if that's any comfort. ;>

My problem, design wise, is that I want the spec to say clearly that  
if you get a bad query syntactically, you must return MalformedQuery.  
Which means you must not return Out Message. That's how WSDL works. I  
don't like specifying by implication (and it's a very subtle one,  
IMO) that there's this DMZ between MalformedQuery Fault and Out  
Message and we're fine if you do something in *that* space. Like  
crash or return QueryRequestRefused or what not.

If we don't require MalformedQuery as the fault for syntactically  
invalid query requests, what's the point of having the more specific  
fault?

In addition, the semantics, at least as I understand them, are  
slightly different. We say explicitly that in the case of  
QueryRequestRefused that the fault doesn't imply whether subsequent  
identical requests will or won't be refused too. But I think the sane  
design space re: malformed queries is that subsequent identical  
requests will not be processed because they are *still* illegal.

Cheers,
Kendall

Received on Monday, 30 January 2006 14:34:16 UTC