Re: Is "GET" or "query" the operation?

Hi Dan.  Sorry about not CCing you on my last message - I didn't realize
you weren't subscribed.

On Fri, Jun 24, 2005 at 02:18:40PM -0500, Dan Connolly wrote:
> > >Can you sketch a test case
> > > that
> > > we could use to tell the difference?
> > 
> > Actually, after much deliberation, no, because "query" doesn't have any
> > defined operational semantics in the specification, so I can't test for
> > them.
> 
> Oh? We have...
> 
> "1. query operation
> SparqlQuery is the only interface of SPARQL Protocol. It contains one
> operation, query, which is used to convey a SPARQL query -- including a
> SPARQL query string and an RDF dataset -- and a query result between
> clients (requesters) and services (responders)."
>  -- http://www.w3.org/TR/rdf-sparql-protocol/
> 
> but I don't see anything that says that the results should match
> what the SPARQL query language space says they should be.
> I guess we should add that.

Yes, that's what I was referring to.

But I don't think you should add that.  Here's why ...

> >  Besides, I fully expect that any test I devise will tell us that
> > GET is the operation being used because it comes along for the ride
> > whenever you turn URIs into data.  That's my point, really.
> 
> If the difference isn't observable on the wire, then this is
> a matter of specification style. I leave that for you to discuss
> with the editor (though he's bound to meet our requirement
> to have a WSDL description of the protocol
> http://www.w3.org/TR/rdf-dawg-uc/#r3.14 ).

Ok, you made me do it! 8-) Here's the test;

- construct a SPARQL query on some server in http URI form
- have a SPARQL protocol client "execute" that query
- take the resulting data and stick it in a file on a different Web
server so that it gets its own http URI
- have the same SPARQL protocol client "execute" that query on the
new URI

If the client gets the data in that second step, then GET is the
operation being used, not "query".  If not, it's not using GET, and is
presumably using "query".

Sound good?

> > > > FWIW, my preference would be that the answer be "GET" and that "query"
> > > > be described as purely informative, i.e. not part of any contract.
> > > 
> > > What would that look like in the spec?
> >
> > It would mean a pretty significant rewrite of section 2, since the
> > current assumption made there seems to be that the SPARQL spec defines
> > the operations (rather than any underlying application protocols), and
> > those operations have to be somehow bound to the protocol.  I believe
> > that the SPARQL spec should avoid defining operations, or at least avoid
> > using them when binding to application protocols.
> >
> > Also, it would mean rewriting the WSDL to use http:GET as the operation
> > rather than "query".  Here's some WSDL 2.0 written by Dave Orchard to
> > describe the Yahoo News services, as an example of this kind of WSDL;
> > 
> > http://www.pacificspirit.com/Authoring/wsdl/YahooV1Search.wsdl
> 
> When I look there, I find, among other things:
> 
>  <wsdl:operation ref="yahoowns:Search"
> 
> so I don't see what you mean by 'use http:GET as the operation'.

That's at the binding.  The interface is;

  <wsdl:operation name="YahooSearch" method="GET" location="{searchString}">

Interestingly, when I just went to lookup the meaning of "method" - Dave
had previously (IIRC) suggested to me that it overrode "name" such that
it *was* the operation - I couldn't find it in the spec!  I've just
pinged Dave - I hope to hear back from him soon.

> > Note though, that I'm not endorsing the use of WSDL at all - I
> > personally think it's underspecified and ambiguous, and only introduces
> > confusion, especially in the context of Web based services (i.e. not
> > "Web services").  I also don't think it helps describe even SOAP/HTTP
> > based services, which you mentioned you were planning to incorporate
> > into the spec at a later date.
> 
> I think the WG considered concerns like that, though they didn't
> carry the day when we decided to adopt the WDSL requirement.

Understood.  I don't mind so much as long as it's informative.

Mark.
-- 
Mark Baker.  Ottawa, Ontario, CANADA.          http://www.markbaker.ca
Coactus; Web-inspired integration strategies   http://www.coactus.com

Received on Friday, 24 June 2005 20:45:22 UTC