limitations of {http output serialization}

[Resend with a more apt subject line.]

WS-Desc,

I'm writing on behalf of DAWG, which is using WSDL 2.0 to specify the SPARQL
Protocol for RDF [1]. We have a couple of LC comments about WSDL 2.0, and
I'll be sending each one in a separate message.

In short, we'd like to have multiple values for {http output serialization}.
Well, in truth, multiple values, or some kind of MIME wildcard, or allow
that component to be optionally declared. (FWIW, I believe this issue is
related to LC323 but not identical.)

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.

If we had to declare a different operations, the total number would become
really unwieldy -- I think the total number would be 10 (number of
serialization formats, 5, times the number of HTTP methods, 2 -- eek! And,
FWIW, this will only get worse if future DAWG adds other interfaces or
operations, with the same blowup of operations. Very unwieldy!)

Much simpler, and more descriptively accurate, to be able to say:

<operation ... whttp:outputSerialization="application/sparql-results+xml, 
application/rdf+xml...">

or

<operation ... whttp:outputSerialization="*/*">

Cheers, 
Kendall Clark

[1] http://www.w3.org/sw/2001/DataAccess/proto-wd/

Received on Thursday, 15 September 2005 14:18:16 UTC