RE: Issue with soap-rpc:result

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

Yes.

>  2) change the SOAP RPC convention to be based on pure XML, not
> on the Data Model.

Yes.

>  And I think this is really what Tim and probably Andrew, too,
> want.

I definitely want this (and more ;-).

> these elements could be encoded using any (or no) encoding like

If SOAP 1.2 is going to define an RPC model, I think it should work when
no encoding is being used.

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

SOAP is XML messaging, so you are, by definition, developing new
applications in "the XML way". CORBA, COM and RPC were used to connect
existing applications too, but you had to write code to map an
application's internal data structures to data types that could be sent
on the wire. CORBA, COM and RPC themselves didn't address this issue.
They just told you what you could legally send and it was up to you to
coerce your data to that format.

It makes sense to me to say that SOAP uses XSD to describe what goes on
the wire and you have to map your application's internal data structures
to formats that could be sent on the wire. 

It doesn't make sense to me to say that SOAP has a data model that can
be mapped to the wire n different ways and that's what endpoints should
code against.

If there is a need to define a mapping from graphs to XML, it is
certainly orthogonal to SOAP. I would argue that this problem should be
addressed in a more fundamental way that applies to all XML technologies
so that we don't end up with lots of different specs defining their own
ways to deal with graphs. Similar to the Infoset, which formalizes XML's
tree model, if a graph model is needed, it should be pervasive and not
just part of SOAP.

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

I see the need to make forward progress and get the spec done. On the
other hand, I think this is a pretty fundamental issue and I'd like to
see it dealt with before the spec is done.

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

This is possible. There are already toolkits that implement RPC-style
programming models on top of XSD-defined message formats (i.e.,
document/literal). In the end, I think a lot of people will end up doing
this so they can have a data model that is compatible with the rest of
XML. I'd just like to avoid a world where there are some doc/literal
systems and some rpc/encoded systems, when both can present a
programming model that looks like RPC (with some subtle differences). It
think developers would be justifiably unhappy in that world.

Thanks,
Tim-

Received on Wednesday, 13 February 2002 14:30:24 UTC