Re: [Fwd: SPARQL Protocol Review and Comments]

On Wed, 2006-01-04 at 14:47 -0500, Kendall Clark wrote:
> 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

We did decide against that:

"for queries that are not SPARQL Query Strings, you should return
MalformedQuery and you must not return 2xx"
 -- http://www.w3.org/2005/08/16-dawg-minutes#item04


> 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
> 
-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/
D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E

Received on Wednesday, 4 January 2006 20:53:33 UTC