Return-Path: 
 <axis-dev-return-4696-apmail-xml-axis-dev-archive=xml.apache.org@xml.apache.org>
Delivered-To: apmail-xml-axis-dev-archive@xml.apache.org
Received: (qmail 39460 invoked by uid 500); 4 Dec 2001 14:22:02 -0000
Mailing-List: contact axis-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: axis-dev@xml.apache.org
list-help: <mailto:axis-dev-help@xml.apache.org>
list-unsubscribe: <mailto:axis-dev-unsubscribe@xml.apache.org>
list-post: <mailto:axis-dev@xml.apache.org>
Delivered-To: mailing list axis-dev@xml.apache.org
Received: (qmail 39451 invoked from network); 4 Dec 2001 14:22:02 -0000
Message-ID: <013e01c17cce$d8bda920$6e00a8c0@ne.mediaone.net>
From: "Glen Daniels" <gdaniels@macromedia.com>
To: <axis-dev@xml.apache.org>
References: <OFB5523BFD.5333E6C0-ON85256B18.004D5C03@raleigh.ibm.com>
Subject: Re: array test
Date: Tue, 4 Dec 2001 09:20:37 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

Inline:

> What "real" problem?  As I posted previously, the following works just
> fine:
>
>    <doitResponse>
>      <doitResult href="#id0"/>
>    </doitResponse>
>    <multiRef id="id0" SOAP-ENC:root="0" xsi:type="SOAP-ENC:Array"
>        SOAP-ENC:arrayType="ns1:foo[3]"
>        xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
>        xmlns:ns1="http://test.com">
>
> On the argument, is there an xsi:type?  Nope.  If you follow the href, is
> there an xsi:type of "SOAP:Array"?  Yep.  Does this require a change to the
> current logic to work?  Doesn't appear to.
>
> Now lets take a look at something that does NOT work currently, involving
> myNS:ArrayOfInt types of things.  This is from the Phalanx "typed"
> endpoint.
>
>    <return xsi:type="s1:ArrayOfstring" SOAP-ENC:arrayType="xsd:string[2]">
>
> Note: no hrefs are required to confuse us.  Just a xsi:type that we don't
> recognize.  In this case, we don't recognize "ArrayOfstring".  If we were
> to have ArrayOfstring defined as a "known" type, or were to treat it as a
> synonym for SOAP-ENC:Array, or simply see the SOAP-ENC:arrayType and
> proceed merrily along our way, all would be well.
>
> What am I missing here?

You're missing the fact that you can imagine a situation where the working
message above doesn't work because the type info for "doItResult" in the Call
object is something like "s1:ArrayOfString".  In that case we won't even get to
the point where we process the xsi:type on the actual multiRef element.

Doug's example didn't illustrate this particular case, but it would happen if
we had a WSDL that specified a "myNS:ArrayOfFoo" type and we got the first of
your two messages above.

There are definitely two issues, and we should deal with both of them, IMO.

--Glen