Re: Issue 195: slightly updated simple proposal

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.

Such SOAP processors need to know which infoset property contains the return
value

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


----- 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: Wednesday, April 24, 2002 11:16 PM
Subject: Re: Issue 195: slightly updated simple proposal


> Gudge,
>  in your proposal RPC affects two layers of data - the XML
> serialization (the infoset) and the graph data.
>  Deserialization: We cannot say "the edge which has the attribute
> rpc:return" because an edge has no such thing as an attribute. So
> on the XML level we could select the element which has the
> attribute and then deserialize the whole structure and
> independently the return value. We'd get two graphs, one subset
> of the other. Since the graph data model doesn't even know about
> IDs, there'd be no way of correlating the result graph with one
> of the out parameters so we wouldn't know which parameter we
> don't have to deal with any more.
>  Serialization: the RPC processor will have the result struct
> serialized, which results in XML without the attribute. It then
> has to go through this XML data *with the knowledge of the used
> Encoding* and put the attribute on the appropriate element.
>  Of course there can be a special SOAP Encoding processor that
> knows about this metadata but this is in fact equivalent to the
> extended data model and an encoding thereof.
>  I don't think that encodingStyle is an example of such metadata
> - it has no effect on the data model layer.
>  Best regards,
>
>                    Jacek Kopecky
>
>                    Senior Architect, Systinet (formerly Idoox)
>                    http://www.systinet.com/
>
>
>
> On Wed, 24 Apr 2002, Martin Gudgin wrote:
>
>  >
>  > ----- 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: Wednesday, April 24, 2002 8:17 PM
>  > Subject: Re: Issue 195: slightly updated simple proposal
>  >
>  >
>  > > Gudge,
>  > >  the problem is we're saying an RPC result is a struct (or array,
>  > > but it's analogous). We can put some information in the struct,
>  > > which would get serialized according to the SOAP Encoding rules,
>  > > but we cannot extend the rules.
>  > >  It would be possible if we didn't make RPC based on SOAP
>  > > Data Model but on infoset instead, with parameters possibly
>  > > encoded (and indicating that with the encodingStyle attribute).
>  > >  We'd have no problem then with ordering, with using attributes
>  > > or any other funkiness, but we cannot do that in SOAP Data Model.
>  > > It was decided last fall that RPC would stay based on the Data
>  > > Model.
>  > >  Or we could create an extended data model allowing metadata on
>  > > edges and an extended encoding serializing the metadata as
>  > > attributes and make RPC result be such a metadata-enhanced
>  > > struct.
>  >
>  > We already allow metadata on edges. env:encodingStyle can appear on
every
>  > edge
>  >
>  > >  Anyway, I dislike the idea of writing a strict XML Schema schema
>  > > for SOAP Encoding data and then treating that as a SOAP Data
>  > > Model schema.
>  >
>  > I wasn't suggesting such an approach. I was merely observing that
defining a
>  > global attribute would allow people to define return values in any
encoding
>  > they liked, including an 'encoding' defined using XML Schema ( or any
other
>  > schema language for that matter )
>  >
>  > Gudge
>  >
>  >
>  >
>
>

Received on Wednesday, 24 April 2002 18:47:11 UTC