WSDL 2.0 issues

Dan, et. al.,

I've raised some questions about WSDL 2.0, particularly about some of its
restrictions on serialization types: for inputs outputs, and faults. The
problems, in a nutshell, are:

1. we don't have any other reason to split the SparqlQuery query operation
into separate operations. It's one operation, from out point of view, that
may return application/sparql-results+xml or application/rdf+xml. But, near
as I can tell, WSDL 2.0 requires an operation to return one and only one
output serialization type. I think that's unnecessarily restrictive and
means there's a class of useful web services that can't be described.

(We do have the option of taking the default outputSerialization type,
application/xml, and describing the output of query as XML. Which is
generally true, but not very specific.)

2. Similarly, we have two bindings for that operation, query: one that uses
GET, with input serialization type application/x-www-form-urlencoded; and
another that uses POST, where we'd also like
application/x-www-form-urlencode to be the input serialization type. But as
I understand WSDL 2.0, it doesn't seem legal to serialize
application/x-www-form-urlencode to a POST. That, too, seems unnecessarily
restrictive, though I may be misreading their specs.

(This is solved by finishing and requiring SparqlX, and while I'm in favor
of that, I don't see why we can't use WSDL 2.0 to describe a service that
takes application/x-www-form-urlencode via POST.)

3. Last, fault serialization types, as with (1) above, seem to have to be
one type only. We haven't discussed this issue yet, but I have assumed we do
not want to specify one and only one Media Type for SPARQL implementations
to communicate faults, at least on the HTTP side.

Is that right? If not, we could moot this issue by requiring one and only
one media type for our faults.

Kendall Clark

PS--My message to the WSDL list is

       http://lists.w3.org/Archives/Public/www-ws-desc/2005Aug/0010.html

Received on Monday, 15 August 2005 18:34:54 UTC