RE: LocationTemplate-1G totally hosed ;-)

Plus one other change - made queryParameterSeparator agree with any explicit
query parameters in whttp:location (which seems to be a good idea regardless
of how the issue I raised earlier turns out.)

 

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

 

  _____  

From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org] On
Behalf Of Jonathan Marsh
Sent: Tuesday, January 16, 2007 5:51 PM
To: 'www-ws-desc'
Subject: LocationTemplate-1G totally hosed ;-)

 

I've been looking more closely at LocationTemplate-1G and find that the
premise of the test was fundamentally flawed.  That premise was that you can
sufficiently test the functionality of whttp:location templates using the
SOAP binding instead of the HTTP binding.  That was incorrect!

 

A more careful read of the spec shows that certain features are only in
force when using the x-www-form-urlencoded serialization, specifically the
automatic serialization of uncited elements as query parameters including
the behavior of whttp:ignoreUncited.

 

Thus the bindings AutoRemainder and AdditionalQueryParams are both wrong in
assuming that query parameters will be added, and the bindings IgnoreUncited
and Escaping are wrong in implying that whttp:ignoreUncited will have any
force.

 

I apologize in advance for the instability of these testcases, but I've gone
ahead and fixed and improved (I hope) them as follows:

 

*	In order not to lose the few bindings that make sense under SOAP,
I've cloned LocationTemplate-1G into LocationTemplate-2G which is an HTTP
binding-only version.  I twiddled a few other details to keep everything
sufficiently unique (e.g. service name, whttp:location URLs, etc.)
*	I've cut the AutoRemainder, AdditionalQueryParams, and
AutoQueryParams bindings from LocationTemplate-1G.
*	Since we've clarified that the {http location} is engaged on both
soap-request and request-response MEPs, I cloned the remaining 4 operations
and test them on the request-response MEP as well.
*	While doing this, I noticed some service names were not unique
within the whole set of tests we're doing, which is inconvenient for some
implementations like Axis2.  I updated MessageTest-2G,3G,4G service names
(which should affect the component model more than the message tests.)

 

This causes a bit of temporary churn in the component model tests as well.

 

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