RE: Issue with soap-rpc:result

> 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 Friday, 8 February 2002 21:34:24 UTC