Glossary Item Box

MEdit Send comments on this topic.

ASN Keyword List

ASN Keyword List

 

ASN Keyword List

A variety of keywords are used in the comment section of the ASN found in each record to control the formatting of the XML translation process. This section documents the existing keywords and their proper use.  It should be noted that these keywords are somewhat unique to the ITS industry, and are not widely support by others.


General remarks:
All keywords are made up of the following simple pattern:

      [white space] -- [keyword] [white space] [end of line]

The double dash of ASN starts the comment area, and it ends with a CR-LF. Note that all keywords fit inside the standard comment areas of an ASN production. They do not share that comment line with any other comments. All keywords are a single token (no white space) and compound thoughts are denoted by complex keywords run together to form a single word.

The keyword applies to the ASN statement or production which immediately precedes it in most cases.

ASN.1 Keywords List

Additional control over the ASM to XML translation is provided by placing keywords in the comment areas of the ASN. The presence of these words controls the XML pattern that is selected in the translation and thereby allows a greater control on how the resulting XML looks. Most of these controls deal with dropping extra tags from the XML that are perceived as unneeded. The resulting template pattern can be found in the table XML_Templates in the MEdit_Settings.mdb file or in the help files here.

Contents

The LOCAL_CONTENT keyword     1
The UNTAGGED keyword     2
The CHOICE_SET keyword     3
The ATTRIB keyword     4


The LOCAL_CONTENT keyword

This term is used whenever an extension in the local schema for that FADD is needed. It is analogous to the ... found in ASN and often appears near it at the end of the ASN production. It can be used both in complex sets such as sequences, and in simple sets such as enumerations or bit-strings. Note the line <xs:restriction base="local:ExamplEnum" /> in the below.
 
Typical use 

ExamplEnum ::= ENUMERATED {

     itemOne       (0),

     itemTwo       (1),

     ... -- # LOCAL_CONTENT

     }

     -- values to 127 reserved for std use

     -- values 128 to 255 reserved for local use

 

Resulting XML:

<xs:simpleType name="ExamplEnum" >

      <xs:annotation>

         <xs:appinfo>

            itemOne (0)

            itemTwo (1)

         </xs:appinfo>

         <xs:documentation>      

            values to 127 reserved for std use

            values 128 to 255 reserved for local use

         </xs:documentation>

      </xs:annotation>

      <xs:union>

         <xs:simpleType>

            <xs:restriction base="xs:unsignedInt">

               <xs:minInclusive value="0"/>

               <xs:maxInclusive value="1"/>

            </xs:restriction>

         </xs:simpleType>

         <xs:simpleType>

            <xs:restriction base="xs:string">

               <xs:enumeration value="itemOne"/>

               <xs:enumeration value="itemTwo"/>

            </xs:restriction>

         </xs:simpleType >

         <xs:simpleType>

            <xs:restriction base="local:ExamplEnum" />

         </xs:simpleType>

      </xs:union>

</xs:simpleType>

 
The local keyword does not always result in a different template pattern, sometimes it simply inserts the local stub as an element in a sequence. In the primitive types, such as enumerated or bit string, it results in a pattern with the name _LOCAL.

The UNTAGGED keyword

This term is used whenever the outer structures of an ASN production should be suppressed in the resulting XML structures. This occurs with multi-deep nested productions and this keyword can apply to SEQUENCE statements in the middle of the production. It can not apply to the outmost or inner most structure.

Note the lines

<xs:element name="myInnerSruct" >
        <xs:complexType>


are not found in the XML below, the keyword has suppressed them and flattened the XML production. This can be useful when you are import a data frame from another place and wish to use it without tags.

Typical use 

MyStruc ::=  SEQUENCE {

   itemOne       Cat,

   itemTwo       Dog,

   myInnerSruct  SEQUENCE {

      item1      Frog,

      item2      Pig

      } -- # UNTAGGED

   }

 

Resulting XML:

<xs:complexType name="MyStruc" >

      <xs:sequence>

         <xs:element name="itemOne" type="Cat" />

         <xs:element name="itemTwo" type="Dog" />

         <xs:sequence>

            <xs:element name="item1" type="Frog" />

            <xs:element name="item2" type="Pig" />

         </xs:sequence>

      </xs:sequence>

</xs:complexType>
 
Keywords which have untagged in their name typically result in a pattern with NOTAG in the template name. Note that patterns with range restrictions (i.e. Size(1..10)) typically have two such patterns, one with the range restriction and one without, as well as the variants without the UNTAGGED use.

The CHOICE_SET keyword

This term can also be used with the SEQUENCE statement in a slightly different form. The normal interpretation of CHOICE in ASN is to select only one item, while XML allows more then one item (a set of choices). Hence the semantic meaning between sequence and choice becomes a bit blurred under these conditions. Use of this keyword causes the sequence statement to be rendered as a multi element choice.

The format of the keyword is slightly different from the others, because the very last item represents the numerical value for the choice, as in:

-- # CHOICE _SET=1               or   UNTAGGED_CHOICE_SET=1
-- # CHOICE_SET=2                or   UNTAGGED_CHOICE_SET=2
-- # CHOICE_SET=3                or   UNTAGGED_CHOICE_SET=3 etc...


Here is an example showing its use both with and without the UNTAGGED keyword as well.
 
Typical use 

TCIP-TestD ::=  SEQUENCE{

   which       SEQUENCE {

      locationsA   LRMS.PointLocation   OPTIONAL,

      featuresA    CPTGenericIden       OPTIONAL

      } -- # UNTAGGED_CHOICE_SET=1 

   which2       SEQUENCE {

      locationsB   LRMS.PointLocation   OPTIONAL,

      featuresB    CPTGenericIden       OPTIONAL

      } -- # CHOICE_SET=1 

   }

   (WITH COMPONENTS {...locationsA PRESENT}|

    WITH COMPONENTS {...featuresA PRESENT})

 

Resulting XML:

<xs:complexType name="TCIP-TestD" >

      <xs:sequence>

         <xs:complexType>

            <xs:choice minOccurs="1">

               <xs:element name="locationsA" type="lrms:PointLocation"  minOccurs="0"/>

               <xs:element name="featuresA" type="CPTGenericIden"  minOccurs="0"/>

            </xs:choice>

         </xs:complexType>

         <xs:element name="which2" >

            <xs:complexType>

               <xs:choice minOccurs="1">

                 <xs:element name="locationsB" type="lrms:PointLocation"  minOccurs="0"/>

                 <xs:element name="featuresB" type="CPTGenericIden"  minOccurs="0"/>

               </xs:choice>

            </xs:complexType>

         </xs:element>

      </xs:sequence>

</xs:complexType>

 

 

The ATTRIB keyword

This term is used whenever a simple element in the ASN is to be rendered as an attribute in the resulting XML. Keep in mind that attributes are generally not used in ITS and that the order in which they appear in usage is non-deterministic. The element chosen must meet all the rules for XML attribute use (i.e. of simple type, etc.). Typically these elements are listed at the end of the ASN production.
Typical use 

MyStruc ::=  SEQUENCE {

   itemOne       Cat,

   itemTwo       Dog,

   itemThree     Frog,          -- # ATTRIB

   itemFour      Pig OPTIONAL,  -- # ATTRIB

   }

 

Resulting XML:

<xs:complexType name="MyStruc" >

      <xs:sequence>

         <xs:element name="itemOne" type="Cat" />

         <xs:element name="itemTwo" type="Dog" />

         <xs:attribute name="itemThree" type="Frog"  use="required"/>

         <xs:attribute name="itemFour" type="Pig" />

      </xs:sequence>

</xs:complexType>
 

 

11424034

   <-LAST     TOP      NEXT->  

 

 

© SubCarrier Systems Corp. All Rights Reserved.