- From: Ray Whitmer <rayw@netscape.com>
- Date: Thu, 16 May 2002 16:31:54 -0700
- To: Pete Hendry <peter.hendry@capeclear.com>
- CC: Marc Hadley <marc.hadley@sun.com>, xml-dist-app@w3.org
Pete Hendry wrote: > Perfect description of why allowing an array representation is a major > headache! > > How is it specified in WSDL (I know that is not the responsibility of > this group but it is the real world) that the return is an array? And, > in this how is it specified that the call has a return value and not > just out/inout arguments? Since the WSDL is the metadata, that is > where we find if there is a return value or not. How is this specified > for an array? This is why issue 195 was so important to me -- not losing the ability to describe the RPC and its arguments and returns using schema, which is what we have today that works (ignoring refs, which seem not often needed and even impossible for some). This was far more important than being able to pick out the exact return value, which is solved by a good description, and is only a small part of the unsolved puzzle delivered in an RPC element if there is no description. More than just the array caused headaches. Even if only struct were supported, that doesn't tell you how to bind the variables to a language that honors order, so what good was the return value? In a struct, the variables are likely to occur in any random order. We cannot even say they should occur in the natural order as SOAP 1.1 did, because that defies what a real struct is since we insist on it being a real struct which does not honor order. As big a headache as array may be, we may encourage its use over struct for that reason. The real answer would have been a generic compound type, that could have legitimately preserved and represented both. That is what we had (minus definition conflicts between RPC call and struct) and what we implemented for SOAP 1.1, and it worked much better, as it seems more difficult to automatically bind dynamic languages to SOAP 1.2. If it comes up during last call, we will still have a lot to talk about. Had we lost the encodingStyle attribute in issue 194, things might have become murkier still for those trying to dynamically bind without a description. Ray Whitmer rayw@netscape.com
Received on Thursday, 16 May 2002 19:30:46 UTC