Re: LocationTemplate-1G totally hosed ;-)

Jonathan Marsh wrote:
>
> 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.
>
Can you elaborate more on this?
Section 5.10.4.2 tells that when soap-response is in use, section 6.7.2 
and the x-www-form-urlencoded serialization should be followed. This 
section describes how to build the request URL from whttp:location, 
whttp:ignoreUncited and the message parameters.
In any case, if the current state is as you describe, is it a clear 
decision from the working group?
>
> 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://auburnmarshes.spaces.live.com
>