RE: CR117 summary

I've annotated Youenn's analysis with the option numbers from last week's
poll (which I'll carry forward this week).

Jonathan Marsh - http://www.wso2.com - http://auburnmarshes.spaces.live.com
 

> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On
> Behalf Of Youenn Fablet
> Sent: Monday, January 29, 2007 5:51 AM
> To: www-ws-desc
> Subject: CR117 summary
> 
> 
>  From last week telcon, different options were proposed to solve
> (partially) CR117.
> Here is a summary:

Option 1: Jonathan's 1st - new syntax for controlling whether or not to
encode

> 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


Option 0: status quo - nothing encoded

> 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.


Option 5: everything encoded 

> 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.


Option 2: Youenn - cited parameters raw, uncited encoded

> 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