The generated C/C++ include file contains a section for each XSD type defined in the XSD source file. In general, there is a one-to-one correspondence between types defined in the XSD file and generated C type or C++ class definitions. In some cases, however, extra types/classes are generated to support certain XSD types. This occurs on XSD complex type definitions when the element nesting level is greater than two (see the section on Complex Types for details).

In addition to XSD types, code is also generated for global element definitions. If no other type references a global element, it is considered to be a main message element (also known as a protocol data unitor PDU). These elements are encoded into the main XML documents or messages that make up the given specification. An entry point encode and decode function is generated for each of these elements. The header file contains the function prototypes for these functions.

Many XSD-based protocols specify multiple global element declarations that describe different XML document types that may be exchanged in a transaction. When a message type is not known in advanced, it is necessary to parse the outer level tag of a document in order to determine the correct decode and/or validation function to invoke. The -genFactoryoption can be used to generate a factory class to automate this process. When option -genFactoryis specified, additional code is generated for factory C type or C++ class definitions. A factory decode/validation/print fucntion is also generated. The header file contains the function prototypes for these functions.

With a WSDL file, if binding information is available (i.e. binding section is present in the WSDL definition file), C/C++ code is generated for WSDL Operation input/oputpt/fault types, and C++ control classes are generated for WSDL Operation input/output/fault. There is a one-to-one correspondence between operation input/output defined in the binding section and the generated C type or C++ class definitions. C type or C++ class definitions are also generated for operation fault to define the default fault information (for example, faultcode, faultstring and faultactor for SOAP 1.1) and fault detail information. If operation fault is defined in binding, extra types/classes are generated to support the fault detail.