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 00:24:06 UTC