Use of Mappings in Type Definitions

---

ASN.1 type definitions can be created that reference class fields and that are constrained by objects defined within an Information Object Set. The XSD mapping for these types contain normal element declarations for fixed type value fields and special "open type" elements for type fields.

The special open type elements will reference a generated complexType with a name in the following format:

<Parent Type Assignment Name>_<Open Type Element Name>_OpenType

The Information Object and Information Object Set definitions related to this type will be added as an annotation in the format described earlier. The generated type will be a choice between all of the different alternatives that make up the Information Object Set.

The basic mapping is as follows:

ASN.1 Definition:

TypeName ::= SEQUENCE {

element1-name FixedTypeFieldRef ({TableConstraint}),

element2-name FixedTypeFieldRef ({TableConstraint}{@key}),

element3-name TypeFieldRef ({TableConstraint}{@key}),

...

}

Any combination of fixed type and type fields can be contained within the type definition.

Generated XSD code:

<xsd:complexType name="TypeName">

<xsd:sequence>

<xsd:element name="elem1Name" type="Field1Type"/>

<xsd:element name="elem2Name" type="Field2Type"/>

<xsd:element name="elem3Name"

type="TypeName_elem3Name_OpenType"/>

...

</xsd:sequence>

</xsd:complexType>

<xsd:complexType name="TypeName_elem3Name_OpenType">

<xsd:choice>

<!-- this is the annotation for the info object set -->

<xsd:annotation>

<xsd:appinfo>

<ClassName>

<object attributes declarations/>

...

</ClassName>

</xsd:appinfo>

</xsd:annotation>

<!-- these are all of the various message alternatives

(name and type) defined within the info object set

<xsd:element name="TypeName" type="TypeName"/>

...

<!-- If info object set is extensible, message of unknown

type is possible -->

<xsd:any namespace="##other" processContents="lax"

minOccurs="0"/>

</xsd:choice>

</xsd:complexType>

In this case, the fixed type field types are obtained directly from the class definition. The type field is a reference to the generated open type field. The generated open type container type contains all of the information on the set of messages that is allowed to occupy the open type field.

An example showing all of this using the NBAP protocol is as follows:

The definition of an NBAP Protocol Information Element Field is as follows:

ProtocolIE-Field ::= SEQUENCE {

id

NBAP-PROTOCOL-IES.&id({CommonSetupRequests}),

criticality

NBAP-PROTOCOL-IES.&criticality({CommonSetupRequests}{@id}),

value

NBAP-PROTOCOL-IES.&Value({CommonSetupRequests }{@id})

}

This type allows any of the messages defined in the CommonSetupRequests information object set to be populated in the Value field. The id and criticality must match that of the defined message. The XSD definitions that are generated from this are as follows:

<xsd:complexType name="ProtocolIE_Field">

<xsd:sequence>

<xsd:element name="id" type=" ProtocolIE_ID"/>

<xsd:element name="criticality" type="Criticality"/>

<xsd:element name="value" type="ProtocolIE_Field_OpenType"/>

</xsd:sequence>

</xsd:complexType>

<xsd:complexType name="ProtocolIE_Field_value_OpenType">

<xsd:choice>

<xsd:annotation>

<xsd:appinfo>

<NBAP_PROTOCOL_IES>

<object id="id_C_ID" type="C_ID"

criticality="reject" presence="mandatory"/>

<object id="43" type="ConfigurationGenID"

criticality="reject" presence="mandatory"/>

<object id="36" type="SetupRqstFDD"

criticality="ignore" presence="mandatory"/>

</NBAP_PROTOCOL_IES>

</xsd:appinfo>

</xsd:annotation>

<xsd:element name="C_ID" type="C_ID"/>

<xsd:element name="ConfigurationGenID"

type="ConfigurationGenID"/>

<xsd:element name="SetupRqstFDD" type="SetupRqstFDD"/>

<xsd:any namespace="##other" processContents="lax"

minOccurs="0"/>

</xsd:choice>

</xsd:complexType>