- From: Martin Gudgin <martin.gudgin@btconnect.com>
- Date: Wed, 24 Apr 2002 22:46:11 +0100
- To: "Jacek Kopecky" <jacek@systinet.com>
- Cc: "Ray Whitmer" <rayw@netscape.com>, <xml-dist-app@w3.org>
----- 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 17:46:49 UTC