Re: Issue 195: slightly updated simple proposal

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


> I have been trying to think of alternatives, myself.
>
> How about a new SOAP encoding type (like a struct or array) which is an
> extra child of the RPC call that identifies the return.

RPC is defined in terms of the data model, not the encoding so we'd have to
add this to the data model.

>
> Relying on schema types is no worse than the call itself, which must be
> identified as an array or a struct (or derived from those) before the
> call can be decoded.

I'm not sure what you mean by this. The SOAP encoding says very little about
type and certainly says nothing about 'array' or 'struct' types or
derivations thereof.

> Requiring it to have a specific QName would
> violate the rules of an array, I think, for which it is also useful.

Agreed, we say that for arrays the edges must be unlabelled.

>
> Languages which have no returns can ignore it and it has all the normal
> characteristics of an out parameter.
>
> Also, an array return can use this as a better way to positively
> identify the return, even in the presence of a void return, in which
> case it is ommitted.  In the array case, it would not use a QName, but
> some positional indication such as an index or immediately preceeding
> the actual return.

I think I'd need to see some example encodings to see what you are driving
at here.

Gudge

Received on Thursday, 25 April 2002 10:02:33 UTC