RE: Issue with soap-rpc:result

 Noah, I meant the "literal" rewrite of RPC to do exactly that - 
to define an RPC data model and its serialization and mandate 
that. Most important, though: this data model and its 
serialization need not be described separately because both are 
made for just one use - this RPC.
 The following was first meant to be a short description, but it 
grew up into a full-blown (although raw) set of rules.
 The idea is:
 0) we expect that there is a procedure (an invokable thing)  
which has a name. A procedure may have an otherwise unnamed
return value. A procedure may have a set of (procedure-scope)
uniquely named parameters going there, both ways or back. A
procedure may specify a constant ordering for its parameters.
 1) inside the Body of the request message the first element
information item is the RPC request element, its qname indicating
the operation.
 2) the RPC request element contains only children element
information items whose qnames must indicate the parameters'
names. They should be ordered according to the order of 
parameters in the original procedure, if the order or the 
original procedure is available.
 3) inside the Body of the response message, unless it is a 
fault, the first element information item is the RPC response 
element. Its qname can be anything at all.
 4) the RPC response element contains only children element 
information items whose qnames must indicate the out parameters' 
names. If the procedure has a return value, it must be the first 
parameter and it must be named rpc:result.
 5) if a parameter's value is NULL (if the parameter's data model
has such a concept), it may be omitted. Otherwise, the parameter
element information items carry the values of the actual
parameters as any child information items. They may be encoded
using any encodingStyle (which should be indicated on the
parameter eii) in complete accordance with the particular
encoding rules. If using the SOAP Encoding, an RPC request could
look like the following:

<env:Body>
  <ns:Operation xmlns:ns="...">
    <x id="1" xsi:type="xsd:int" env:encodingStyle="...">42</x>
    <y ref="1" env:encodingStyle="..."/>
  </ns:Operation>
</env:Body>

In this case, we have an operation named {...}Operation, with 
parameters named x and y. The value of the parameter x is encoded 
using the following children information items: attribute ii 
"id", attribute ii "xsi:type", character ii "42". The value of 
the parameter y is encoded using the child attribute ii "ref". 
The meaning of these information items depends on the encoding 
rules.

This is a raw draft but I think that it should be sufficient for 
a "literal" RPC. What do you think?

                   Jacek Kopecky

                   Senior Architect, Systinet (formerly Idoox)
                   http://www.systinet.com/



On Thu, 14 Feb 2002 noah_mendelsohn@us.ibm.com wrote:

 > I just sent a note outlining two options for how we model RPC overall. You 
 > are below presuming my "option #1", in which we say a lot about what 
 > parameters are and so on.   That's probably OK (I need to think some more) 
 > as long as we model the endpoint abstractions carefully as proposed in my 
 > last note. 
 > 
 > In doing so, we will discover that the change from encoded to non- 
 > represents a radically change in our view of the endpoint.  Implicit in 
 > SOAP 1.1 was that the endpoints dealt in a set of graph structures, and 
 > that the arguments and parameters were windows into such graphs.   In your 
 > new unencoded world we must similarly state carefully how we view the 
 > contract between endpoints.  If the elements that you associate with the 
 > parameters have href/id constructs for example, does that represent a 
 > connection that means anything in a way we can discuss?  Are we ruling out 
 > such IDs?
 > 
 > I don't think we can have it both ways.  If we are going to allow any XML 
 > under the method name, then it's tricky to claim that it's really a set of 
 > separate arguments to a method.  If we really mean the elements to be 
 > separate, then we need to describe the restricted set of XML constructs 
 > that are legal and have meaning in the RPC model.  That's a data model and 
 > encoding.  It may be a much simpler one than we now have, and it may map 
 > to much more natural XML structure in simple cases, but it's still an 
 > encoding and we should name and document it.  I'm uncomfortable trying to 
 > say:  "well, you can sort of use any XML, except there are all these 
 > constructs that we sort of avoid and don't really tell you about cleanly, 
 > but at least didn't have all that complicated encoding stuff."  If we're 
 > using all of XML, and can find a useful way to map it as RPC, that's 
 > great.  Let's consider it.  If we want a new model and encoding that's 
 > less ambitious and more XML-like than the old one, let's propose that. 
 > Let's not do the latter and label it as the former. 
 > 
 > Maybe I've misunderstood.  I should confess to not having actually 
 > programmed with any of the systems such as .Net that provide automatic 
 > document style mappings.  I strongly suspect that they deal best with 
 > stylized uses of XML, in which case they are in some sense encoded.  I 
 > could be wrong about that.  If so, please let me know what I'm missing.
 > 
 > ------------------------------------------------------------------
 > Noah Mendelsohn                              Voice: 1-617-693-4036
 > IBM Corporation                                Fax: 1-617-693-8676
 > One Rogers Street
 > Cambridge, MA 02142
 > ------------------------------------------------------------------
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > Jacek Kopecky <jacek@systinet.com>
 > 02/13/2002 04:45 AM
 > 
 >  
 >         To:     Noah Mendelsohn/Cambridge/IBM@Lotus
 >         cc:     Tim Ewald <tjewald@develop.com>, "'XMLDISTAPP'" <xml-dist-app@w3.org>
 >         Subject:        RE: Issue with soap-rpc:result
 > 
 > 
 > Noah,
 > the following things would be left in the RPC section:
 > 1) that the dispatch is based on the QName of the first
 > immediate child of Body, and that its local name is based on the
 > procedure's name;
 > 2) that the parameters' names are based on the names in the
 > procedure's declaration and that the parameters' actual values
 > are elements in the procedure element (see 1) in the same order
 > as in the procedure's declaration (if available);
 > 3) that the result is an first child element of Body (its name
 > being irrelevant)
 > 4) that the return value is the first out parameter, named
 > enc:result.
 > 
 > The pros of this change: we can serialize parameters using other
 > encodingStyles (even different ones), we can keep ordering
 > restrictions (unavailable in the Encoding's structs), we don't
 > have to worry about serialization roots in the Body.
 > The cons: we'd probably have to duplicate some stuff from the
 > Encoding regarding null parameter values and completely
 > descriptive messages would probably have to contain encodingStyle
 > attribute on each of the parameters.
 > 
 > It seems to depend on the respective values of the pros and
 > cons. I can have it both ways. 8-)
 > 
 > Best regards,
 > 
 > Jacek Kopecky
 > 
 > Senior Architect, Systinet (formerly Idoox)
 > http://www.systinet.com/
 > 
 > 
 > 
 > On Tue, 12 Feb 2002 noah_mendelsohn@us.ibm.com wrote:
 > 
 > > Jacket Kopecky writes:
 > >
 > > >> Therefore I vote yes on 2 - decoupling RPC from
 > > >> the graph data model
 > >
 > > It's interesting to ask what's left of RPC when we do this.  We've 
 > already
 > > separated out request/response as an exchange pattern, so we've got 
 > that.
 > > By leaving out the data model, we're eliminating any fixed notion of how
 > > arguments are results are modeled, except to say that they are XML.  The
 > > only thing I can think of that's left is to indicate that the QName of 
 > the
 > > immediate child of <Body> is the key to dispatching the service to be
 > > performed (keep in mind that our default rules for handling bodies are 
 > now
 > > looser than that.)  What else would be left of RPC in your proposal (I'm
 > > neither endorsing nor disagreeing with it, just asking for 
 > clarification).
 > >  Thanks.
 > >
 > > ------------------------------------------------------------------
 > > Noah Mendelsohn                              Voice: 1-617-693-4036
 > > IBM Corporation                                Fax: 1-617-693-8676
 > > One Rogers Street
 > > Cambridge, MA 02142
 > > ------------------------------------------------------------------
 > >
 > >
 > >
 > 
 > 
 >

Received on Friday, 15 February 2002 08:16:27 UTC