- 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
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 UTC