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:16:05 UTC