- From: Lee Feigenbaum <feigenbl@us.ibm.com>
- Date: Fri, 20 Oct 2006 10:24:29 -0400
- To: RDF Data Access Working Group <public-rdf-dawg@w3.org>
- Message-ID: <OF2FA50123.51C638F6-ON8525720D.004F0771-8525720D.004F25AD@us.ibm.com>
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
Received on Friday, 20 October 2006 14:24:47 UTC