- 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>
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 UTC