LC338: 5 options to solve the SPARQL multiple output issue

LC338[1] is from the DAWG:

| Our situation is that our protocol qua service has one interface,
| SparqlQuery, and one operation, query. That operation takes a SPARQL query
| and returns the results of that query. Nice, neat, and simple.
| 
| However, SPARQL queries may return different MIME types, including
| application/sparql-results+xml, application/rdf+xml, as well as different
| serializations of RDF (N3, Turtle, N-Triples).
| 
| We also have a POST binding for query in order to submit In Messages that
| are so long as to not reliably be serializable over a GET.

The problem is that {http output serialization} only allows one value.
Dave Orchard explained different ways of addressing the problem in
[2].

However, SPARQL's situation doesn't allow for option 1 with the way
our spec is now: their service always takes a <query> element in.
Since they want to use an HTTP GET or POST binding, they need the
IRI[3] and Multipart[4] styles, which both restrict the localPart of
the element's QName to be the same as the Interface Operation
component's name.

So, below are 4 options to allow them to describe their service as
currently defined, each one necessitating little to no modifications
to the spec.

1. define an interface with one operation, and have multiple bindings
   of this operation at the same endpoint

   Modification needed to the spec: none, status quo!

   <interface>
     <operation ref="query">
       <input element="query"/>
       <output element="sparqlorrdf"/>
     </operation>
   </interface>
   
   <binding name="b1">
     <operation ref="query"
                httpOutputSerialization="application/sparql-results+xml"/>
   </binding>
   
   <binding name="b2">
     <operation ref="query"
                httpOutputSerialization="application/rdf+xml"/>
   </binding>

   <service>
     <endpoint binding="b1"
               address="a"/>
     <endpoint binding="b2"
               address="a"/>
   </service>

  Advantages: feasible today, describes the media type output
  accurately
  
  Drawbacks: the description of the output message format is vague,
  i.e. you don't describe individually the message format associated
  with each media type; one may need to define a lot of bindings;
  arguably ugly

2. define an interface with several operations, one for each
   serialization options:

   Modification needed to the spec: remove the restriction on
   matching the localPart of the message reference with the name of
   the operation from IRI and Multipart styles; why do we have this
   restriction?

   <interface>
     <operation ref="get1">
       <input element="query"/>
       <output element="sparql"/>
     </operation>
     <operation ref="get2"/>
       <input element="query"/>
       <output element="rdf"/>
     </operation>
   </interface>
···
   <binding>
     <operation ref="get1"
                httpOutputSerialization="application/sparql-results+xml"/>
     <operation ref="get2"
                httpOutputSerialization="application/rdf+xml"/>
   </binding>

   <service>
     <endpoint binding="b"
               address="a"/>
   </service>

  Advantages: almost feasible today, describes the service accurately;
  the description of the output is precise
  
  Drawbacks: one may need to define a lot of operations

3. define several possible media types for the output:

   Modification needed to the spec: make {http output serialization} a
   list, and say that either one may be used; it seems like a harmless
   change.

   <interface>
     <operation ref="query">
       <input element="query"/>
       <output element="sparqlorrdf"/>
     </operation>
   </interface>
···
   <binding name="b">
     <operation ref="query"
     httpOutputSerialization="application/sparql-results+xml application/rdf+xml"/>
   </binding>
···
   <service>
     <endpoint binding="b"
               address="a"/>
   </service>

  Advantages: describes the media type output accurately, with a terse
  description

  Drawbacks: the description of the output message format is vague,
  i.e. you don't describe individually the message format associated
  with each media type
  
4. allow not to define the output serialization:

   Modification: allow */* to {http output serialization} 

   <interface>
     <operation ref="query">
       <input element="query"/>
       <output element="sparqlorrdf"/>
     </operation>
   </interface>
···
   <binding name="b">
     <operation ref="query" httpOutputSerialization="*/*"/>
   </binding>
···
   <service>
     <endpoint binding="b"
               address="a"/>
   </service>

  Advantages: terse description

  Drawbacks: the description of the message output and of the output
  serialization is vague

I left out the application/xml serialization option from Dave, as it
wouldn't work for n3 for example.

Of course, there is a 5th option, also status quo for us, which I
think is equivalent to Dave's option 2, I think, for which we say that
our spec is fine, and that their protocol is designed the wrong way,
and we send them comments showing how we think it should be done and
how it will be described very well by our spec.

To answer Umit's question, I believe that this issue does not impact
the SOAP binding.

Kendall and Bijan will tell us what they think is best. All approaches
seem feasible.

My preference is for 2, then 3. 1 seems OK though not optimal. 4 seems
to go against the idea of describing services. I am uncomfortable with
5, as they probably have good reasons for having designed their query
service that way.

Note that we may want to allow both 2 and 3.

Finally, if we adopt 3, then I believe that we should mention that
HTTP Accept headers may be used by a client to express a preference as
to the output serialization.

Cheers,

Hugo

  1. http://www.w3.org/2002/ws/desc/5/lc-issues/issues.html#LC338
  2. http://lists.w3.org/Archives/Public/www-ws-desc/2005Sep/0007.html
  3. http://www.w3.org/TR/2005/WD-wsdl20-adjuncts-20050803/#_operation_iri_style
  4. http://www.w3.org/TR/2005/WD-wsdl20-adjuncts-20050803/#_operation_multipart_style
-- 
Hugo Haas - W3C
mailto:hugo@w3.org - http://www.w3.org/People/Hugo/