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

This action should be DO.

>            + ACTION DC 2002/06/10: Send note to WSA WG
>              expressing concern about normative binding
>              for GET.

I had pushed back upon sending a note to WSA WG as I didn't have enough
knowledge of the issues.  I've spent some time talking with our dev staff.

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.

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.

2) Define a mapping from XML (or SOAP) into url encoded.  This was the basis
for the DaveO/Tim Bray approach.

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.

2) Update the WSDL specification to provide greater type support for the
SOAP 1.2 with GET.  Problem described earlier.

I think I've provided sufficient background material, possible solutions,
and potential action items for a fruitful discussion today.

Cheers,
Dave

Received on Monday, 24 June 2002 14:26:39 UTC