Re: [Fwd: SPARQL Protocol Review and Comments]

On Jan 4, 2006, at 2:03 PM, David Wood wrote:

>>>   OMISSION: In the "Malformed Query" paragraph of Section 2.1.4,  
>>> it is unclear what behavior is expected from a query processing  
>>> service if a malformed query does not result in a MalformedQuery  
>>> fault.  One way to solve this is to make such a fault mandatory  
>>> ("must" instead of "should").  If that is not done, the document  
>>> should say what kind of behavior to expect (is a  
>>> QueryRequestRefused OK?  How about returning nothing?).
>>
>> The WG explicitly decided to make MalformedQuery optional. I'm not  
>> clear why you think the document must say what must happen in the  
>> case where the spec says an implementation may do something or may  
>> not. Can you say more about this?
>
> Well, an implementor will have to make exactly that decision.   
> Either they will choose to implement MalformedQuery or they won't.   
> If they don't, then what should they do?  Return nothing?  Drop the  
> connection?  QueryRequestRefused?  As an implementor, I'd be  
> looking first to the spec for guidance.  Failing to find any, I'd  
> do what I thought best - which is another way of saying that I'd  
> make a different decision to someone else and hence potentially  
> cause an interoperability problem.

The WG discussed explicitly the case of requiring a service to always  
return MalformedQuery in cases where the query string isn't legal  
SPARQL. It didn't choose to specify that design.

In some cases an illegal SPARQL query will be *answered* -- because,  
say, some service implements a superset of SPARQL that includes, say,  
some syntactic no-no. Thus, the cases seem to be:

1. answer illegal SPARQL queries with some results
2. return MalformedQuery
3. the spec doesn't say what to do otherwise

I believe that's the design that spec describes and that the WG  
consents to.

Do you have some suggested text to make this clearer? (I think there  
was some desire not to explicitly say (1)... :>)

> Yes, we are saying the same thing.  I was suggesting, however, that  
> the language in Section 3.0 (under Security)  explicitly point a  
> reader to Section 2.1.4 to ease compliance.

Ah, yes, I've done that. Sorry, didn't grok that that was yr point  
hereabouts. So: Done.

> So I guess that's OK.  If it were me, I would probably add Content- 
> Type headers in /all/ the examples to be clear (in Section 2.2.1).

HTTP 1.1 says:

Any HTTP/1.1 message containing an entity-body SHOULD include a
Content-Type header field defining the media type of that body.

But none of those request messages contain entity-bodies, which leads  
me to believe that the SHOULD does not apply.

Cheers,
Kendall

Received on Wednesday, 4 January 2006 19:47:58 UTC