xsi:type in doc literal format

Although in normal circumstances xsi:type does not appear in a literal WSDL's SOAP message, there are still cases when type information is necessary and it will appear -- in polymorphism, for instance. If the API expects a base type and an extension instance is sent, the type of that instance must be provided for proper deserialization of the object.

My question: How valid is to send xsi:type in doc/literal format? Is it possible to find an official answer (positive/negative)? What are your thoughts?

example:

<Device xsi:type="ns1:DeviceID">value</Device>

instead o开发者_Python百科f

<Device>value</Device>

The xsi:type attribute is normally not necessary since the XSD schema contained in the WSDL's types section is enough information for the client/server to figure out the type of all the elements.

But consider that there is sometimes the need to have a field or element as being of any type (xsd:anyType) so that you can use polymorphism (as you mentioned yourself).

For example, you might have a web service that runs some commands sent to it inside an XML field marked as xsd:anyType. Such a service specifies nothing about the type of the data at design time so instead type information must be provided at runtime.

Of course such a service does not accept absolutely any type but work with set of predefined types (i.e. so that you don't send it just any crap; just valid commands from a set of command types).

But the XML part is just communication. You eventually have to do something with that type programmaticaly, in client/server code. That means converting the xsd:anyType to an object in a programming language.

A WSDL-To-Code tool usually maps an xsd:anyType to the a top Object class which frankly isn't that useful. For that reason, an xsd:anyType is always serialized along with an xsi:type that specifies the actual type so that your code knows what the heck is in there.

As to how valid it is send xsi:type in doc/literal format my answer is: I'm thinking it is valid. WSDL and SOAP specifications mention nothing specific related to this (as to prohibit it), and the WS-Interoperability specification allows it.

So I think xsi:type it is not something positive or negative but just a tool for the job.

I think this use is discouraged. Generally in web services, the element name and position dictate it's type. It does make sense to leave room in a schema for expansion using "any".

<sequence>
<element name="a" type="AType"
<element name="b" type="BType"
<any minOccurs="0"

This allows for the possibility of sending additional information at a latter time without making the document invalid.

Let's consider a case where you are extending a class, AddressType, that is defined in schema

<address xs:type="USAddressType">
   <name
   <line1

Basically I (your partner) will have to write custom validation for this, so I would prefer to get an XSD that contains all known the extensions so I can use my standard validation libraries.