W3C home > Mailing lists > Public > www-ws-desc@w3.org > January 2007

CR117 summary

From: Youenn Fablet <youenn.fablet@crf.canon.fr>
Date: Mon, 29 Jan 2007 14:51:27 +0100
To: www-ws-desc <www-ws-desc@w3.org>
Message-id: <45BDFBDF.1020908@crf.canon.fr>

 From last week telcon, different options were proposed to solve 
(partially) CR117.
Here is a summary:
1) Enable two serialization modes (encoded and raw)
Pros: the most powerful option, simple to explain and understand
Cons: new feature, may require a new Last Call

2) Status quo
Pros: enable dynamic URI constructions
Cons: greatly limit the usability of GET and POST/x-www-form-urlencoded 
for web services
Notes:
    1) IIRC, the SPARQL description (the only real example of the HTTP 
binding, AFAIKT) may lead to ambiguous requests, since strings and uris 
values are serialized as query string parameters
    2) IIRC, form web clients generally URL-encode parameter values 
before inserting them in the query string. WSDL would not be able to 
describe the servers processing these requests.

3) Select Encoded mode
Pros: simple to explain, ambiguity is then easy to check.
Cons: Disable the ability to describe some REST-style services
Note: Raw mode use cases may be partially enabled with the encoded mode 
by splitting a single parameter value into several parameter values.
    <element name="date"/> would be changed as <element 
name="year"/><element name="month"/><element name="day"/>
The one case that cannot be addressed with the encoded mode is when a 
parameter value contains a variable number of path steps, which may not 
be that widespread.

4) Raw mode for path parameter values/Encoded mode for query parameter 
values
Pros: No LC needed. Enable dynamic path construction. Also enable 
SPARQL, web forms scenarios and all simple use of HTTP GET. Ambiguity is 
easy to check for simple location templates.
Cons: Less understandable (?) than the other options.
URL-Encoding query parameter values is quite widespread and, IMHO, we 
should not go against that.
The current status quo is also vague about whether URL-encoding is used 
or not for query parameter values.
I also did not heard anybody arguing for the support of dynamic query 
string parameters...

Hope this helps going forward with this issue,
    Youenn
Received on Monday, 29 January 2007 13:51:38 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:45 GMT