W3C home > Mailing lists > Public > xml-dist-app@w3.org > April 2002

Re: Issue 195: soap-rpc:result

From: Jacek Kopecky <jacek@systinet.com>
Date: Mon, 8 Apr 2002 22:09:42 +0200 (CEST)
To: Noah Mendelsohn/Cambridge/IBM <noah_mendelsohn@us.ibm.com>
cc: Ray Whitmer <rayw@netscape.com>, <xml-dist-app@w3.org>
Message-ID: <Pine.LNX.4.44.0204082156350.12891-100000@mail.idoox.com>
 Noah, please see my comments below.

                   Jacek Kopecky

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



On Mon, 8 Apr 2002, Noah Mendelsohn/Cambridge/IBM wrote:

 > I probably came on a bit too strong in the note that you
 > quote.  I think the use of schema in WSDL to describe encoded
 > graphs involves some unfortunate compromises, and I think that
 > the WSDL group should take a hard look at these issues.  That
 > said, I think that existing experience with WSDL shows that
 > conventions can be developed to promote a substantial degree
 > of interoperability based on current WSDL technology and SOAP
 > graph encodings.

I agree.

 > The decision tree that I suggest we follow is this: 
 > 
 > * If SOAP indeed requires a fairly general graph encoding that
 > can model traditional programming language data structures,
 > then I think the one we have is reasonable.  I'm not sure
 > there is any other graph encoding we would propose that would
 > be more schema friendly.  On the contrary, I believe ours
 > works particularly well with schema. The other way to go would
 > be to drop the SOAP graph encoding entirely, and use an
 > XML-tree representation for RPC arguments. This would support
 > only a subset of the RPC's that we can do today, but would
 > model more directly in XML schema of course. 

I disagree that it would support a subset of the currently
possible RPCs. But there are two issues here. The first is the 
dependence of SOAP RPC on SOAP Encoding. The other is the 
presence of either in SOAP spec. 

As I had proposed, we could make RPC based on XML and not on SOAP
Encoding (or Data Model, to be precise). This would not disallow
SOAP Encoding, it would make it optional in RPC and also some
other issues on RPC would not exist at all.

I don't think anyone will argue that dropping SOAP Encoding and 
SOAP RPC from SOAP would limit the use of SOAP - both are 
adjuncts and can be replaced by similar work of other parties. 
But I agree that having SOAP Encoding and SOAP RPC in the spec 
will help with wider adoption of SOAP.

 > On the other hand, I'm not at all sure this would meet the
 > expectations of the SOAP community, and I believe we have a
 > specific requirement in our charter, which calls for: "A
 > mechanism for serializing data representing non-syntactic data
 > models such as object graphs and directed labeled graphs,
 > based on the datatypes of XML Schema." [1]
 >
 > * Presuming that we do want to keep a graph model, then the
 > burden then falls on the WSDL group to decide what modeling
 > technology to use for interface contracts.  As I say, what
 > they have works moderately well for many common cases.

I agree again, and I believe the next version can work completely
well (at least in the area of data encoding and description), not
just moderately well.

 > So, I apologize for having been a bit too extreme in my
 > earlier analysis.  I do think there are some issues, but on
 > balance I am not prepared to recommend at this point that
 > protocols workgroup abandon the current graph encoding.  
 > Thank you.
 > 
 > [1] http://www.w3.org/2000/09/XML-Protocol-Charter#scope
Received on Monday, 8 April 2002 16:09:46 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:09 GMT