W3C

Disposition of Candidate Recommendation comments for the SPARQL Protocol for RDF dated 6 Apr 2006

This is the disposition of the comments received by the RDF Data Access Working Group during the Candidate Recommendation publication period of the SPARQL Protocol for RDF.

Comments received during CR have led to these changes in the SPARQL Protocol for RDF:

The other changes to the specification during CR were editorial in nature:

The Working Group does not believe that any of these changes would invalidate any previous review of the specification, nor require any implementation to change.

The Working Group has asked commenters to let the group know if they were not satisfied with the response to their comments.

In the table below, red in the WG decision column indicates that no changes to the document or related materials were made based on the comment, and green indicates that a change was made to accommodate the comment.

In the "Commenter reply" column, red indicates the commenter objected to the WG resolution, green indicates approval, and yellow means the commenter didn't respond to the Working Group response to the comment.

CommenterCommentWorking Group decisionCommenter reply
Arthur Ryman Error in sparql-protocol-query.wsdl detected by Apache Woden

... However, the SOAP fault codes are part of the SOAP envelope namespace. The binding should be: ...
Fixed bug in WSDL. None.
Jonathan Marsh sparql-protocol-query.wsdl

The schemaLocation attribute is of course optional, and we could mandate additional mechanisms in our test framework to deal with it (e.g. add a catalog file). However the single omission looks more like a mistake to me than a deliberate design choice. Is the omission of schemaLocation deliberate? If all other factors are equal, would you consent to adding it?
Added schemaLocation to WSDL Commenter acknowledged response offlist.
Bjoern Hoehrmann SPARQL Protocol: application/sparql-query requests

From http://www.w3.org/TR/2006/CR-rdf-sparql-protocol-20060406/ it is not really clear to me why POSTing application/sparql-query documents to the service is a bad thing...
No direct technical solution in WSDL 2.0.
I have received a response from the WS-description WG [1] and unfortunately we didn't get a favorable answer. They are currently in last call and Jonathan Marsh had filed a bug to address your concern, however, they did not get around to resolving it this time around. He also suggested using an extension, which seems a bit overkill for the simple feature you are looking for in the SPARQL protocol. Last time DAWG discuss this issue in a meeting, there was almost no support to move forward with this issue if the WS-desc group did not come up with a feasible answer. Hence, we would like to leave the protocol as it's currently defined.
None.
Ray Hookway SPARQL Protocol question - details of 2.1.2 query In Message

I found what I believe to be a problem in the SPARQL protocol specification. The basic problem is a disparity between http://www.w3.org/2005/09/sparql-protocol-types ... which is imported by http://www.w3.org/TR/rdf-sparql-protocol/sparql-protocol-query.wsdl ... and http://www.w3.org/TR/rdf-sparql-protocol/sparql-protocol-types.xsd ...
Fixed old schema at namespace URI location. None.
Petr Kremen SPARQL WSDL problems

I am encountering problems with SPARQL WSDL1.1 and WSDL2.0. For both I am using Axis2...
Fixed one bug. Also:

Unfortunately, while the group did do the work on examining SPARQL with WSDL 1.1 and related tools a while back, it is not work that we have been able to devote resources to to keep up-to-date, nor is the WSDL 1.1 something that we are pursuing on the W3C Rec. track.

If you do see problems with the WSDL 2.0 document, please do let us know. Unfortunately, we also do not have the bandwidth to recreate specific application setups (as with wsdl2java), so the more information that you can give about the problems with the protocol specification or protocol WSDL 2.0 files, the better.

Commenter promises further tool-independent detail. No further response.

RDF Data Access Working Group