RE: Issue with soap-rpc:result

> [Noah]
> Overall: I have always had doubts about the wisdom of the
> graph model in
> SOAP, but it's also very late in the process to be 
> questioning it.   Count
> me as more or less neutral on the technial merits, but very 
> concerned that whatever we adopt be modeled and explained 
> very carefully and precisely.

I share your doubts, and wish I had raised the issue sooner. If it is
too late to change things, so be it. However, I *completely* agree that
whatever model is adopted must be explained very carefully and
precisely, including which bits are optional and which are not.

The problem I see in all of this is that right now there are basically
two SOAPs. People implementing toolkits handle encoded messages
differently from unencoded messages (which isn't supposed to be the
case, as per the thread on encoding style, but most SOAP toolkits I've
played with work this way).

I want there to be one SOAP based on sending messages described using
XSD. All messages that comply with SOAP's RPC model and encoding
mechanism can be described in XSD - albeit perhaps somewhat grotesquely.
All messages that can be described in XSD cannot be defined in terms of
SOAP's RPC model or encoding model. That tells me that XSD is the basic
atom for describing messages. I do not understand why the RPC and
encoding models cannot be written in terms of mapping the SOAP data
model to schema instead of directly to XML. (The notion that a contract
might be specified at the SOAP data model level can be addressed at a
higher level, e.g., in WSDL, at the SOAP level all we need to care about
is how the encoding rules map to a specific message format.) If those
parts of the spec are in fact optional adjuncts, layering them on XML
messages described by XSD seems like the only elegant solution to me.

In any case, in the absence of some sort of reconciliation between these
two sides of the SOAP world, I fear the current trend will continue. Web
Service toolkits will simply process messages using two different code
paths, one for RPC/encoded messages and one for non-encoded messages
described solely using XSD. Developers, meanwhile, will continue to be
very confused.


Received on Wednesday, 20 February 2002 11:40:09 UTC