- From: Dan Connolly <connolly@w3.org>
- Date: Tue, 16 Aug 2005 08:56:51 -0500
- To: kendall@monkeyfist.com
- Cc: DAWG Mailing List <public-rdf-dawg@w3.org>
On Mon, 2005-08-15 at 14:34 -0400, Kendall Clark wrote: > 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. Yes; it seems there's a requirements mismatch. Evidently the SPARQL protocol isn't a Web Service, because Web Services have all their I/O in XML: "Definition: A Web Service is a software application identified by a URI [IETF RFC 2396], whose interfaces and binding are capable of being defined, described and discovered by XML artifacts and supports direct interactions with other software applications using XML based messages via Internet-based protocols". -- http://www.w3.org/TR/2002/WD-ws-desc-reqs-20021028/ I don't think I had thought that thru when we adopted 3.14 WSDL Protocol http://www.w3.org/TR/rdf-dawg-uc/#r3.14 Hmm... maybe time to reconsider. > (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 -- Dan Connolly, W3C http://www.w3.org/People/Connolly/ D3C2 887B 0F92 6005 C541 0875 0F91 96DE 6E52 C29E
Received on Tuesday, 16 August 2005 13:56:59 UTC