Fw: Draft agenda: 24 June TAG teleconference (Arch document, WSA update)

FYI: A requirement for us to support the new SOAP MEP (the HTTP-GET-in /
HTTP-SOAP-out case). Also, Paul Prescod would like it to be possible
to bind different HTTP operations on a per operation basis rather than
just on a per-portType basis. I think both these requirements make
sense.

Jeffrey, can you please do the honors and add these to the requirements
list as draft requirements?

THanks,

Sanjiva.

----- Original Message -----
From: "David Orchard" <dorchard@bea.com>
To: "'Sanjiva Weerawarana'" <sanjiva@watson.ibm.com>; <www-tag@w3.org>
Sent: Tuesday, June 25, 2002 11:54 AM
Subject: RE: Draft agenda: 24 June TAG teleconference (Arch document, WSA
update)


>
> Sanjiva,
>
> Thanks muchly for spending the time to look at this.
>
> In WSDL, how would one define the type for the symbol parameter in
> http://example.org/foo?symbol=BEAS ?  Are you talking about the
> urlReplacement element?  Something like:
>
> <message name="m1">
>         <part name="part1" type="xsd:string"/>
>     </message>
>
>     <portType name="pt1">
>         <operation name="o1">
>            <input message="tns:m1"/>
>        ...
>         </operation>
>     </portType>
>
>     <service name="service1">
>         <port name="port1" binding="tns:b1">
>            <http:address location="http://example.org/"/>
>         </port>
>      </service>
>
>     <binding name="b1" type="pt1">
>         <http:binding verb="GET"/>
>         <operation name="foo">
>        <http:operation location="foo?symbol=(part1)"/>
>             <input>
>                <http:urlReplacement/>
>            </input>
>           ...
>         </operation>
>     </binding>
>
> I, and I think the TAG, agree with having a WSDL definition for a HTTP
> GET-in/SOAP out binding that is orthogonal to the SOAP POST binding.
Could
> this be added to the WSDL issues list, as it sounds like you are in
> agreement as well.
>
> Thanks,
> Dave
>
>
>
> > -----Original Message-----
> > From: www-tag-request@w3.org
> > [mailto:www-tag-request@w3.org]On Behalf Of
> > Sanjiva Weerawarana
> > Sent: Monday, June 24, 2002 9:22 PM
> > To: www-tag@w3.org
> > Subject: Re: Draft agenda: 24 June TAG teleconference (Arch document,
> > WSA update)
> >
> >
> >
> > "David Orchard" <dorchard@bea.com> writes:
> > > It is clear the description of GET binding that uses
> > parameters in WSDL
> > does
> > > not have the same level of information that the POST Binding does.
> > > Specifically, the GET binding uses the form "urlencoded",
> > and none of the
> > > parameters can be described - beit names, types, order.
> > The WSDL GET
> > > binding does support types and parts for non-parameters.  So
> > > http://example.org/foo/foo2/foo3 can have types associated
> > with foo, foo2,
> > > foo3.  This also conveiently deals with ordering of
> > parameters and names.
> > >
> > > The problem comes about when parameters are used.  WSDL
> > does not define
> > any
> > > mechanism for typing the query parameter, ie
> > > http://example.org/foo?symbol=BEAS.
> >
> > I must be missing the point you're making .. WSDL certainly lets you
> > describe the types of all the parameters- that's part of the message
> > definition. The message definition is common for all
> > bindings, HTTP-GET,
> > HTTP-POST, SOAP/HTTP, etc..
> >
> > However, what WSDL doesn't do is let you do something that HTTP
> > doesn't support: have a mechanism to indicate the type of data that's
> > flowing in the request. That's obviously out of scope for WSDL,
> > but this is an HTTP feature- you can indicate parameter names but
> > not types! For the SOAP case one can use xsi:type if one so wished
> > to indicate the type of data inline, but really that's got nothing
> > whatsoever to do with WSDL.
> >
> > > So it would seem nice to have a similar kinds of "schema"
> > information
> > > available for GET with query parameters.  However, the
> > problem is what
> > would
> > > the "right" solution look like?
> > >
> > > We thought of 2 different approaches.
> > >
> > > 1) Add type information into the URL encoding.  Extend WSDL to allow
> > > refinement of the typing for the query string.  Perhaps a
> > specialized
> > > syntax - similar to the FORM POST encoded - could be used.
> >
> > Adding type info to a URL would be something that HTTP would do,
> > not WSDL.
> >
> > > 2) Define a mapping from XML (or SOAP) into url encoded.
> > This was the
> > basis
> > > for the DaveO/Tim Bray approach.
> >
> > I don't see how this addresses the "problem" of having each request
> > be self-describing in terms of types of data. This addresses the
> > orthogonal problem of what to do with complex typed parameters
> > involved in a GET scenario. I believe the current spec (WSDL 1.1)
> > and the WS-Desc WG have so far decided to not try to solve that
> > problem.
> >
> > > To try to summarize the problem:
> > >
> > > The WSDL 1.1 GET binding with query parameters - the type
> > suggested by the
> > > SOAP 1.2 specification for GET - does not provide any mechanism for
> > > expressing the syntactice schema of the types expressed in
> > the GET query.
> > > This poses a significant problem for interoperability for
> > SOAP with GET
> > > implementations, compared to the HTTP POST binding for SOAP.
> > >
> > > There are at least a couple of things that might be done.
> > >
> > > 1) Update the WSDL specification for the SOAP 1.2 with GET.
> >  This may be
> > > explanative only, as it's not clear how to mix the HTTP GET and SOAP
> > > bindings in a request/response MEP.  We'd like this as high
> > priority, as
> > the
> > > SOAP 1.2 specification now clearly supports this, is in
> > Last Call period,
> > > and we are concerned about interoperable SOAP 1.2 implementations.
> >
> > WSDL should (IMO) have a binding to support the
> > HTTP-GET-in/SOAP-out MEP
> > that is being added to SOAP 1.2. In my mind that binding is orthogonal
> > to the existing SOAP binding; do you see it differently?
> >
> > > 2) Update the WSDL specification to provide greater type
> > support for the
> > > SOAP 1.2 with GET.  Problem described earlier.
> >
> > As I said above, I don't see the problem ..
> >
> > Bye,
> >
> > Sanjiva.
> >
> >
> >

Received on Tuesday, 25 June 2002 02:50:18 UTC