"xsi:type" value for Complex Types in return value not rendered as per generated WSDL about wash_out HOT 2 CLOSED

It looks like Address (both work and home) are the same type tns:address in your wsdl. The attribute names are workAddress and homeAddress. The type, properly defined in the wsdl is Address. A consumer would properly map this to myUser1.homeAddress.street and myUser1.workAddress.street.

Is there a particular consumer giving you problems (Java introspection, .Net, SoapUI)? I have to get better at reading wsdls, but what you have looks as if it would work in Java and SoapUI.

tns:users is a variable name, not the type, in your case this is an array of UserInfo. The WSDL is responsible for telling your cliient this. Each work address, home address and user id is a type UserInfo as defined in the WSDL.

<part type="tns:userInfo" xsi:minOccurs="0" name="users" xsi:maxOccurs="unbounded"/>

Notice the TYPE definition there is userInfo. Your consumer will reference this to determine the proper consumption of the data you provided. The name matches the variable name in your provider. You can change this name, I believe it's entirely up to you.

If you introspect and consume your wsdl, there would be 2 types (UserInfo and Address). users is an array of UserInfo. In Java, if I were to dynamically introspect and consume this service, I could access everything programmatic like this.

--Pseudo
response = execute_service
for (user in response.users)
// user is of Type UserInfo
// user.workAddress is of type Address
// user.homeAddress is of type Address
user.workAddress.street; // would do something with the users work street
// user.userId is a string attribute on UserInfo type

This is just as you have defined it in your WashOut::Types.

-- If this is too winded or repetitive, I apologize. It does look like it is working as intended based on inspection of code, and wsdl. To me.

from wash_out.

@jancel is absolutely right. That's exactly how things work.

from wash_out.