FTR, the Working Group this issue as a CR144 [1].
The latest editor's draft includes this fix [2, 3].
Unless you let us know otherwise within 2 weeks, we will assume you agree
with the resolution of this issue.
[1] http://www.w3.org/2002/ws/desc/5/cr-issues/issues.html#CR144
[2]
http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20-adjuncts.html
?content-type=text/html;%20charset=utf-8#soap-binding
[3]
http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20-adjuncts.html
?content-type=text/html;%20charset=utf-8#id2296689
Jonathan Marsh - http://www.wso2.com - http://auburnmarshes.spaces.live.com
> -----Original Message-----
> From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org] On
> Behalf Of Jonathan Marsh
> Sent: Tuesday, January 16, 2007 6:09 AM
> To: 'Youenn Fablet'
> Cc: 'www-ws-desc'
> Subject: RE: LocationTemplate-1G totally hosed ;-)
>
>
> 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!
>
> 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.
>
> > 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
> > >
>