Re: Issue 195: slightly updated simple proposal

----- Original Message -----
From: "Jacek Kopecky" <jacek@systinet.com>
To: "Martin Gudgin" <martin.gudgin@btconnect.com>
Cc: "Ray Whitmer" <rayw@netscape.com>; <xml-dist-app@w3.org>
Sent: Thursday, April 25, 2002 12:37 AM
Subject: Re: Issue 195: slightly updated simple proposal


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

You're right, I never said that ;-)

However, I'm not convinced that adding an attribute, in a seperate
namespace, is really extending the SOAP Data Model or the SOAP Encoding. The
model only deals in edge labels, node ids and terminal values. The encoding
only deals in element QNames, ref and id attributes, character children and
the attributes related to arrays. So, neither the encoding nor the model
would 'see' an attribute in another namespace. The only thing that will
'see' that attribute will be a SOAP processor that knows about RPC. I would
expect a processor that did not understand RPC to ignore such an attribute.

We don't explicitly state that such attributes are allowed in the SOAP
Encoding, but neither do we explicity rule them out. I personally think that
ruling out attributes in other namespaces, in general, is a bad idea,
because it limits the ability of users to annotate and otherwise add extra
information to things.

Gudge

>
> 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 Thursday, 25 April 2002 04:54:47 UTC