- From: Paul Gearon <gearon@ieee.org>
- Date: Tue, 4 Jan 2011 12:05:09 -0500
- To: Lee Feigenbaum <lee@thefigtrees.net>
- Cc: Andy Seaborne <andy.seaborne@epimorphics.com>, SPARQL Working Group <public-rdf-dawg@w3.org>
On Mon, Jan 3, 2011 at 10:13 AM, Lee Feigenbaum <lee@thefigtrees.net> wrote: > On 12/29/2010 5:22 AM, Andy Seaborne wrote: <snip/> >> One note - the query protocol SPARQL 1.0 does not currently allow JSON >> results (nor CSV, TSV or plain text nor even HTML all of which I've seen >> used on the web). > > I'd consider all of these to be (healthy) extensions to the SPARQL 1.0 > protocol. As do I. I did notice that the spec states that the result will be either XML (for SELECT/ASK) or a representation of a graph (for CONSTRUCT/DESCRIBE), and does not provide other options. However, the same group included a Note on the JSON format for results. So there is evidently a tacit acknowledgement of these extensions. Perhaps the protocol part of the spec should not have been so specific. >>> But anyway, I see two main options given this, neither of which is >>> totally satisfying: >>> >>> Option 1: >>> >>> Rewrite the SPARQL protocol to be defined normatively without using WSDL >>> 2.0. >>> Pros: We can specify the exact behavior that we want. The protocols are >>> simple enough that this is not overly complex. >>> Cons: This is a large editing job, and we already have scheduling and >>> resource issues with getting protocol to Last Call. Also, I'm sure there >>> are many specification details of "the right way to use HTTP" that are >>> taken care of us automatically by leaning on WSDL that we might have to >>> be explicit about in this case. >> >> If there are such details, then there is use for WSDL for us. Can we >> enumerate what they might be? > > I can't :-) I'm thinking of basic things like the fact that the key/value > pairs within the query string can occur in any order without changing the > semantics of the request. Again, I don't know if this should be a serious > concern, or how much of that sort of thing we'd need to spell out explicitly > if we re-do the protocol document. > >> As an implementer of the HTTP protocol, I didn't use the WSDL for any >> details and had to go outside WSDL for normal HTTP details such as other >> return codes. >> <Option 2 elided> >> I support Option 1. > > I asked on twitter and the response unanimously supported moving to an > HTTP-only protocol. What do other members of the WG think? I'm behind option 1. I don't really know WSDL very well and like Andy I didn't bother with it much either. I think it's a fair presumption that the majority of implementors won't know it well enough for it to be of use. It's all well and good to have a formal definition like WSDL, but what's the point if no one can read it? :-) Regards, Paul
Received on Tuesday, 4 January 2011 17:06:30 UTC