W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > July to September 2005

Re: WSDL 2.0 issues

From: Steve Harris <S.W.Harris@ecs.soton.ac.uk>
Date: Tue, 16 Aug 2005 10:08:12 +0100
To: DAWG Mailing List <public-rdf-dawg@w3.org>
Message-ID: <20050816090812.GB17487@login.ecs.soton.ac.uk>

On Mon, Aug 15, 2005 at 02:34:42 -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.
> 
> (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.)

Presumably that would prevent us returning construct results in Turtle and
co? Though I guess that was the case all along, and I just wanst paying
attention.
 
> 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.

I'm using the XML head element of the results format at the moment, it's
something the client knows how to parse, and its lying around.

- Steve
Received on Tuesday, 16 August 2005 09:08:54 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:24 GMT