Supported Data Types
Encoding Styles
The only supported encoding type is the standard SOAP encoding style as defined in Section 5 of the SOAP 1.1 specification.
Data Types & Mappings
The following data types are supported, and their mappings to and from XML Schema types is shown. These types are also
supported in 1 dimensional safe arrays, and in User Defined Types (UDT's) as long as the UDT is defined
in a typelibrary. UDT's are mapped to the SOAP ComplexType.
Basic Types
| Com Type |
XML Schema Type |
Notes |
| signed byte (VT_I1) | xsd:int | |
| signed short (VT_I2) | xsd:int | |
| signed long (VT_I4) | xsd:int | |
| signed int64 (VT_I8) | xsd:int | |
| unsigned byte (VT_UI1) | xsd:int | |
| unsigned short (VT_UI2) | xsd:int | |
| unsigned long (VT_UI4) | xsd:int | |
| unsigned int64 (VT_UI8) | xsd:int | |
| float (VT_R4) | xsd:float | |
| double (VT_R8) | xsd:double | |
| currency (VT_CY) | xsd:string | *1 |
| String (VT_BSTR) | xsd:string | |
| Boolean (VT_BOOL) | xsd:boolean | |
| Date (VT_DATE) | xsd:timeInstant | |
*1 This works, but there is probably a better type for this, this may be revised in a future version.
All data is encoded as per the XML specification, therefore you can transport arbitrary XML fragments as strings.
(see the tutorial for an example.)
Arrays
One dimensional SAFEARRAY's of all the supported basic types listed above are supported,
and are mapped to type SOAP-ENC:Array with the relevant SOAP-ENC:arrayType set.
The exception are arrays of bytes (VT_I1 or VT_UI1) which are mapped to SOAP-ENC:base64 and are base64 encoded or decoded.
Partial, Sparse & multi-dimension arrays are not yet supported (they may be supported in a future version)
User Defined Types (UDT's) aka ComplexTypes
UDT's which are defined in typelibraries, can be used, and can contain any supported data type (including other UDT's). All the obvious
nesting combinations are supported (UDTs with Arrays of UDT as a member), however multi-ref accessors are not supported, so you could
probably blow it up trying to return a doubly linked list.
By default the SOAP version of the UDT is qualified with a namespace URI of "uuid:{guid of udt here}", e.g.
<Person xsi:type="ns1:Person" xmlns:ns1="uuid:6B9EC0AC-C0C2-4ff9-894A-24CB77CDDAAD">
<fName xsi:type="xsd:string">Simon</fName>
<lName xsi:type="xsd:string">Fell</lName>
<EmailAddrs xsi:type="SOAP-ENC:Array" SOAP-ENC:arrayType="xsd:string[2]">
<item xsi:type="xsd:string">simon@fell.com</item>
<item xsi:type="xsd:string">sfell@streetfusion.com</item>
</EmailAddrs>
</Person>
Whilst perfectly valid, its a little unfriendly, however you can specify a custom attribute in the UDT definition to override the URI.
e.g. defining the UDT like this,
typedef [uuid(6B9EC0AC-C0C2-4ff9-894A-24CB77CDDAAD), public, SOAP_URI("urn:com-fell-simon-demos-Person")] struct Person
{
BSTR fName ;
BSTR lName ;
SAFEARRAY(BSTR) EmailAddrs ;
} Person ;
would result in the following serialized version.
<Person xsi:type="ns1:Person" xmlns:ns1="urn:com-fell-simon-demos-Person">
<fName xsi:type="xsd:string">Simon</fName>
<lName xsi:type="xsd:string">Fell</lName>
<EmailAddrs xsi:type="SOAP-ENC:Array" SOAP-ENC:arrayType="xsd:string[2]">
<item xsi:type="xsd:string">simon@fell.com</item>
<item xsi:type="xsd:string">sfell@streetfusion.com</item>
</EmailAddrs>
</Person>
This can be useful when dealing with clients that use the namespace URI as a key to which de-serializer to use (such as Apache SOAP)
<<< Installation
>>> Interoperability with other SOAP toolkits