W3C home > Mailing lists > Public > www-ws-desc@w3.org > August 2005

RE: Data Access WG questions about WSDL

From: IC Dept.- MIT-Maqbool Al Maimani <maqbool@oas.com.om>
Date: Tue, 30 Aug 2005 08:40:43 +0400
Message-ID: <FD196CAED4D46C4288E8F13F565BF91B0264CA0D@EX_NT1.hq.omanair.com>
To: "Hugo Haas" <hugo@w3.org>, "Kendall Clark" <kendall@monkeyfist.com>
Cc: <www-ws-desc@w3.org>, "Eric Prud'hommeaux" <eric@w3.org>

Dear All

Where can I get the latest development on WSDL, UDDI, SOAP and XAML.
Moreover, I want to know the latest on the Semantic Web Services.

Also, I would like to get the open research points and issues on web
services and semantic web services



-----Original Message-----
From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org] On
Behalf Of Hugo Haas
Sent: Tuesday, August 16, 2005 5:02 PM
To: Kendall Clark
Cc: www-ws-desc@w3.org; Eric Prud'hommeaux
Subject: Re: Data Access WG questions about WSDL

Hi Kendall.

* Kendall Clark <kendall@monkeyfist.com> [2005-08-15 14:24-0400]
> I'm working on the SPARQL Protocol for the Data Access Working Group
> I'm the UMD alternate on WS-DESC), and I have a few questions about
> and the HTTP bindings in particular:
> 1. Is this a legal combination for an operation binding:
> and whttp:inputSerialization="application/x-www-form-urlencoded"?
> We don't have an XML representation of our query language, and we
think in
> some cases SPARQL queries, serialized into an IRI with the GET method,
> be too long to reliably work on all HTTP servers/clients. So we've
> another binding that uses POST, and we'd like the message body to
> application/x-www-form-urlencoded data.

I don't see why it would not work. However, what you are going to end
up with is a POST of an empty message to a IRI built based on the
instance data, and I don't think that it's the solution you were

Didn't you want to use multipart/form-data is an input serialization
instead? And in which case, yes, you can do it.

> 2. Our interface, SparqlQuery, has one operation, query. The Media
Type of
> the message returned by query depends on the kind of query submitted
to the
> service: SELECT and ASK return application/sparql-results+xml;
> CONSTRUCT return application/rdf+xml.
> So, the question: is there a way to say that the
> of an operation binding is one of 2 or more Media Types? We have *no
> reason* to split the query operations into separate operations. Both
> application/sparql-results+xml and application/rdf+xml *can* be
described as
> application/xml, but we'd like to be able to describe our service more
> accurately than that.

The value of whttp:outputSerialization is "a IANA media type
token"[1], which interestingly doesn't have a reference to define it
clearly, but I don't think that it allows something like
"application/*", or "application/sparql-results+xml
application/rdf+xml", or even "application/sparql-results+xml,

So WSDL doesn't allow you to do what you want to.

Talking to Eric Prud'hommeaux about this, we actually wondered what
would happen if one was declaring two binding operations with
identical input parameters but different output ones:

  <interface name="SPARQL">

    <operation name="one" wsdlx:safe="true"
      <input messageLabel="Query" element="s:query"/>
      <!-- maybe there's a better specification than #any here
           but that will do for the purpose of this example -->
      <output messageLabel="Result" element="#any"/>

    <!-- this one is identical to the previous one -->
    <operation name="two" wsdlx:safe="true"
      <input messageLabel="Query" element="s:query"/>
      <output messageLabel="Result" element="#any"/>


  <binding name="HttpBinding" interface="m:GetTemperature"
    <operation ref="m:one" whttp:method="POST"
    <!-- only the output serialization changes -->
    <operation ref="m:two" whttp:method="POST"

Correct me if I'm wrong, but I don't think that the specification
prevents this, and I would interpret this as "you may get either one".
But it's ugly in this case.

It actually may be possible to change the definition of the
serialization properties to allow for a list of media types instead of
one particular media type.

> 3. Similarly, we'd like to avoid having to require a particular fault
> serialization type in our HTTP bindings. That is, we anticipate SPARQL
> services being free to serialize fault messages in several different
> Types: plain text, HTML, XML, RDF, etc.
> If whttp:faultSerialization is a required property and the default
> doesn't describe our service, what alternative do we have?

Maybe the fault serialization should be a property of the Binding
Fault and Binding Fault Reference components, rather than of the
Binding Operation, which would solve your problem.

As WSDL 2.0 is in LC until 19 September, I encourage you to send all
the feedback you may have as a result of this discussion to



Hugo Haas - W3C
mailto:hugo@w3.org - http://www.w3.org/People/Hugo/
Received on Tuesday, 30 August 2005 04:42:52 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:54:56 UTC