RE: CR117 summary

And, FWIW, my analysis, since I seem quite out of step with the majority on
this issue.

First, disallowing encoded parameters is hostile to REST-style services.
Most web sites today encode parameter values (often using an additional
convention of substituting "+" for "%20".)  For us not to support the
generation of these URIs without pre-%-encoding the values in the XML is
quite unfriendly.  Thus any proposal that does not allow or require
%-encoding of the data during population of the template, regardless of
where the data appears in the template, is a non-starter for me.  That
includes options 0, 2 and 4.

Option 5 is a compromise position and doesn't rule out ambiguity in
reconstructing an XML document from the URI, but it also precludes the
interesting use case of a parameter that represents a path segment, or a
full URI, such as a base URI.  This half-way approach doesn't really fully
embrace the needs of either the authors or the implementers.  I'd rather go
fully in one direction or the other, and choose option 1 or 3.

Although I prefer option 3, I don't think we would need to return to Last
Call if we chose option 1, as this change is more of a clarification than a
new feature.  We'd have to redo the test cases, which shouldn't add more
than a week to the timeline.  (Though I think the test cases currently all
conform to option 3 already so that would be even faster ;-)

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

> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On
> Behalf Of Jonathan Marsh
> Sent: Wednesday, January 31, 2007 12:13 PM
> To: 'Youenn Fablet'; 'www-ws-desc'
> Subject: 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
>