WebReference.com - Part 2 of Chapter 3: Professional XML Web Services, from Wrox Press Ltd (2/5)
Professional XML Web Services
Simple Data Types
In SOAP encoding, simple types are always represented as single elements in the body.
SOAP encoding exposes all the simple types that are built into the XML Schemas Specification. If we are
using a simple type with SOAP encoding, then it must come from XML Schemas, or be derived from a type
that does. The namespace associated with the XML Schemas data types is
This provides the common types that many programmers will expect, like:
date, and so on. If we assume the
prefix is associated with the XML Schemas URI, and the
soapENC prefix is associated with
the SOAP encoding URI, then both of these payload values work with strings. This refers to XML Schemas:
while this refers to SOAP encoding:
For a XML Schemas tutorial, including a list of the types available in XML Schemas (and therefore, SOAP encoding), go to http://www.w3.org/TR/xmlschema-0/.
SOAP tries to make it possible for a wide variety of languages to communicate, and not all
languages are created equal. In many scripting languages, type is a loose concept. To help level the
playing field, SOAP borrows from XML Schemas once again and uses the
xsi:type attribute is a way for elements in the payload to indicate their
type. It is associated with XML Schemas, and the
xsi prefix in this case is associated with
http://www.w3.org/1999/XMLSchema-instance. It can appear on any payload element.
Developers not familiar with namespaces and schemas in XML need to be aware that the
xsiprefix of the
xsi:typeis insignificant. The attribute could easily appear in the message as
foo:type, provided that the
fooprefix is associated with the namespace URI
http://www.w3.org/1999/XMLSchema-instance. Likewise, the
xsdprefix commonly used on the values of the
typeattribute is assumed here to be associated with
http://www.w3.org/1999/XMLSchema. Be aware of this and other namespace issues as you work with SOAP messages.
If the application knows what type is being sent and retrieved from some outside source
(for example, a schema, a WSDL document, or other metadata), then the
is not required. The fact remains that not all languages will be supporting WSDL in the near future,
if ever, and so the good neighbor approach suggests that including
xsi:type will help make
our SOAP messages more interoperable with "type-challenged" languages like XSLT.
So what does this mean for the SOAP message as a whole? In order to use the
xsi:type attribute and the
xsd prefix for data types, we must define what
these prefixes mean inside the message. Let's consider another example message with encoding in mind.
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" soap:encodingStyle="http://schemas.xmlsoap.org/soap /encoding/"> <soap:Body> <m:MixedMessage xmlns:m="http://www.wrox.com/mix/"> <param1>OU812</param1> <param2>2001</param2> <param3>3.14159</param3> </m:MixedMessage> </soap:Body> </soap:Envelope>
That message meets all the requirements of SOAP, but many implementations would not be able to process it because they would not be able to map the values in the payload to types in the target language. We don't want to require a language to use a union type like the variant in COM, or to try to map the type by trial and error. Therefore, we add a little information to our message to make it more readable:
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" soap:encodingStyle="http://schemas.xmlsoap.org/soap /encoding/" xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance" xmlns:xsd="http://www.w3.org/1999/XMLSchema"> <soap:Body> <m:MixedMessage xmlns:m="http://www.wrox.com/mix/"> <param1 xsi:type="xsd:string">OU812</param1> <param2 xsi:type="xsd:integer">2001</param2> <param3 xsi:type="xsd:double">3.14159</param3> </m:MixedMessage> </soap:Body> </soap:Envelope>
Now all the data in the payload is identified by type, and it becomes much easier for a SOAP implementation to process.
Created: November 19, 2001
Revised: November 19, 2001