This is another issue which was discussed as the June/July meeting. The
feeling there was that although these would (probably) be used in
different scenarios - the URL approach being more suitable for a thin
client/browser type client, whereas the SOAP approach for a more complex
client, the actual API (i.e. request/response structures) should be the
same.
This is lead a little from the concept in WSDL where the message
structures are specified independently of the transport encoding. So I
tried to write the WSDL so that we only have one request/response
structure (ignoring the response extensibility issues which are causing
so much trouble at present) and then have two bindings URL and SOAP. In
theory we could have other bindings (SMTP anyone?).
However, we didn't want to be prescriptive about how these two different
encodings (URL vs SOAP) would be used. For instance a rich client could
use the URL form, and in theory a client could send a SOAP request
expecting to be able to use XSL to display the result using a browser
control (e.g. the Internet Explorer ActiveX controls).
*I* hope we can tackle the two requirement spec.s in the same manner.
I'm a little busy at the moment but will try to have another look
through the WSDL spec in case that suggests something. However, you may
be right that we have to split the standard.
Matthew
> -----Original Message-----
> From: Alan Kent [mailto:[log in to unmask]]
> Sent: 20 November 2001 23:25
> To: [log in to unmask]
> Subject: Re: No response from your server
>
> On Tue, Nov 20, 2001 at 10:04:52AM -0000, Matthew Dovey wrote:
> > But this breaks one of *your* claimed motivations - namely the use
of
> > existing SOAP toolkits etc.
> > ...
> > So yes we can do this, but we are moving away from our original
goals.
> >
> > Matthew
>
> Does this mean the URL and SOAP schemes should really be separate
> streams of development? (maybe sharing 'CQL') If the goal is for
> the SOAP approach to be nice for SOAP users, and the URL scheme
> is meant to be nice for web browsers, then these are two quite
> different things with different requirement specifications.
>
> Alan
|