Nested Types

---

It is possible to nest other XSD sequence or choice content model groups within another sequence. For example, it is possible to nest a sequence definition within another sequence definition as follows:

	<xsd:complexType name="A">
 
	   <xsd:sequence>
 
	      <xsd:element name="x" type="xsd:string"/>
 
	      <xsd:sequence minOccurs="0">
 
	         <xsd:element name="y" type="xsd:integer"/>
 
               <xsd:element name="z" type="xsd:boolean"/>
 
	      </xsd:sequence>
 
	   </xsd:sequence>
 
	</xsd:complexType>
 

In this example, the type has three elements - x , y, and z. A nested SEQUENCE is used with the y and z elements to indicate the group is optional.

The XBinder compiler recursively pulls all of the nested content model groups (i.e. the embedded sequence and choice definitions) out of the sequence type to form a series of types that contain only a single level of elements. The names of the newly formed types are of the form BaseTypeName_LxS where BaseTypeName is the name of the main type, L is the nesting level, and S is the sequential position of the element within the construct. For example, in the definition above, the following two C types are generated to model the XSD type above:

typedef struct A_1x2 {

OSINT32 y;

OSBOOL z;

} A_1x2;

typedef struct A {

struct {

unsigned _seq2Present : 1;

} m;

const OSUTF8CHAR* x;

A_1x2 _seq2;

} A;

In this case, XBinder created the type A_1x2 to represent the inner sequence. It then added the _seq2 element to the main C type using this type. This allows all of the elements in the inner sequence to be managed as a group in the generated code. This is particularly useful if the element group is optional or repeating.

The C++ generated code is similar except that items are in the form of class definitions instead of structures.