RE: Issue with soap-rpc:result

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 Thursday, 14 February 2002 14:08:09 UTC