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.

XML Schema Versions

4s4c now supports both the 1999 Schema namespace and the 2001 Schema namespace, by default the response from 4s4c will use the 2001 Schema namespace, unless the request uess the 1999 schema namespace, in which case it will build the response using the 1999 Schema.

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:decimal &nbps;
String (VT_BSTR) xsd:string  
Boolean (VT_BOOL) xsd:boolean  
Date (VT_DATE) xsd:timeInstant / xsd:dateTime  
Single Variant (VT_VARIANT) what ever the contained type is from above 
Array of Variants (VT_VARIANT) xsd:ur-type / xsd:anyType*2
*1 This works, but there is probably a better type for this, this may be revised in a future version.
*2 Each item in the array is has its own type definied on the item
All data is encoded as per the XML specification, therefore you can transport arbitrary XML fragments as strings. (see the tutorial for an example.)


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"></item>
		<item xsi:type="xsd:string"></item>
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 ;
} 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"></item>
		<item xsi:type="xsd:string"></item>
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)

Multi-ref Accessors

Release 1.3 contains support for decoding incoming multi-ref accessors, however it will not generate a response that has multi-ref accessors in it. See the \perl\ example that shows this in action.

<<< Installation      >>> WSDL Support