Return-Path: Delivered-To: apmail-xml-axis-dev-archive@xml.apache.org Received: (qmail 60235 invoked by uid 500); 6 Aug 2002 15:16:32 -0000 Mailing-List: contact axis-dev-help@xml.apache.org; run by ezmlm Precedence: bulk Reply-To: axis-dev@xml.apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list axis-dev@xml.apache.org Received: (qmail 60223 invoked from network); 6 Aug 2002 15:16:32 -0000 Importance: Normal Sensitivity: Subject: WSDL MIME is broken - need suggestions for arrays To: axis-dev@xml.apache.org X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: butek@us.ibm.com Date: Tue, 6 Aug 2002 10:09:44 -0500 X-MIMETrack: Serialize by Router on D04NM203/04/M/IBM(Build M13TT_07122002 Pre-release 2|July 12, 2002) at 08/06/2002 11:16:33 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=09BBE69EDFDC0E3B8f9e8a93df938690918c09BBE69EDFDC0E3B" Content-Disposition: inline X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N --0__=09BBE69EDFDC0E3B8f9e8a93df938690918c09BBE69EDFDC0E3B Content-type: text/plain; charset=US-ASCII Between WSDL 1.1 and JAX-RPC, for MIME we essentially ignore the type given in the message part and determine the type via the binding. For example: ... The binding says "image/jpeg". We know that means "java.awt.Image", so message m1's type could have been anything at all since it's ignored: "xsd:string", "xsd:anyURI". While quite odd, this works just dandy. We end up with the Java signature: public void setImage(java.awt.Image body); Now, how do we map THIS signature to WSDL? public void setImages(Image[] bodies); mime:content cannot contain anything but part and type. I've come up with 2 possible hacks, but they're both rather messy to deal with: 1. append "[]" to the end of the type string for each dimension. 2. add additional mime:content entries for each dimension: "" Another option: 3. completely ignore WSDL 1.1 and come up with our own xml for MIME types. This is completely non-interoperable, but WSDL MIME is so broken that I don't know how much interoperability we'd have, anyway. Any preferences? Any other suggestions? Russell Butek butek@us.ibm.com --0__=09BBE69EDFDC0E3B8f9e8a93df938690918c09BBE69EDFDC0E3B Content-type: text/html; charset=US-ASCII Content-Disposition: inline Between WSDL 1.1 and JAX-RPC, for MIME we essentially ignore the type given in the message part and determine the type via the binding. For example:

<complexType name="ArrayOfBinary"> ... </complexType>

<message name="empty"/>
<message name="m1">
<part name="body" type="tns:ArrayOfBinary"/>
</message>

<portType name="pt1">
<operation name="setImage">
<input message="m1"/>
<output message="empty"/>
</operation>
</portType>

<binding name="b1" type="tns:pt1">
<operation name="setImage">
<input>
<mime:multipartRelated>
<mime:part>
<mime:content part="body" type="image/jpeg"/>
</mime:part>
</mime:multipartRelated>
</input>
<output/>
</operation>
</binding>

The binding says "image/jpeg". We know that means "java.awt.Image", so message m1's type could have been anything at all since it's ignored: "xsd:string", "xsd:anyURI". While quite odd, this works just dandy. We end up with the Java signature:

public void setImage(java.awt.Image body);

Now, how do we map THIS signature to WSDL?

public void setImages(Image[] bodies);

mime:content cannot contain anything but part and type. I've come up with 2 possible hacks, but they're both rather messy to deal with:
1. append "[]" to the end of the type string for each dimension.
2. add additional mime:content entries for each dimension: "<mime:content part="body" type="array"/>"

Another option:
3. completely ignore WSDL 1.1 and come up with our own xml for MIME types. This is completely non-interoperable, but WSDL MIME is so broken that I don't know how much interoperability we'd have, anyway.

Any preferences? Any other suggestions?

Russell Butek
butek@us.ibm.com --0__=09BBE69EDFDC0E3B8f9e8a93df938690918c09BBE69EDFDC0E3B--