RE: [wsrp-wsia] WSRP proposed changes to better support JSR 168

Due to timezone differences, I did not get a chance to comment at all on the
contained SOAP array proposal. FYI Here is my reply to the JSR 168 group:

I'm sure this will get discussed next week and sort of already came up on
yesterday's wsia-wsrp call. The WSRP WSDL is currently document/literal.
While we may still debate this choice, the WS-I.org basic profile and newer
web tool chains encourages this style of WSDL Web Services:

http://www.ws-i.org/Profiles/Basic/2002-10/BasicProfile-1.0-WGD.htm

The WS-I.org profile also discourages the soapenc:arrayType attribute:

<quote>R2110 A DESCRIPTION MUST NOT use soapenc:arrayType attribute.</quote>

Practically, the extension mechanism used by the WSRP wsdl:

<sequence><any namespace="##other"/></sequence>

Means that one gets a:

org.apache.axis.message.MessageElement[] for Axis (use getAsDom() on this)
System.Xml.XmlElement[]for .NET
javax.xml.soap.SOAPElement[] for JAXRPC

This is then just normal XML (DOM like) processing. A string array (e.g. if
a string array is needed, as a common extension and I've heard arrays of
string property key/value as examples too) would be in one of the [] slots
and best encoded internally as a sequence of string items:

<complexType name="StringArray">
  <sequence>
    <element name="String" type="xsd:string" maxOccurs="unbounded"/>
  </sequence>
</complexType>

Which the WSRP wsdl already declares as a type. I suggest these can just be
placed in a properly namespaced vendor extension element (of type
StringArray). I do appreciate the problem and yours is a good clarification
of soap arrays, but why not side step the whole soap encoding issue with XML
schema?

regards,
Andre