This is an artifact from SOAP 1.1 which has caused me a lot of trouble. Here's some information:
1. This type has two 'out-of-band' concepts outside of XML Schema. a. the wsdl:arrayType attribute (which does not appear in the PSVI of the schema) tells the WSDL processor that the type is an array type. The value of the attribute, like "Foo[,,]", tells the WSDL processor that the type is a 3-dimensional array with each item having type Foo. The WSDL processor must analyze the string for this info. b. owing to the definition of soapenc:Array, a pure schema processor cannot tell either the name of the element that will be used for each item in the array, nor the type of said items. (The soapenc:Array type is essentially (oversimplified) <any maxOccurs="unbounded" processContents="lax"> with the addition of the arrayType attribute.) 2. The SOAP data model says that an array type (signalled by the arrayType="Foo[3,6,7]" attribute found in a SOAP envelope somewhere) indicates that the element with the attribute is one whose content items have type Foo, the names of the elements don't matter because they're distinguished only by position in the list, that there should be 3*6*7 of them, and they should be treated as a 3-dimensional array with the appropriate dimensions. Any element name may be used for the items -- you can't find out from the wsdl or any schema what name will be used, you just have to get an instance document and see. But the information is sufficient for a SOAP processor to do something reasonable with the document. It's not sufficient for a pure Schema processor to know how to lay out a form displaying such an object -- the Schema processor must add SOAP or WSDL knowledge of how to interpret these magic attributes. 3. Axis arranges to deserialize one of these elements using its ArrayDeserializer, which, if it knows a deserializer for Foo elements into, e.g. FooClass java objects, will produce FooClass[3,6,7]. The registering of the deserializer is keyed not off the ArrayOfFoo type, but off the soapenc:Array type, which is necessary to know if you want to use your own deserializer instead of the built-in one. In Soap 1.2, things are somewhat less quirky, because the soapenc:Array type has been dropped. This means that somebody has to actually define the ArrayOfFoo type, naming the element used for each item, and stating its type as Foo. This makes things lots easier for the pure Schema processor. Soap 1.2 still has special attributes for the instance document: nodeType="array" tells the SOAP processor that the element is an array in the SOAP data model. itemType="Foo" gives the type of the item. There's also an attribute giving the dimensions. I haven't looked this up in the WSDL 1.2 spec, but presumably there is something equivalent to the wsdl:arrayType attribute that gives info to the WSDL processor in the absence of an instance document. I'm pretty sure Axis treats the deserialization of SOAP 1.2 arrays similarly to that for 1.1 arrays. Jeff ----- Original Message ----- From: "Cory Wilkerson" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, July 31, 2003 2:08 PM Subject: ArrayOf_xsd_string/float/whatever I realize this isn't the schema support group...but given the following definition...are we saying that ArrayOf_xsd_string is a subtype of soapenc:Array and we're restricting the value of arrayType to xsd:string? I had a look through the WSDL spec and saw that this is a way to provide the "default" type to the array -- but I'm missing something somewhere. I guess I've never seen a restriction applied at the attribute level and have taken Axis' wsdl generation for granted -- up until now. What exactly is going on here? <complexType name="ArrayOf_xsd_string"> <complexContent> <restriction base="soapenc:Array"> <attribute ref="soapenc:arrayType" wsdl:arrayType="xsd:string[]" /> </restriction> </complexContent> </complexType>
