RE: [wsdl] Re: [soapbuilders] Interop Issue - Good Example
- -----Original Message-----Regarding Matt's suggestion, I may be misunderstanding... butIf you use "tns:ArrayOfSOAPService" directly, wouldn't you need to usetype="tns:ArrayOfSOAPService"in the part definition rather than using the element attribute? Sincetns:ArrayOfSOAPServiceis a reference directly to a complexType definition?Perhaps one rule could be:If the message part is referencing an element, then you do your object constructionafter you've determined the type, either by looking at a <complexType> child of theelement or by following a "type" attribute on the element.Then, you end up at "ArrayOfSOAPService" and go from there, and Simon's rule #3kicks in.Or am I completely off base here?Thanks,Tony
From: Simon Fell [mailto:soap@...]
Sent: Monday, February 05, 2001 5:24 PM
Subject: [wsdl] Re: [soapbuilders] Interop Issue - Good Example
On Tue, 06 Feb 2001 00:15:41 -0000, in soap you wrote:
>I came across a good example of an interop issue. The WSDL at this
>has schema associated with its types element (this is included at the
>bottom). The schema is entirely correct, but does provide an
>interesting issue when returning or sending objects. This particular
>wsdl doc has an array of objects associated with it. Under
>a "normal" processor a part with type attribute = "xsd:ArrayOfFloat"
>can be easily resolved without the aid of schema.
Assuming xsd points to http://www.w3.org/1999/XMLSchema then
xsd:ArrayOfFloat doesn't exist. what i've seen everyone else do for
arrays, is to define their own type for arrays, following the
recommended naming convention from the WSDL spec. (there's still an
outstanding debate of how exactly the array should be defined)
This could be massively simplified by someone coming up with a schema
that defines all the common array types and importing it in. However
the current MS toolkit doesn't support import, and i'm not sure how
many others do.
>However, when the
>part has an element attribute the schema must be involved. In our
>implementation an element attribute is equivalent to passing an
>object, e.g., this is a critical issue (for us). In the example the
>response part's element attribute is "tns:ItemArray" . A processor
>could correctly determine that this object is an array of objects by
>retrieving the preappended the "Array" from the text and prefixing
>with non-"xsd". However, it would appear more gentle to
>use "tns:ArrayOfSOAPService" as this would be as easily resolvable
>a) element attribute confirms schema is involved (object in our case)
>b) "tns" confirms same as [a]
>c) "ArrayOf" signals and array is present (which is same when xsd
>type is present.
>d) "SOAPService" gives us the root of the schema tree to resolve
ok, try this.
1. complex types can be "linked" from the messages section to the
types section via a element name / element pair or a complex type /
2. the uri for tns needs to match the targetnamespace in the
3. the complex type definition is inheriting from soap:Array and this
should be used to indicate that its an array. the all/sequence/element
info within the complexType has the info to de-reference the array
(IMO) basing it on the text name is a mistake, you've got to pick your
way through all the schema references, I'm beginning to understand why
Jacek didn't like it !
To unsubscribe from this group, send an email to: