Re: construct starting to feel like a separate interface

On Sun, 2005-05-15 at 17:48 +0100, Seaborne, Andy wrote:
[...]
> > for ref...
> > http://www.w3.org/2001/sw/DataAccess/proto-wd/sparcli.py
> > 1.5 now
> > 
> 
> There is a tradeoff for simple clients.  If there are separate interfaces for 
> different operations, then it requires the client library to send different 
> things for the various result forms

Really? That's not my understanding. Two different WSDL interfaces
can produce exactly the same HTTP query parameters, if I'm not mistaken.

>  - and so the client library needs to know 
> at the point the request is made.  So it needs to understand SPARQL query 
> strings (at some level - need not be complete parsing) or it would require the 
> API to get the application to tell the client library what to do.

The experience I'm getting by coding up a client that interacts
with various sparql services is that the application or the client
or whatever knows whether it's asking for bindings or for a graph.

> With one interface, a simple client could written that does not need to parse 
> the query string.

My code doesn't parse the query string; it relies on the caller
to call getGraph() for CONSTRUCT/DESCRIBE and getBindings for SELECT.
(I have a 3rd method for ask; I wish I didn't have to; I wish
I could just use getBindings).

>   The most basic is send query string to a service.  It's the 
> results that need the information - our result form, for example, enumerates 
> the variables in the header making subsequent parsing streamable.  Works if 
> you can tell RDF/XML from XML result sets, like "accept" processing.

I never found a case where that was a useful way for the code to flow;
i.e. where you didn't know what sort of results you were going to
get until they came back.


-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/
D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E
see you at XTech in Amsterdam 24-27 May?

Received on Monday, 16 May 2005 02:49:51 UTC