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: 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