Re: update= vs query=

Hi Lee, please see below.


On Wed, 2009-09-23 at 03:58 -0400, Lee Feigenbaum wrote:
> in either case, it was suggested that a natural way to extend the 
> protocol would be to have update statements over HTTP be indicated with 
> update= rather than query=. Chimezie wondered on the telecon and below 
> whether that was necessary.
> 
>  From the SPARQL/Protocol point of view, we seem to have a few choices 
> for how to support SPARQL/Update:
> 
>    + It can be its own Interface (a la SparqlQuery)
>    + It can be its own Operation (a la query)
> 
> ...others?

It can also stay the same operation, query. I think you're implying this
option below. In fact, a new operation "update" could still have a
"query" URI parameter on the wire.

> In either case, the WSDL HTTP bindings seem to say ... if i'm reading 
> them right ... that the only thing that determines how to construct a 
> GET IRI or the qyuery string for the body of a POST is the local name of 
> the sequence of child elements of the element that forms the input 
> message element for the operation. 

The thing that determines how to construct the input message and address
is the operation selected for invocation by the client. I believe the
WSDL group decided against requiring that every operation have a unique
input message schema (but I can't verify that now, I'm off-line). It's
common, however, to give different elements to different messages,
because in SOAP that's the easiest way to let the server know which
operation is being invoked. In HTTP, with GET, the equivalent mechanism
would be to rename the operation parameter "query" below to "update",
resulting in update=. But it's not required, given that the actual query
will be different anyway.

> right now it's:
> 
> <xs:element name="query-request">
>    <xs:complexType>
>      <xs:sequence>
>        <xs:element minOccurs="1" maxOccurs="1" name="query" 
> type="xs:string">
>         <xs:annotation>
> 	      <xs:documentation>query is an xs:string constrained by the 
> language definition,
>           http://www.w3.org/TR/rdf-sparql-query/#grammar, as "a sequence 
> of characters in
>           the language defined by the [SPARQL] grammar, starting with 
> the Query production".</xs:documentation>
>         </xs:annotation>
>        </xs:element>
>        <xs:element minOccurs="0" maxOccurs="unbounded" 
> name="default-graph-uri" type="xs:anyURI"/>
>        <xs:element minOccurs="0" maxOccurs="unbounded" 
> name="named-graph-uri" type="xs:anyURI"/>
>      </xs:sequence>
>    </xs:complexType>
> </xs:element>
> 
> ...which has child elements query, default-graph-uri, named-graph-uri, 
> which is why that's what SPARQL over HTTP looks like.
> 
> All of which is to say, surprisingly to me, that the operation name 
> isn't encoded into HTTP bindings at all.

To be precise, the operation name is not encoded into SOAP bindings
either. It's the top-level element that's ignored in the HTTP binding.
Not that the difference is very important.

> the main difference between making it a separate interface vs. a 
> separate operation is...? I'm not sure yet, need to re-learn that. Maybe 
> what faults can be returned?

The main difference is that a new interface would mean that if a single
service should implement both functionalities, it would have to use a
third interface that would extend both SPARQL protocol interfaces. Not
worth it. There's nothing in WSDL about a service having to support all
the operations of an interface. But in case of the lack of support,
there should be a nice fault somewhere.

Different operations in one interface can return different faults, so
that wouldn't be a difference between making update a separate interface
or operation. The "nice fault" from above would probably be added only
to the update operation, because I too wouldn't expect write-only
endpoints.

In either case (different interface, diff. operation) the HTTP binding
in the WSDL could specify that this operation only supports POST and
never GET. This would rule out the reuse of the query operation for
updates.

> Anyway, practically speaking, the benefit of always doing query= seems 
> to be the same benefit as we have right now for having the same 
> operation for all SPARQL query types (select, construct, ask, describe) 
> -- a generic client can easily take a query string from a user and pass 
> it to a SPARQL endpoint, without needing to parse it at all.
> 
> The benefit to having update= is - I think - that it's easier for a 
> read-only endpoint to reject SPARQL/Update queries without needing to 
> parse the query.

I think the benefits of having update= outweigh the drawback in the
"generic client" above. But my opinion on this is worth very little.

> PPS I think we might use WSDL's "IRI Style" incorrectly because the 
> local name of our input message's XML root element (query-request) is 
> not the same as the operation name (query). Is there anyone in the world 
> who possibly cares about this?

Just WSDL validators. But it wouldn't be hard to fix this, right? Just
rename the top-level element to query; this would not constitute any
kind of conflict with the child element of the same name, or with
anything else in the WSDL.

Hope it helps,
Jacek

Received on Wednesday, 23 September 2009 21:17:44 UTC