RE: Issue with soap-rpc:result

 Tim, others,
 I see a push away from a graph model to a tree described by XML 
Schema here. I think mostly you are pushing an open door.
 We have two orthogonal ways to proceed if we want to change 
something:
 1) change the SOAP Data Model and SOAP Encoding to, possibly, a 
set of guidelines for mapping some kinds of graphs to XML Schema 
structures,
 2) change the SOAP RPC convention to be based on pure XML, not 
on the Data Model.
 These approaches can be combined, too.

 I'll start with 2: I support this change, only the majority on 
the RPC task force was of the opinion that the RPC convention 
should be based on our data model.
 And I think this is really what Tim and probably Andrew, too, 
want. Since IMO RPC is orthogonal to any Data model, it could 
(and should) be modeled as such - as I indicated before, we could 
make the request an element, the parameters elements, too, and 
these elements could be encoded using any (or no) encoding like 
the SOAP Encoding of the SOAP Data model. Therefore the 
parameters' values could be in any data model, even in different 
ones.

 Let me get back to 1: There has been a lot of effort in the 
Encoding task force to clarify and simplify the Encoding rules in 
order to minimalize the problems in implementations (and as an 
implementor myself, I think we've done a great deal). 
 The situation with SOAP Encoding should not be view as forcing 
the implementors to choose. It's rather that the SOAP Data model 
and the SOAP Encoding thereof are attempts to standardize the 
interchange of data in a very common data model. SOAP is not 
going to be used only to develop new applications in "the XML 
way", it is going to be used to connect to existing applications, 
often on the principle of RPC, often with data in a graph data 
model not unlike ours. This is the reason for the RPC and the 
Encoding sections, as I see it. 

 Therefore I vote yes on 2 - decoupling RPC from the graph data 
model (which is unnecessary and over-complex for the task of 
representing RPC requests and responses), and I vote no on 1 - 
effectively removing the Data Model and the Encoding. (I don't 
want to describe our Data model's structures with XML Schema, 
that's like describing curves with a linear model.)

 The only problem is that the question 2 was already discussed in
the summer in the RPCTF, and that the WG might be reluctant to
(re)open this issue. It can always be indicated that our adjuncts
are not mandatory and that not using them is nothing bad at all
when the task is incompatible with the assumptions of the
particular adjunct.

 Best regards,

                   Jacek Kopecky

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



On Fri, 8 Feb 2002, Tim Ewald wrote:

 > > Now, I can understand the case for dropping the graph model entirely;
 > 
 > To be frank, this is where I want to go and I should just admit it. :-)
 > 
 > I *strongly* believe that we should focus on what XML's native model,
 > i.e., trees, and work out from there. I'm very much afraid that we are
 > headed down a path where people will be forced to choose between SOAP's
 > graph-oriented data model and the tree-based world of XML.
 > 
 > I agree that providing schema(s) for representing a graph as a tree is
 > not optimal because of all the possible permutations. However, it is
 > possible to define a schema for the results of applying a particular
 > encoding. I'd *rather* just use XSD and work with trees, because that's
 > what all of the XML tools and technologies are designed to support. But
 > if I have to accept an alternative like the SOAP data model, I want a
 > way to get back to trees, even if I need a different, ugly schema for
 > each encoding scheme (and this is basically what the SOAP encoding rules
 > do anyway).
 > 
 > I'd really prefer that we stay away from a language for describing
 > graphs in terms of structs, arrays, etc. In XML, we have a viable
 > cross-vendor/language/platform way to represent and manipulate typed
 > data, with a tremendous amount of tool support. All of that is based on
 > trees. While trees certainly have limitations, I don't want to see us go
 > back to the beginning and start over with a language for graphs!
 > 
 > I would love to see SOAP 1.2 back off from graphs and encodings
 > altogether. I'd love to see SOAP message formats defined entirely in
 > terms of XSD, ensuring compatibility with all the other XML technologies
 > and tools. If that means that I can't transparently map arbitrary object
 > models to SOAP messages, I'm fine with that. To me, tight integration
 > with the rest of XML is more important. I also think it is what will
 > happen anyway. The vast majority of the people I talk to about SOAP
 > believe that "document/literal" is the way to go precisely because it is
 > based on XSD.
 > 
 > Of course, defining contracts in terms of tree-based messages makes
 > dealing with graphs harder. However, in many cases this is not an issue
 > and, in the cases where it is an issue, graphs can be mapped to trees in
 > a range of ways.
 > 
 > For me it is simple: if we are building on XML, we are building on
 > trees. I would rather be able to work directly with SOAP *and* XSD and
 > all the other XML technologies and push the issue of representing graphs
 > up to the application level then define SOAP in terms of graphs and
 > force people to adopt a new data model that XML doesn't natively
 > support.
 > 
 > I really believe that this change is actually critical to SOAP's future
 > success. I also believe that a lot of people - starting with me - are
 > going to work at the XSD level no matter what the SOAP RPC model says.
 > 
 > So, the question is: how many people would support the shift away form
 > graphs to XSD?
 > 
 > Thanks,
 > Tim-
 > 
 > 
 > 
 > > 
 > > ------------------------------------------------------------------
 > > Noah Mendelsohn                              Voice: 1-617-693-4036
 > > IBM Corporation                                Fax: 1-617-693-8676
 > > One Rogers Street
 > > Cambridge, MA 02142
 > > ------------------------------------------------------------------
 > > 
 > > 
 > > 
 > > 
 > 
 >

Received on Tuesday, 12 February 2002 04:40:13 UTC