RE: [soapbuilders] Re: Interop issues list
- Hi Simon,You are right. I will update that particular issue to reflect this correction. However, there is still an interop issue that I will have documented, specifically for this aspect of array item element naming. Here is what it is.I was testing the "echoStringArray" method using .NET server and SOAP::Lite client. For those folks not familiar with the "XMethods Interop Lab", this test simply takes a string array from soaplite client , sends it to the .net server, and has the .net server echo it back, thus testing all serialization and deserialation segments in that round trip.The .NET server produced an SDL contract that shows that it expected the array item element to be <string>, according to the XML schema.Now, soaplite sent by default an autogenerated symbol name - specifically, <c-gensym5>, as the array item element.But what I found is that it echoed back an empty array, telling me that the it failed to pick up the elements. Next, I tried forcing soaplite to use <string>, as the SDL schema specified, and presto, my array elements got thrown back to me properly, so I know that this one change caused .NET to suddenly see my elements, so clearly .NET was looking for a specific name in parsing the array elements; it's the same name that it published in the SDL file.The spec says:"Within an array value, element names are not significant for distinguishing accessors. Elements may have any name. In practice, elements will frequently be named so that their declaration in a schema suggests or determines their type. "So I think what this says is, go ahead in the WSDL file and declare an element like <string> as the name of the array element, but SOAP parsers MUST NOT validate that element name - any name must be accepted. .NET is doing specifically using that name to do the validation / parsing process.Cheers,
From: Simon Fell [mailto:soap@...]
Sent: Tuesday, March 20, 2001 8:50 PM
Subject: [soapbuilders] Re: Interop issues list
this is great, I think you've covered everything i've seen, I have an
issue with #4 though. The SOAP spec for arrays is quite clear that the
element name for the array items doesn't matter (and therefore the
thing serializing the array, can arbitrarily choose an element name),
section 5.4.2 para 3
" .... Within an array value, element names are not significant for
distinguishing accessors. Elements may have any name. ..."
On Tue, 20 Mar 2001 17:38:11 -0800, in soap you wrote:
>(I'm crossposting, my apologies for the duplicates you may receive)
>In my work on XMethods I've collected notes on a variety of issues that
>prevented interoperability. People often email me asking why they can't hit
>this dotnet service with that apache client, for example. I'd like to
>submit this list for review by the community. The focus in most of my work
>so far has been the most basic version of SOAP, which I would suggest, is a
>good starting point for getting all of the implementations to interop.
>1. Section 5 SOAP encoding
>I'd like to request that if you've run across an interop problem before that
>ISN'T on this list please email me and I'll put it in. The list lives (for
>I would also appreciate any corrections, etc.
>Please note that I am NOT proposing the interop solution here, just
>collecting data that I believe will help the community in ultimately solving
>I'll send out another notice when I've received some feedback , so that the
>implementors using the soapbuilders group can start to debate the issues.
>(Since I'm crossposting this, just so folks know, the soap builders group is
>a Yahoo group that provides the SOAP implementors a forum for debating
>XMethods Web Services Listings
>You can read messages from the SOAP archive, unsubscribe from SOAP, or subscribe to other
>DevelopMentor lists at http://discuss.develop.com.
To unsubscribe from this group, send an email to:
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.