Re: encodings in RPC

Jacek Kopecky wrote (..last week, sorry for being slow.  I'm still way 
behind on email):

>> Hello Noah. 8-)
>>  On today's telcon, you seemed to suggest that you would support
>> completely tying RPC to the SOAP data model or even encoding.
>>  Does that mean that you would disallow using encodingStyle
>> inside the data? Would you disallow the following?
>> 
>>  <Body>
>>    <foo:processUDDIRequest>
>>      <theRequest SOAP-ENV:encodingStyle="urn:uddi">
>>        <findTModel>
>>          ...
>>        </findTModel>
>>      </theRequest>
>>    </foo:processUDDIRequest>
>>  </Body>
>> 
>>  Let's say that urn:uddi signifies an encoding of a different
>> data model than SOAP's.
>>  My opinion is that this should be possible (as opposed to 
>> forbidden).

I think I would mostly forbid it, or at least have the results dependent 
on the outermost encoding.  More specifically, I would suggest the 
following:

* The purpose of Chapter 7 is to allow general purpose middleware to bind 
SOAP messages to languages such as Java, PERL, etc.  To do this 
effectively, any given implementation needs to know in advance the range 
of data models and encodings to be accepted.

* SOAP 1.1 chapter 5 embodies a data model (structs, arrays, schema simple 
types) and one encoding of that model.  SOAP v1.1 chapter 7 specifically 
says that the arguments to an RPC are modeled as a struct.  Of course, to 
understand what the struct is you must understand the types and encodings 
of the entire data graph that the struct references.  So, if somewhere in 
the graph you switch to an encoding that is arbitrary, I don't see how the 
deserializers and language bindings can do their job.

* I have suggested that the dependency should be on the model (structs) 
rather than on the particular encoding.  So, I would suggest that it be 
possible, if not necessarily desireable, for you to be able to define a 
new encoding that (a) includes the base SOAP data model, and therefore 
provides the struct model on which the RPC spec depends and (b) 
specifically defines the interpretation of a nested encoding switch, in 
effect including the new encoding in its own definition. 

In short, I think you want the deserializers to have the information they 
need to reconstruct the data graph in all cases.  Otherwise, you're 
effectively switching into flat message mode in the middle of an RPC. 
Actually, I do think it would be interesting to add some types that 
represent XML itself, but that's mostly a different discussion.

-----------------------------------------------------------------------
Noah Mendelsohn                                    Voice: 1-617-693-4036
Lotus Development Corp.                            Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------------

Received on Thursday, 23 August 2001 00:09:24 UTC