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

RE: Proposed resolution: issues 78, 16

From: Jacek Kopecky <jacek@idoox.com>
Date: Mon, 6 Aug 2001 09:04:25 +0200 (CEST)
To: Henrik Frystyk Nielsen <henrikn@microsoft.com>
cc: <Noah_Mendelsohn@lotus.com>, <mlong@phalanxsys.com>, <xml-dist-app@w3.org>
Message-ID: <Pine.LNX.4.33.0108060856430.20368-100000@mail.idoox.com>
 if the RPC convention says it is "modeled as a single-rooted
instance of a directed graph within the SOAP encoding data model"
it has ties to the SOAP encoding data model. The (abstract) data
model is not specified explicitly anywhere in SOAP/1.1, nor is it
specified (AFAIK) in SOAP version 1.2.

 If we specify the data model, we can have three sections with
such dependencies:
 1) abstract data model
 2) encoding, depends on 1
 3) RPC, depends on 1

 The problems I see with this approach are:
 a) the abstract data model is either too complicated or
restricts the possible encodings too much,
 b) RPC on-the-wire representation depends on the used encoding.

 We might also try to say "here is a simple data model, here is
RPC that depends on any encoding that follows this simple data
model" but then, since the data model would be so simple,
section-5 encoding would be sufficient to cover it and no other
encodings for this data model would have to be invented, so we
would end up in a situation even worse than today - RPC would
depend on the simple data model but we wouldn't have the
certainty about the actual encoding used, while in fact it would
usually be section 5.

                            Jacek Kopecky


On Sun, 5 Aug 2001, Henrik Frystyk Nielsen wrote:

 > I may be missing something but 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?
 > Note here that I am making a distinction between this question and
 > whether the RPC convention has to be serialized using the SOAP section 5
 > encoding style or not (which I don't think is the case). That is, it is
 > possible to invent other encoding styles for this particular RPC
 > convention using the encodingStyle attribute.
 > Henrik
 > >Jacek writes:
 > >
 > >>>  RPC needs to point to the RPC element while
 > >>> an encoding wants to mark serialization
 > >>> root(s).
 > >
 > >+1.  This is exactly the right distinction between the two. Again, I'm
 > >still not 100 percent sure I'm ready to endorse any particular
 > >approach,
 > >but I think the distinction in the potential needs is just
 > >right.   For
 > >better or worse, the chapter 5 encoding provides a graph data
 > >model.  One
 > >of its uses is for RPC, but there are other potential uses.  The root
 > >attribute distinguishes certain nodes in the graphs.  Chapter
 > >7 provides
 > >for remote procedure call:  the proposed START tag marks the
 > >element that
 > >identifies the service to be called, I think.  I wonder
 > >whether something
 > >like METHOD= or CALL= might be more suggestive than START?
 > >I'm not sure
 > >we are really starting anything, so much as distinguishing the element
 > >that identifies the call to be attempted.
Received on Monday, 6 August 2001 03:04:48 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:15 UTC