W3C home > Mailing lists > Public > xml-dist-app@w3.org > August 2001

RE: Proposed resolution: issues 78, 16

From: <Noah_Mendelsohn@lotus.com>
Date: Mon, 6 Aug 2001 10:38:34 -0400
To: "Henrik Frystyk Nielsen" <henrikn@microsoft.com>
Cc: "Jacek Kopecky" <jacek@idoox.com>, mlong@phalanxsys.com, xml-dist-app@w3.org
Message-ID: <OF549D2E35.010474AE-ON85256AA0.004E1E11@lotus.com>
Henrik Frystyk Nielsen writes:

>> if an RPC invocation or the result of an
>> invocation is modeled as a single-rooted 
>> instance of a directed graph
>> within the SOAP encoding data model then 
>> why is additional information
>> needed to identify the top element of the 
>> invocation or result of that
>> invocation?

I'm happy to do this either way, as long as the solution adopted is 
architecturally clean.  Among the ways to do this are roughly:

a)  RPC chapter says (roughly):  "You must use an encoding of a data 
model.  That data model model must represented a directed graph of labeled 
values {etc., etc.}  which must include an encoding of "record" 
structures, in which fields are uniquely labeled.   It is a requirement 
that any encoding of that data structure uniquely identify a "root" of the 
graph, which must be of type "record"  and which is taken as the 
representation of the argument list."  I think this option is the closest 
to SOAP 1.1/SOAP 1.2, and as you say it does not rely on any "call" or 
"method" arguement at the RPC level, and what Henrik seems to be 
recommending.

b) RPC chapter says (roughly):   "You must use an encoding of a data 
model.   That data model model must represented a directed graph of 
labeled values {etc., etc.}  which must include an encoding of "record" 
structures, in which fields are uniquely labeled.   The node which 
represents the call itself must be labeled with the 
SOAPRPC:ProcedureInvocation argument, which  which must encode an item of 
type "record"  and which is taken as the representation of the argument 
list."   This seems to be what Jacek  is recommending.  This makes the RPC 
model just slightly more complicated, but makes the contract between the 
RPC chapter and the encodings a bit simpler:  it does not require the 
encodings to have their own notion.

c) Make the RPC system dependent on exactly the encoding in chapter 5, 
with no alternatives possible.

I have no strong preference between (a) and (b), don't much like (c).  As 
I have said before, it might be nice to do a simple job of naming data 
models.  Then we can say:  "The default data model for SOAP includes, 
records (structs), multi-structs, and arrays, along with the simple types 
from XML Schema Datatypes.  RPC calls and responses can be represented 
using any encoding for the SOAP default data model."  Then in chapter 5, 
you describe the default data model, and say "to promote interoperability, 
SOAP provides a standard encoding for the default data model (which is 
essentially the one we've had in chapter 5 all along).

------------------------------------------------------------------------
Noah Mendelsohn                                    Voice: 1-617-693-4036
Lotus Development Corp.                            Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------------
Received on Monday, 6 August 2001 10:50:00 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:03 GMT