Re: [Fwd: SPARQL Protocol Review and Comments]

On 4 Jan2006, at 12:39, Kendall Clark wrote:
> d about some of off-line, but I owe you a public response. All of  
> the following changes can be found in the latest editor's draft:
>
> $Revision: 1.83 $ of $Date: 2006/01/04 17:38:08 $
> http://www.w3.org/2001/sw/DataAccess/proto-wd/

Thanks for the response.  Happy new year to all.

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

>>   SUGGESTION:  Section 3.0, "Policy Considerations", states that  
>> query services MAY refuse to process certain query requests.  In  
>> that case, I suggest making it clear that they MUST do so as  
>> defined in Section 2.1.4.
>
> Hmm. Section 3.0 says that some queries, because of various policy  
> considerations, can be simply not processed by services. So, a  
> query asks a service to retrieve a 1GB KB over the Web, and the  
> service is under heavy load, then that service can simply refused  
> to process that request. Section 2.1.4 tells implementers how,  
> having made that decision, it is to be carried out: namely, by  
> returning QueryRequestRefused.
>
> So, there's two parts:
>
>  1. a service *may* refuse to process a request
>  2. if it so chooses, then it *must* return QueryRequestRefused

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.

>>   QUESTION:  Was the Content-Type of the example query intended to  
>> be "application/x-www-form-urlencoded"?
>
> Which example?

Err.  Umm...  I couldn't find it after a quick look :(  I do note  
where the doc says:

"The HTTP binding for the query operation contains two parts. The  
first uses [HTTP] GET with application/x-www-form-urlencoded  
serialization and UTF-8 encoding. The second uses [HTTP] POST with  
application/x-www-form-urlencoded serialization and UTF-8 encoding.  
The GET binding should be used except in cases where the URL-encoded  
query exceeds practicable limits, in which case the POST binding  
should be used."

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


Regards,
Dave