Re: [Fwd: SPARQL Protocol Review and Comments]

On Sep 26, 2005, at 11:55 AM, Dan Connolly wrote:

> Hi all,
>
> I reviewed [1], which at the time was the current version, pointed  
> to by  [2].

Hi David,

We talked 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/

>   My suggestion for resolution is to comply with the final WSDL 2.0  
> specification (now in Last Call).

Since yr review, WS-Desc redesigned a good bit of WSDL 2.0,  
particularly the HTTP bindings, which I believe now have gone into  
another LC period. At any rate, the SPARQL Protocol spec will (soon)  
reflect legal usages of WSDL 2.0. Which we can do without changing  
our design because the HTTP bindings changed significantly and in  
ways that accommodate our design.

> 2.  Important/Technical
>
>   ERROR: In the first paragraph of Section 2.1.2, "called st:query- 
> result" should be changed to "called st:query-request".
>
>   ERROR:  The element name "query-result" in Figure 1.1, "XML  
> Schema fragment", should be changed to "query-request".

Done and don (and fixed in a few other places, too. Global search-and- 
replace is more trouble than it's worth!)

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

>   SUGGESTION:  Section 2.2 says "if a SPARQL Protocol service  
> supports HTTP bindings, it must support the bindings as described  
> in sparql-protocol-query.wsdl.  A SPARQL Protocol service may  
> support other interfaces."  If I am reading that correctly, it says  
> that if I only want to have a RESTful interface and not WSDL, I am  
> not compliant.  I don't like that in theory or in practice,  
> especially since sparql-protocol-query.wsdl is currently broken  
> rather badly.

I believe that to be a misreading. I believe the HTTP bindings,  
described by WSDL, to be RESTful. They do not require anyone to "use  
WSDL". However, I added this language to an earlier section, in order  
to try to avoid this kind of confusion:

SPARQL Protocol contains one interface, SparqlQuery, which in turn  
contains one operation, query. SPARQL Protocol   is described  
abstractly with WSDL 2.0 [WSDL2] in terms of a web service that  
implements its interface, types, faults, and operations, as well as  
by HTTP and SOAP bindings. Note that while this document uses WSDL  
2.0 to describe SPARQL Protocol, there is no obligation on the part  
of any implementation to use any particular implementation strategy,  
including the use of any WSDL library or programming language framework.

>   SUGGESTION:  The use of a diminutive ("Little Jo") in Section  
> 2.2.1.3 may be taken as insulting (or, worst, racist) by some and  
> should therefore by changed to something else (e.g. "Jo").

Changed.

>   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

>   SUGGESTION:  In Section 3.0, the phrase "may be constrained by  
> law in some countries" should be changed to "may be constrained by  
> law in some jurisdictions".

Done.

>
>   QUESTION:  In the first paragraph of Section 2.1.2, could the  
> phrase "represented in the message schema by query" be deleted  
> without changing the intention?  Does the reference to the "message  
> schema" refer to another document?

I changed this to be more uniform with the rest of the language in  
that paragraph:

The SPARQL query string, identified by one query type, is defined by  
[SPARQL] as "a sequence of characters in the language defined by the  
[SPARQL] grammar, starting with the Query production". The RDF  
dataset description is composed of zero or one default RDF graphs —  
composed by the RDF merge of the RDF graphs identified by zero or  
more default-graph-uri types — and by zero or more named RDF graphs,  
identified by zero or more named-graph-uri types. These correspond to  
the FROM and FROM NAMED keywords in [SPARQL], respectively.

>   QUESTION:   There are references to both IRIs and URIs in this  
> document.  Does that represent the state of IRI uptake or an error?

Good question. I don't know the answer today. I'll try to figure it  
out. (I think it may be that some of the refs to "URI" need to be  
"IRI", but not all of them. So, for example, the interface bits are  
really meant for end-users, developers, and such, where "URI" is a  
better choice right now, because of uptake.)

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

Which example?

>   QUESTION:  I noticed that the SPARQL Query Language for RDF  
> working draft [3] (as of Revision 1.390  2005/06/13 13:37:19)  
> removed references to bnodes in results.  Should the bnode used in  
> Section 2.2.1.1 in the example result be removed?

Hmm, this is under heavy, ongoing discussion. It may have to be  
revised, but I don't have an answer today.

> 3.  Formatting
>
>   ERROR: The title of Section 2.1.2, "query-result In Message"  
> should be changed to "query In Message" to be consistent with the  
> titles of Sections 2.1.1, 2.1.3 and 2.1.4.

Done.

>
>   SUGGESTION:  The "PREFIX foaf: <http://xmlns.com/foaf/0.1/>"  
> lines in the SPARQL example queries in Sections 2.2.1.1, 2.2.1.2  
> and 2.2.1.4 are not used and should be deleted.

Done.

> 4.  Nits
>
>   SUGGESTION:   The <documentation> section of Figure 1.0, "WSDL  
> 2.0 fragment" in Section 2.1.1 ends in two periods (full stops for  
> those who learned English in the Commonwealth) instead of one.

Done.

>   SUGGESTION:  In the first paragraph of Section 2.1.4, I suggest  
> deleting the words "described here".

Done.

>
>   SUGGESTION:  In the "Malformed Query" paragraph of Section 2.1.4,  
> I suggest changing "should be returned, but an HTTP" to "should be  
> returned.  An HTTP".

Done.

Thanks for the careful review, David.

Cheers,
Kendall