Re: WSDL and POSTing SPARQL Update requests directly

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