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

Re: Relationship between SOAP data model, SOAP encoding, and RPC

From: Jacek Kopecky <jacek@idoox.com>
Date: Wed, 15 Aug 2001 23:10:09 +0200 (CEST)
To: Henrik Frystyk Nielsen <henrikn@microsoft.com>
cc: <xml-dist-app@w3.org>
Message-ID: <Pine.LNX.4.33.0108152242000.24526-100000@mail.idoox.com>
 Henrik,

 I'd like to voice my concern with trying to map RPC onto the
SOAP data model. IMHO the mapping may not be natural.

 Right now, for example, we're trying to solve the issues with
the return value.

 You see, RPC request maps very naturally onto a structure
because every single piece of information that is needed has its
place:

 1) the procedure name is the accessor for the root structure
 2) the parameter names are the accessors inside the root
structure

 On the other hand, RPC response has a few things that may be
dirty:

 1) Because RPC assumes correlation of request-response message
pattern, the root structure doesn't have a natural name. It might
be named as the procedure with "Response" but SOAP/1.1 says it's
unnamed. This is still OK from the encoding point of view,
though.
 2) The return value of a call is unnamed. Now this is a problem
because unnamed things cannot be members of a structure. If we
model the result as an array of parameters, it would not be
symmetrical with the request. If we model both as arrays, the
thing is not simple any more.

 There is the additional issue that some implementations might
not want to implement an encoding of the SOAP directed-graph data
model, while they still might want to use RPC (probably with a
simpler data model and encoding).

 So I think there is a completely different way of solving your
issue no. 3:

 Create a simple specialized data model for RPC. This data model
needn't be explicitly described in any text because it only uses
the RPC terms like call, parameter and return value.

 Create an arbitrary encoding of this data model (which may or
may not resemble the current practice in encoding RPC calls).
This encoding should be described in terms of infoset.

 The parameters of the call would have to be serialized using a
different, more general, data model and encoding; we would, of
course, suggest our data model and our encoding. The
encodingStyle attribute on the parameters could be defaulted by
an attribute on the call.

 I hope I get to formulating and sending out a proposal for
concrete wording and syntax of the above.

 In my opinion this approach would be much cleaner unless we find
a reasonable mapping of the result to the SOAP data model.
Indeed, if we do find such a reasonable mapping, I probably would
+1 your or similar solution to #3.

 Best regards,

                            Jacek Kopecky

                            Idoox
                            http://www.idoox.com/




On Tue, 14 Aug 2001, Henrik Frystyk Nielsen wrote:

 >
 > As part of the discussions about the SOAP RPC convention in section 7
 > [1] and how it relates to section 5 [2], the RPC taskforce are
 > considering the following clarification outlined below. Before we spend
 > cycles on doing any edits, we would like to get input on whether this is
 > a reasonable position or whether there are reasons for not doing it.
 >
 > This mail is my attempt to summarize the proposal to a larger audience -
 > please comment as appropriate.
 >
 > Issue 1: SOAP Section 5 currently defines a directed graph data model
 > with elements like struct, array, id/href, etc. *as well as* a
 > particular encoding of that data model without clearly separating the
 > two.
 >
 > Clarification 1: We would like to clarify the relationship between the
 > data model and the particular encoding by saying that the SOAP encoding
 > is one of several potential encodings of the SOAP data model.
 >
 > Issue 2: The formulation of the definition of the root attribute is
 > obscure
 >
 > Clarification 2: The SOAP Root attribute defined in section 5.6 [3] is
 > part of the SOAP encoding and can be used to disambiguate roots from
 > non-roots when this is not apparent from the encoded instance.
 >
 > Issue 3: The relationship between section 5 and section 7 is unclear
 >
 > Clarification 3: Make clear that the RPC convention is based on the SOAP
 > data model and point out that the RPC invocation or the result of an
 > invocation is modeled as a single-rooted instance of the SOAP data model
 > where the root of the instance is the RPC invocation or the result of
 > the RPC invocation.
 >
 > As for any other data modeled using the SOAP data model, the RPC
 > convention can use the SOAP encoding to represent an instance of an RPC
 > invocation or the result of an invocation. In case the SOAP encoding is
 > used and a single root can not be unambiguously determined, the SOAP
 > Root attribute can be used to determine roots from non-roots.
 >
 > Henrik Frystyk Nielsen
 > mailto:henrikn@microsoft.com
 >
 > [1] http://www.w3.org/TR/2001/WD-soap12-20010709/#_Toc478383512
 > [2] http://www.w3.org/TR/2001/WD-soap12-20010709/#_Toc478383532
 > [3] http://www.w3.org/TR/2001/WD-soap12-20010709/#_Toc478383501
 >
Received on Wednesday, 15 August 2001 17:10:12 GMT

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