three open protocol issues (schemaLocation, bad links, and posting SPARQL queries)

Hi DAWG,

Kendall and Elias and I have identified three currently open issues with 
the SPARQL protocol. I'm summarizing them in this email, along with our 
thoughts on how the issues should be addressed. We'd appreciate feedback, 
and I think for #3 we might need a WG decision at some point.

1/ schemaLocation

Issue: As per 
http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2006May/0010, 
the protocol document seems to have missed adding a schemaLocation pointer 
for one of its schema imports. 

Proposed resolution: Update editor's draft of the protocol and add the 
schemaLocation pointer.


2/ non-TR links

Issue: As per 
http://lists.w3.org/Archives/Public/public-rdf-dawg/2006JulSep/0274, the 
protocol document currently published in /TR/ space has several links 
which point to the rq23 old editor's draft of the query language document. 
In the /TR/ copy of the QL document, all links to the protocol document 
and XML format document that I can find point to /TR/ space.

Proposed resolution: Update editor's draft of the protocol such that all 
links point to /TR/ space, even while the protocol document is still a 
working draft. Doing this ensures that publication of a working draft does 
not have a hit-or-miss procedure for updating links. 

(Andy or Eric or Kendall -- is there some accepted W3C practice for how to 
handle documents in parallel development which are bouncing between 
evolving working drafts and stable versions in /TR/ space?)


3/ posting SPARQL queries directly

Issue: Bjoern points out in 
http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2006Sep/0007 
that the protocol document (the WSDL, really) allows queries to be issued 
via HTTP POST and specifies that the content of the HTTP POST message 
should either be application/x-www-form-urlencoded or application/xml. 
Bjoern wonders why the protocol document does not also allow 
application/sparql-query+xml ( 
http://www.alvestrand.no/pipermail/ietf-types/2005-November/000894.html ). 


Possible resolutions:
  3.a Add application/sparql-query to whttp:inputSerialization for POST 
messages. Pros: Allows the natural case of directly POSTing a SPARQL query 
without URL or XML encoding it. Cons: Extra implementation cost for 
services implementing the SPARQL protocol.
  3.b  Remove application/xml from whttp:inputSerialization for POST 
messages. Pros: Simplest resolution, no burden on implementors. Cons: Does 
not allow alternative serializations of SPARQL queries to be posted.

Proposed resolution:
  3.a 

Lee