RE: Proposed resolution: issues 78, 16

 Matt,
 IMHO Noah's (a) and (b) aren't significantly different.
 The downside you're asking for in your (1) is this: it would
break backwards compatibility. Many SOAP RPC implementations
don't mark non-roots with root="0".
 It would indeed remove the disambiguities but we also want to
remove the dependence of RPC on encodings, see my reply to Noah
in [1] for the main of my reasons.

[1] http://lists.w3.org/Archives/Public/xml-dist-app/2001Aug/0063.html

                            Jacek Kopecky

                            Idoox
                            http://www.idoox.com/




On Mon, 6 Aug 2001, Matt Long wrote:

 > 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 17:16:55 UTC