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


> -----Original Message-----
> From:
> []On
> Behalf Of Henrik Frystyk Nielsen
> Sent: Tuesday, August 14, 2001 12:43 PM
> To:
> Subject: Relationship between SOAP data model, SOAP encoding, and RPC
> 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.

It would seem *more elegant* and natural to precisely claim that independent
elements NOT encoded with SOAP-ENC:root are equivalent to
SOAP-ENC:root="1",i.e., serialization roots, and only independent elements
encoded SOAP-ENC:root="0" are non-serialization roots.  Similar
clarification of the location of where these elements can be appropriately
scoped, which would also seem natural to be scoped by either Header or Body.

The pseudo-issue of "backward compatibility" only exists on the application
level and not on the interoperability level.  My testing indicates
considerable non-interoperability between implementations once one increases
the complexity of a request under root + id/href, i.e., each implementations
enforces their own specific rules.  I would consider a goal *scalable*
interop, and thus I believe my assertions regarding resolution of "root" are
inline with this goal.

There is natural overflow to the concern of orthagonality of headers and
body, meaning whether there will be a prohibition of headers referencing
independent elements in body.

> 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
> [1]
> [2]
> [3]

Received on Wednesday, 15 August 2001 12:43:09 UTC