Re: RSVP: Resolution to issue #29 satisfactory? (fwd)

 Gudge,
 I think RPC is very much a programming concept. Most programming
environments use some kind of data model close or equal to the
(so far implied) data model of SOAP Encoding.
 It should be clear that there may be lots of different mappings
from this data model to XML (infoset) data model. If we present a
single simple mapping, the implementors of generic SOAP RPC
libraries/systems have a considerably easier job, IMHO, and I
speak now as such an implementor.
 I agree that non-RPC application usually work with the XML so
they can be coded to a schema. The RPC applications, on the other
hand, can now be developped very easily with no interaction with
XML because of SOAP Encoding of their native data model (or one
that's very close).
 So I think SOAP encoding is quite a reasonable thing to have if
we have RPC.
 Best regards

                   Jacek Kopecky

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



On Wed, 7 Nov 2001, Martin Gudgin wrote:

 >
 > The whole point of SOAP Encoding initially was that because we didn't have a
 > schema language we needed to start from some other type system. SOAP Section
 > 5 ( as it was known at that time ) gave us some standard rules for what to
 > do when starting from a programmatic type system like C++ or Java. At the
 > time this was useful.
 >
 > We now know a lot more about XML than we did in 1998/1999. And we now have a
 > schema language. So I would argue that even in the 'RPC' case two parties
 > could just agree what the XML is going to look like and be done.
 >
 > Now, is there benefit to having a 'standard' encoding style? I don't know.
 > It doesn't seem like much of a burden to me to just look at what a given
 > endpoint expects and what it returns and then code for it. If I have a
 > schema description I can probably generate the code from that. But I may be
 > in a minority here by thinking that what goes on the wire is the place to
 > start rather than starting with code...
 >
 > Regards
 >
 > Gudge
 >
 >
 > ----- Original Message -----
 > From: "Dan Brickley" <danbri@w3.org>
 > To: "Martin Gudgin" <marting@develop.com>
 > Cc: "Christopher Ferris" <chris.ferris@sun.com>; "Jacek Kopecky"
 > <jacek@systinet.com>; <bprice@us.ibm.com>; <xml-dist-app@w3.org>
 > Sent: Wednesday, November 07, 2001 4:17 PM
 > Subject: Re: RSVP: Resolution to issue #29 satisfactory? (fwd)
 >
 >
 > >
 > > On Thu, 1 Nov 2001, Martin Gudgin wrote:
 > >
 > > > ----- Original Message -----
 > > > From: "Dan Brickley" <danbri@w3.org>
 > > > To: "Christopher Ferris" <chris.ferris@sun.com>
 > > > Cc: "Jacek Kopecky" <jacek@systinet.com>; <bprice@us.ibm.com>;
 > > > <xml-dist-app@w3.org>
 > > > Sent: Thursday, November 01, 2001 3:16 PM
 > > > Subject: Re: RSVP: Resolution to issue #29 satisfactory? (fwd)
 > > >
 > > >
 > > > <SNIP>Long version</SNIP>
 > > >
 > > > > Short version: "what is SOAP-encoding for? what is it *not* for?"
 > > >
 > > > Dan,
 > > >
 > > > There are many people, myself included, that do not think that an
 > encoding
 > > > schema is necessary for many iteractions. Two parties just need to agree
 > on
 > > > what the XML is going to look like for a given exchange.
 > > > This will probably be defined in a schema of some sort. There is no need
 > for
 > > > any 'standard' data encoding in many of these cases. In fact, I would go
 > so
 > > > far as to say we only need a 'standard' encoding for cases where two
 > parties
 > > > cannot agree by defining a schema.
 > > >
 > > > Martin
 > >
 > > So would you go so far as to say that SOAP Encoding is basically just
 > > used for RPC? I've heard this from others offlist, but the 1.2 spec and WG
 > > charter had given me the impression that it might be intended for wider
 > use.
 > >
 > > Dan
 > >
 >

Received on Thursday, 8 November 2001 04:58:52 UTC