Re: Issue 231 options

Noah, as usual, you do have a point. 8-)

I think the goal you formulated is better than the one I wrote, and it's
what I would have written had I thought about those "self-describing is
unnecessary for me" cases.

But in the current SOAP Encoding, neither goal is met.

If we don't mandate arraySize (or any other indication that an array is
an array and not a generic or a struct), the receiver will not be able
to be certain that the sender would really have used arraySize if it was
an array.

If we do agree with your goal (as I do), we'll not only need to mark
arrays, but also generics (the two distinct kinds of them I have
described multiple times before) and structs, so that an empty compound
is distinguished from a simple type.

I don't think such a change would cause a second Last Call and it would
solve the issues with generics, too, at least for me.

Best regards

                   Jacek Kopecky

                   Senior Architect, Systinet Corporation
                   http://www.systinet.com/



On Mon, 2002-09-09 at 21:30, noah_mendelsohn@us.ibm.com wrote:
> 
> Jacek Kopecky writes:
> 
> >> Should SOAP Encoding serialization 
> >> produce self-describing XML? 
> >> (self-describing in terms of 
> >> the data structure)
> 
> I think there's a variation of this goal that you don't cover, but it's 
> the one I would like in principal if we could get there:
> 
> Should it be possible for an application to use SOAP Encoding 
> serialization to produce self-describing            XML? (self-describing 
> in terms of the data structure)
> 
> We got quite close in SOAP 1.1, and that was conscious.  So, and 
> application CAN use xsi:type on all elements that are of simple type, but 
> it need not if it prefers to rely on schemas or other external contracts 
> to establish the interpretation of the contents.  It may be too late, and 
> I've never pushed it, but I would like >>to be able to<< distinguish 
> structs from arrays in a self-describing message, but that's not at all 
> the same as saying that every serialization should be self-describing.
> 
> I'm not advocating any particular design decision at this point, just 
> suggesting that the goal as I've stated it seems like a quite appealing 
> middle ground between always self-desc. and "it's not always possible." 
> Obviously, it's a matter of degree in any case.  Thanks.
> 
> ------------------------------------------------------------------
> Noah Mendelsohn                              Voice: 1-617-693-4036
> IBM Corporation                                Fax: 1-617-693-8676
> One Rogers Street
> Cambridge, MA 02142
> ------------------------------------------------------------------
> 
>

Received on Monday, 9 September 2002 16:16:11 UTC