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 01:54:31 UTC