[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC