The ITU-T ASN.1 X.681 and X.682 standards specify a table-driven approach for the assignment of constrained values to open types within a specification. These constraints are known as "table constraints" and utilize Open Type, Class, Information Object and ObjectSet definitions. Elements within types that are constrained in this way result in a special mapping to be done. This is only done when the -tables option is specified.

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 an anonymous <choice> complexType that will contain an alternative for each of the type fields listed in the referenced information object set that are allowed for the type.

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">
            <xsd:complexType>
               <xsd:choice>
                  <xsd:element name="infoObjectName" type="InfoObjectType">
                  ...
               </xsd:choice>
            </xsd:complexType>
         </xsd:element>
      </xsd:sequence>
   </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 <choice> container type contains all of the possible elements allowed by the table constraint for the open type field.

Example

This example is from a modified version of the 3GPP NBAP ASN.1 specification. Thsi protocol makes heavy use of classes, information objects, and information object sets.

One example of this is the NBAP InitiatingMessage type which is defined is as follows:

   InitiatingMessage ::= SEQUENCE {
      procedureID NBAP-ELEMENTARY-PROCEDURE.
         &procedureID ({NBAP-ELEMENTARY-PROCEDURES}),
         
      criticality NBAP-ELEMENTARY-PROCEDURE.
         &criticality ({NBAP-ELEMENTARY-PROCEDURES}{@procedureID}),
         
      messageDiscriminator NBAP-ELEMENTARY-PROCEDURE.
         &messageDiscriminator ({NBAP-ELEMENTARY-PROCEDURES}{@procedureID}),
         
      transactionID TransactionID,
      
      value NBAP-ELEMENTARY-PROCEDURE.
         &InitiatingMessage ({NBAP-ELEMENTARY-PROCEDURES}{@procedureID})
   } 

A simplified version of the NBAP-ELEMENTARY-PROCEDURES information object set that defines the contents of some of the element fields is as follows:

   NBAP-ELEMENTARY-PROCEDURES NBAP-ELEMENTARY-PROCEDURE ::= {
      radioLinkSetupFDD |
      radioLinkSetupTDD,
      ...
   }

The NBAP-ELEMENTARY-PROCEDURE class is defined as follows:

   NBAP-ELEMENTARY-PROCEDURE ::= CLASS {
      &InitiatingMessage,
      &SuccessfulOutcome        OPTIONAL,
      &UnsuccessfulOutcome      OPTIONAL,
      &Outcome                  OPTIONAL,
      &messageDiscriminator MessageDiscriminator,
      &procedureID ProcedureID  UNIQUE,
      &criticality Criticality  DEFAULT ignore
   }
   WITH SYNTAX {
      INITIATING MESSAGE        &InitiatingMessage
      [SUCCESSFUL OUTCOME       &SuccessfulOutcome]
      [UNSUCCESSFUL OUTCOME     &UnsuccessfulOutcome]
      [OUTCOME                  &Outcome]
      MESSAGE DISCRIMINATOR     &messageDiscriminator
      PROCEDURE ID              &procedureID
      [CRITICALITY              &criticality]
   } 

Finally, the information objects that are referenced in the information object set are as follows:

   -- *** RadioLinkSetup (FDD) ***
   radioLinkSetupFDD NBAP-ELEMENTARY-PROCEDURE ::= {
      INITIATING MESSAGE    RadioLinkSetupRequestFDD
      SUCCESSFUL OUTCOME    RadioLinkSetupResponseFDD
      UNSUCCESSFUL OUTCOME  RadioLinkSetupFailureFDD
      MESSAGE DISCRIMINATOR common
      PROCEDURE ID { procedureCode id-radioLinkSetup, ddMode fdd }
      CRITICALITY  reject
   }
               
   -- *** RadioLinkSetup (TDD) ***
   radioLinkSetupTDD NBAP-ELEMENTARY-PROCEDURE ::= {
      INITIATING MESSAGE     RadioLinkSetupRequestTDD
      SUCCESSFUL OUTCOME     RadioLinkSetupResponseTDD
      UNSUCCESSFUL OUTCOME   RadioLinkSetupFailureTDD
      MESSAGE DISCRIMINATOR  common
      PROCEDURE ID  { procedureCode id-radioLinkSetup, ddMode tdd }
      CRITICALITY   reject
   }

After working through the various layers, ASN2XSD is able to produce an XSD definition that provides fixed type references for the procedureID, criticality, and messageDiscriminator elements. An anonymous choice is produced under the value element that defines all of the types that may be used in the open type eleemnt. This is the resulting XSD definition:

   <xsd:complexType name="InitiatingMessage">
      <xsd:sequence>
         <xsd:element name="procedureID" type="NBAP-CommonDataTypes:ProcedureID"/>
         <xsd:element name="criticality" type="NBAP-CommonDataTypes:Criticality"/>
         <xsd:element name="messageDiscriminator" type="NBAP-CommonDataTypes:MessageDiscriminator"/>
         <xsd:element name="transactionID" type="NBAP-CommonDataTypes:TransactionID"/>
         <xsd:element name="value">
            <xsd:complexType>
               <xsd:choice>
                  <xsd:element name="radioLinkSetupFDD" type="NBAP-PDU-Contents:RadioLinkSetupRequestFDD"/>
                  <xsd:element name="radioLinkSetupTDD" type="NBAP-PDU-Contents:RadioLinkSetupRequestTDD"/>
               </xsd:choice>
            </xsd:complexType>
         </xsd:element>
      </xsd:sequence>
   </xsd:complexType>