RE: Proposed resolution: issues 78, 16

Henrik, Jacek, Noah,

Under (a) and (b) roots have an identification mechanism.  How does this
logically differ from v1.1, v1.2-WD versions which specifies how non-roots
are identified?  Under Sec 5 encoding there is no concept of "top element"
below body (rpc or non-rpc), however Sec 5.6 relates how to distinguish
roots and non-roots (rpc or non-rpc).  My interpretation of Sec 5 encoding
with regard to rpc is that if you have one serialization root in an rpc,
that serialization root is the method wrapper element.  If you have more
than one, it's not an rpc(albeit you could change this to allow boxcarring).
One could easily assume from Sec 5.6 (especially in v1.2-WD) that
independent elements unmarked with "root" attribute are serialization roots.

1) What is the downside of requiring non-serialization roots be marked with
SOAP-ENC:root="0" (rpc or non-rpc)?
2) Does this not remove the ambiguities?


-Matt

>
>
> 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 12:44:38 UTC