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

Re: LocationTemplate-1G totally hosed ;-)

From: Youenn Fablet <youenn.fablet@crf.canon.fr>
Date: Tue, 16 Jan 2007 15:58:18 +0100
To: Jonathan Marsh <jonathan@wso2.com>
Cc: "'www-ws-desc'" <www-ws-desc@w3.org>
Message-id: <45ACE80A.2020606@crf.canon.fr>

Jonathan Marsh wrote:
> Below
>
> Jonathan Marsh - http://www.wso2.com - http://auburnmarshes.spaces.live.com
>  
>
>   
>> -----Original Message-----
>> From: Youenn Fablet [mailto:youenn.fablet@crf.canon.fr]
>> Sent: Tuesday, January 16, 2007 6:26 PM
>> To: Jonathan Marsh
>> Cc: www-ws-desc
>> Subject: 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.
>>     
>
> I forgot about the SOAP Response MEP - must be some jetlag.  Nothing with an
> application/soap+xml media type will add uncited parameters, but I guess
> that doesn't include the SOAP Response MEP which doesn't have a media type
> on the request.  But in that case something is still broken:  {http ignore
> uncited} isn't among the parameters listed as supported by the SOAP binding.
> It doesn't appear in the interchange format, so it shouldn't really have
> been available for you to use to pass that testcase!  
>   
I am still unsure of the relationship between application/soap+xml and 
uncited parameters.
Are you referring to section 6.7/table 6-5?
Anyway, in the SOAP-Response case, the media-type may be omitted within 
the request, but it may also be added.
It may be especially useful if soap action has been specified and will 
help the server.
Are you suggesting that depending on this implementation choice, 
parameters should or should not be added to the request URL?


> Also, with CR133 we made the request-response MEP correspond to the
> soap-response MEP, apparently including (with the above change) auto-adding
> query params and honoring ignoreUncited.  However, it seems to me much
> better to keep SOAP request-response parallel to serializing as
> application/xml under the HTTP binding, which would not add query parameters
> automatically and thus there's no need for ignoreUncited.
>   
+1 for keeping soap request-response aligned with application/xml 
serialization.
>   
>> In any case, if the current state is as you describe, is it a clear
>> decision from the working group?
>>     
>
> I'm just trying to interpret the status quo, but perhaps that's not as clear
> as I thought it was...  I'll back out the changes (looks like part of the
> checkin failed anyway).
>
> So here's a concrete proposal to fix the spec rather than the testcase:
>
> In Section 5 change:
>   *  {http location} on Binding Operation components, as defined in 
>      6.4 Binding Operations
> to:
>   *  {http location} and {http location ignore uncited} on Binding Operation
>      components, as defined in _6.4 Binding Operations_ and _6.7.2.2.2 
>      Controlling the serialization of the query string in the request IRI_,
>      respectively.
>
> In Section 5.10.4.1.1 change (pre-CR133 text):
>   The SOAP "http://www.w3.org/2003/05/soap/mep/ImmediateDestination"
>   property takes the value of the WSDL {address} property of the Endpoint
>   component.
>
> to:
>   The SOAP "http://www.w3.org/2003/05/soap/mep/ImmediateDestination"
>   property takes the value of the WSDL {address} property, modified by 
>   the {http location} property following the rules described in section
>   _6.7.1 Serialization of the instance data in parts of the HTTP request_.
>
>
>   
>>> 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.)
>>>       
>
> I'm still going to check-in these fixes.
>
>   
>>> 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
>>>
>>>       
>
>
>
>   
Received on Tuesday, 16 January 2007 14:58:36 GMT

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