W3C home > Mailing lists > Public > xml-dist-app@w3.org > May 2002

Re: Rewording of section 4.1.2 based upon resolution of issue 195

From: Ray Whitmer <rayw@netscape.com>
Date: Thu, 16 May 2002 16:31:54 -0700
Message-ID: <3CE4416A.70100@netscape.com>
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 

Ray Whitmer
Received on Thursday, 16 May 2002 19:30:46 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:20 UTC