RE: Proposed resolution: issues 78, 16

 Noah,
 I'm NOT recommending (b). Sorry for such an emphasis but I feel
this might be otherwise overlooked.
 My wording would be:
 j) RPC chapter says (roughly): "The first or otherwise specified
element inside the Body is the RPC element. The RPC element
contains child elements whose names match the names of the
arguments of the procedure (the first element in the response
being the return value, if the procedure has a return value). Each
argument element's child nodes (including the attributes) is
determined by the serialization of the value of the appropriate
argument."

 The "otherwise specified" is quite intentionally meant as "by
means of an attribute on the Body element" because in this way you
would
 a) stay backwards compatible with SOAP/1.1 RPC,
 b) not need to search the whole contents of the Body element in
case the attribute was not used (whereas you would have to do so
in case of _not_ using the soap-enc:root attribute - in order to
see it's really not used). I don't suggest we use an attribute
_on_the_RPC_element_.

 Also note that there is only one reference to serialization in
the text, that also is intended. This puts no restraint on the
encodings and more importantly the representation of the RPC
element doesn't differ if we use a different encoding. Imagine an
RPC call such as this:

<soap-env:Envelope ...>
  <soap-env:Body>
    <struct soap-env:encodingStyle="http://my.org/funky-encoding"
            xmlns="http://my.org/funky-encoding">
      <name>GetStockQuote</name>
      <argument name="stock">
        <string>GM</string>
      </argument>
    </struct>
  </soap-env:Body>
</soap-env:Envelope>

IMHO this is a valid SOAP/1.1 RPC call exactly following the rules
in section 7, just with my own funky encoding. I want to avoid
such a possibility.

                            Jacek Kopecky

                            Idoox
                            http://www.idoox.com/




On Mon, 6 Aug 2001 Noah_Mendelsohn@lotus.com wrote:

 > 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 17:11:47 UTC