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

Data Access WG questions about WSDL

From: Kendall Clark <kendall@monkeyfist.com>
Date: Mon, 15 Aug 2005 14:24:31 -0400
To: www-ws-desc@w3.org
Message-ID: <20050815182431.GA2157@monkeyfist.com>


I'm working on the SPARQL Protocol for the Data Access Working Group (and
I'm the UMD alternate on WS-DESC), and I have a few questions about WSDL2
and the HTTP bindings in particular:

1. Is this a legal combination for an operation binding: whttp:method="POST"
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, may
be too long to reliably work on all HTTP servers/clients. So we've added
another binding that uses POST, and we'd like the message body to contain
application/x-www-form-urlencoded data.

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; DESCRIBE &
CONSTRUCT return application/rdf+xml.

So, the question: is there a way to say that the whttp:outputSerialization
of an operation binding is one of 2 or more Media Types? We have *no other
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.

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 Media
Types: plain text, HTML, XML, RDF, etc.

If whttp:faultSerialization is a required property and the default value
doesn't describe our service, what alternative do we have?

Kendall Clark
Received on Monday, 15 August 2005 18:24:42 UTC

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