- From: Jacek Kopecky <jacek@systinet.com>
- Date: Thu, 25 Apr 2002 01:37:03 +0200 (CEST)
- To: Martin Gudgin <martin.gudgin@btconnect.com>
- cc: Ray Whitmer <rayw@netscape.com>, <xml-dist-app@w3.org>
Gudge,
see inside. 8-)
Jacek Kopecky
Senior Architect, Systinet (formerly Idoox)
http://www.systinet.com/
On Wed, 24 Apr 2002, Martin Gudgin wrote:
> SOAP Data Model says nothing about return values
> SOAP Encoding says nothing about return values
> Only RPC cares about return values.
>
> Therefore only SOAP processors that care about RPC care about return values.
I agree up to here.
> Such SOAP processors need to know which infoset property contains the return
> value
When using SOAP Data Model, it's unnecessary to deal with the
infoset, all you need is in the graph because what was serialized
was a graph.
Once you start adding attributes to edges, you're extending the
Data Model and the Encoding. I believe I've said this a few times
already and I believe you never said "no, it's untrue".
Similarly, if you're dealing with the infoset, you're building an
encoding processor (which is OK, by the way). If this processor
can give you more than a SOAP Data Model graph (e.g. one with the
additional information "this is the return value"), you're
extending the Data Model again.
I've said before that with an extended Data Model (and Encoding)
you can do this, but you seem to disagree with the need to extend
the Data Model to deal with an attribute. Is this true? If so,
I'm afraid I don't understand how you can do it, so please
explain it, especially with respect to the *separate* SOAP
Encoding layer.
> With the attribute approach such SOAP processors need to serialize and
> deserialize the return attribute appropriately. The attribute approach puts
> all the responsibility onto the RPC layer. Mandating a particular name for a
> graph edge smears the idea of return values across RPC, encoding and data
> model.
>
> Gudge
Received on Wednesday, 24 April 2002 19:37:05 UTC