Network Working Group S. Legg Request for Comments: 4912 eB2Bcom Category: Experimental July 2007 Abstract Syntax Notation X (ASN.X) Status of This Memo This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The IETF Trust (2007).Abstract
Abstract Syntax Notation X (ASN.X) is a semantically equivalent Extensible Markup Language (XML) representation for Abstract Syntax Notation One (ASN.1) specifications. ASN.X completely avoids the numerous ambiguities inherent in the ASN.1 language; therefore, specifications written in ASN.X are much easier to parse and manage than original ASN.1 specifications. ASN.X, together with the Robust XML Encoding Rules (RXER), constitutes a schema language for XML documents that offers, through other ASN.1 encoding rules, alternative compact binary encodings for XML instance documents.
Table of Contents
1. Introduction ....................................................4 2. Conventions .....................................................5 3. General Considerations ..........................................6 3.1. Annotations ................................................7 4. ModuleDefinition Translation ....................................8 5. Translation of Assignments .....................................11 5.1. Referencing Named Constructs ..............................11 5.2. Importing Namespaces ......................................12 5.3. TypeAssignment Translation ................................14 5.4. ValueAssignment and XMLValueAssignment Translation ........14 5.5. ValueSetTypeAssignment Translation ........................15 5.6. ObjectClassAssignment Translation .........................15 5.7. ObjectAssignment Translation ..............................16 5.8. ObjectSetAssignment Translation ...........................16 5.9. ParameterizedAssignment Translation .......................17 6. Translation of Types ...........................................17 6.1. Identifier Replacement ....................................17 6.2. DefinedType Translation ...................................18 6.3. Translation of Built-in Types .............................20 6.4. BitStringType Translation .................................21 6.5. IntegerType Translation ...................................22 6.6. EnumeratedType Translation ................................24 6.7. PrefixedType Translation ..................................25 6.7.1. Short Form TaggedType Translation ..................28 6.7.2. Long Form TaggedType Translation ...................29 6.8. SelectionType Translation .................................30 6.9. InstanceOfType Translation ................................31 6.10. ObjectClassFieldType Translation .........................31 6.11. TypeFromObject and ValueSetFromObjects Translation .......32 6.12. Translation of Combining Types ...........................32 6.12.1. NamedType Translation .............................32 6.12.2. SequenceType Translation ..........................36 6.12.3. SetType Translation ...............................38 6.12.4. ChoiceType Translation ............................39 6.12.5. Translation of UNION Types ........................40 6.12.6. SequenceOfType Translation ........................41 6.12.7. Translation of LIST Types .........................42 6.12.8. SetOfType Translation .............................42 6.12.9. Effect of Insertion Encoding Instructions .........43 6.13. Translation of Constrained Types .........................43 6.13.1. Constraint Translation ............................46 6.13.2. UserDefinedConstraint Translation .................46 6.13.3. TableConstraint Translation .......................47 6.13.4. ContentsConstraint Translation ....................49 6.13.5. ExceptionSpec Translation .........................50
7. Translation of Values ..........................................51 7.1. Translation of Literal Values .............................53 7.2. Translation of Notational Values ..........................54 7.2.1. DefinedValue Translation ...........................56 7.2.2. BuiltinValue Translation ...........................57 7.2.3. ValueFromObject Translation ........................60 7.2.4. ObjectClassFieldValue Translation ..................60 8. Translation of Value Sets ......................................61 8.1. ElementSetSpecs Translation ...............................62 8.2. ElementSetSpec Translation ................................62 8.3. SubtypeElements Translation ...............................63 8.3.1. ValueRange Translation .............................64 8.3.2. InnerTypeConstraints Translation ...................65 9. Translation of Object Classes ..................................66 9.1. DefinedObjectClass Translation ............................66 9.2. ObjectClassDefn Translation ...............................68 9.2.1. TypeFieldSpec Translation ..........................68 9.2.2. FixedTypeValueFieldSpec Translation ................69 9.2.3. FixedTypeValueSetFieldSpec Translation .............70 9.2.4. VariableTypeValueFieldSpec Translation .............71 9.2.5. VariableTypeValueSetFieldSpec Translation ..........73 9.2.6. FieldName Translation ..............................74 9.2.7. ObjectFieldSpec Translation ........................75 9.2.8. ObjectSetFieldSpec Translation .....................76 10. Translation of Objects ........................................77 10.1. DefinedObject Translation ................................77 10.2. ObjectDefn Translation ...................................78 10.3. ObjectFromObject Translation .............................80 11. Translation of Object Sets ....................................80 11.1. DefinedObjectSet Translation .............................81 11.2. ObjectSetElements Translation ............................82 11.2.1. ObjectSetFromObjects Translation ..................83 12. Translation of Information From Objects .......................83 13. Translation of Parameterized Definitions ......................83 14. EncodingControlSections Translation ...........................93 15. Security Considerations .......................................94 16. Acknowledgements ..............................................94 17. References ....................................................95 17.1. Normative References .....................................95 17.2. Informative References ...................................97 Appendix A. ASN.1 for ASN.X .......................................95 Appendix B. ASN.X for ASN.X ......................................115
1. Introduction
A full parser for the Abstract Syntax Notation One (ASN.1) language [X.680][X.680-1][X.681][X.682][X.683] is difficult to implement due to numerous ambiguities in the notation. For example, certain notations for a Value are syntactically indistinguishable from notation for a ValueSet, Object, ObjectSet, DummyReference, or SimpleTableConstraint. An ObjectClassAssignment, ObjectAssignment, or ObjectSetAssignment resembles respectively a TypeAssignment, ValueAssignment, or ValueSetTypeAssignment. A FixedTypeValueFieldSpec or FixedTypeValueSetFieldSpec resembles respectively an ObjectFieldSpec or ObjectSetFieldSpec, and an ObjectClassFieldType resembles InformationFromObjects notation. In general, such ambiguities can only be resolved once the entire specification has been parsed. There are other notations that are not mutually ambiguous but still require several lexical tokens to be scanned before they can be distinguished from each other. The difficulty of parsing ASN.1 is an impediment to its wider adoption. This document defines a semantically equivalent Extensible Markup Language (XML) [XML10][XML11] representation for ASN.1 specifications called Abstract Syntax Notation X (ASN.X). An ASN.X module is a well-formed and valid XML document conforming to XML namespaces [XMLNS10][XMLNS11]. ASN.X completely avoids the inherent ambiguities of the ASN.1 language; therefore, specifications written in ASN.X are much easier to parse and manage than original ASN.1 specifications. For example, any conformant XML processor forms the basis of an ASN.1 toolkit. ASN.X, together with the Robust XML Encoding Rules (RXER) [RXER], constitutes a schema language for XML documents that offers, through other ASN.1 encoding rules, alternative compact binary encodings for XML instance documents conforming to an ASN.X specification. ASN.X definitions can also incorporate type, element, and attribute definitions from XML Schema [XSD1] documents, RELAX NG [RNG] documents, or Document Type Definitions (DTDs) [XML10][XML11]. ASN.X is defined in terms of rules for translating from an ASN.1 specification. This does not preclude an ASN.X module being written directly without a pre-existing ASN.1 module; however, such an ASN.X module is considered valid if and only if there exists, in principle, an ASN.1 module that when translated would yield the ASN.X module. The format for ASN.X has also been designed so that the content of an ASN.X module conforms to the RXER encoding of an abstract value of an ASN.1 type, the ModuleDefinition type, presented in Appendix A. This means that it is possible to decode an ASN.X module using an RXER decoder and then re-encode the abstract value (for storage or
transmission) using any of the other encoding rules for ASN.1. Thus, the "X" in ASN.X can be regarded as standing for either XML or RXER, or more generally, for any set of ASN.1 encoding rules. The ASN.X translation of the ASN.1 module in Appendix A is presented in Appendix B.2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are to be interpreted as described in BCP 14, RFC 2119 [BCP14]. The key word "OPTIONAL" is exclusively used with its ASN.1 meaning. Throughout this document "type" shall be taken to mean an ASN.1 type, and "value" shall be taken to mean an ASN.1 abstract value. A reference to an ASN.1 production [X.680] (e.g., Type, NamedType) is a reference to the text in an ASN.1 specification corresponding to that production. The description of the translation of an ASN.1 module into an ASN.X module makes use of definitions from the XML Information Set (Infoset) [INFOSET]. In particular, information item property names follow the Infoset convention of being shown in square brackets, e.g., [local name]. Literal values of Infoset properties are enclosed in double quotes; however, the double quotes are not part of the property values. In the sections that follow, "information item" will be abbreviated to "item", e.g., "element information item" is abbreviated to "element item". Element items will be referred to by their [local name] in angle brackets, e.g., "the <type> element item" means the element item with the [local name] "type". Attribute items will be referred to by their [local name], e.g., "the type attribute item" means the attribute item with the [local name] "type". This document uses the namespace prefix "asnx:" to stand for the namespace name "urn:ietf:params:xml:ns:asnx", though in practice any valid namespace prefix is permitted in ASN.X. Encoding instructions [X.680-1] referenced by name in this specification are encoding instructions for RXER [RXEREI]. The associated provisions do not apply to encoding instructions for other encoding rules that happen to have the same name. Code points for characters [UNICODE] are expressed using the Unicode convention U+n, where n is four to six hexadecimal digits, e.g., the space character is U+0020.
3. General Considerations
ASN.X is defined in terms of rules for translating an ASN.1 module into a synthetic Infoset. This synthetic Infoset is then serialized into a well-formed and valid XML document (the ASN.X module) in the same manner that the synthetic Infoset for a non-canonical RXER encoding is serialized into an XML document (see Section 6.12 of the specification for RXER [RXER]). Aside: The serialization permits CDATA sections, character references, and parsed entity references. However, note that an ASN.X module may be transferred as data in a protocol and that some protocols disallow entity references. Apart from the [document element] of the document item for an ASN.X module, the translation of some ASN.1 construct belongs to the [children] or [attributes] of an enclosing element item. Where the translation of the construct is an element item, it is appended to the [children] of the enclosing element item. Elements MUST be appended to the [children] of the enclosing element item in the order described. Translators MAY add white space character items (i.e., U+0020, U+0009, U+000D and U+000A) to the [children] of any element item (to improve the layout) except element items with the [local name] "literalValue", "fieldName", or "restrictBy". Aside: White space in the [children] of <fieldName> and <restrictBy> element items is explicitly covered under their respective descriptions. Where the translation of the construct is an attribute item, it is added to the [attributes] of the enclosing element item. The order of attribute items is not significant. Translators MAY add leading and trailing white space characters to the [normalized value] of any attribute item except an attribute item with the [local name] "literalValue". Aside: An attribute or element item with the [local name] "literalValue" holds an RXER Infoset translation of an abstract value, and white space characters may be significant in that abstract value. In most cases, RXER itself permits optional leading and trailing white space characters in the Infoset translation. Translators MAY add comment and processing instruction (PI) items to the [children] of any element item except an element item with the [local name] "literalValue".
Aside: In most cases, RXER itself permits comment and PI items in the [children] of the element items with the [local name] "literalValue". Aside: Note that an ASN.X module may be transferred as data in a protocol and that some protocols disallow processing instructions. The [in-scope namespaces] and [namespace attributes] for <literalValue> and <restrictBy> element items are determined according to Section 6.10 of the specification for RXER [RXER]. The [in-scope namespaces] and [namespace attributes] for other element items in the translation are determined according to Section 6.2.2.1 of the specification for RXER. The [namespace name] of any element item or attribute item generated by the translation from an ASN.1 specification has no value unless specified otherwise. In those cases where the [namespace name] of an element item has a value, the [prefix] of the element item is determined according to Section 6.2.2.2 of the specification for RXER. In those cases where the [namespace name] of an attribute item has a value, the [prefix] of the attribute item is determined according to Section 6.2.3.1 of the specification for RXER. Aside: Non-canonical RXER allows all valid namespace prefixes and all valid placements for their corresponding namespace declaration attributes. Whenever an element item is added to the [children] of an enclosing element item, the enclosing element item becomes the [parent] of the element item. Whenever an attribute item is added to the [attributes] of an element item, the element item becomes the [owner element] of the attribute item. For each attribute item, the [specified] property is set to true, the [attribute type] has no value, and the value of the [references] property is set to unknown.3.1. Annotations
In a number of places, as indicated in subsequent sections, the translator is permitted to add an element item with the [local name] "annotation". The [children] and [attributes] of the <annotation> element item are at the discretion of the translator. Typical uses of the <annotation> element item would be to hold comments from the ASN.1 specification that are normative in nature, e.g., a comment in a user-defined constraint, or to hold directives for an ASN.1 compiler.
Free text or XML comments in an <annotation> element will be preserved in a Canonical RXER (CRXER) encoding [RXER] (because the corresponding ASN.1 type for the <annotation> element item is the Markup type [RXER]), while XML comments outside <annotation> elements will not be preserved. Vendors using the <annotation> element items to hold ASN.1 compiler directives (as attributes or child elements of the <annotation> element) SHOULD use element or attribute names that are qualified with a namespace name specific to the vendor.4. ModuleDefinition Translation
The translation of a ModuleDefinition [X.680] (an ASN.1 module) is an element item with the [local name] "module" and the [namespace name] "urn:ietf:params:xml:ns:asnx" (i.e., an <asnx:module> element item). The element item is typically the [document element] of a document item. An attribute item with the [local name] "format" and [normalized value] "1.0" MAY be added to the [attributes] of the <asnx:module> element item. An ASN.1 module has a schema identity URI if it contains a SCHEMA-IDENTITY encoding instruction, in which case the schema identity URI is the character string specified by the AnyURIValue of the SCHEMA-IDENTITY encoding instruction. If the ASN.1 module being translated has a schema identity URI, then an attribute item with the [local name] "schemaIdentity" SHALL be added to the [attributes] of the <asnx:module> element item. The [normalized value] of this attribute item is the schema identity URI of the module. If the target namespace [RXEREI] for the ASN.1 module is not absent, then an attribute item with the [local name] "targetNamespace" SHALL be added to the [attributes] of the <asnx:module> element item. The [normalized value] of this attribute item is the target namespace of the module. Aside: An ASN.1 module has a target namespace if it contains a TARGET-NAMESPACE encoding instruction. If the ASN.1 module contains a TARGET-NAMESPACE encoding instruction that specifies a Prefix, then an attribute item with the [local name] "targetPrefix" SHALL be added to the [attributes] of the
<asnx:module> element item. The [normalized value] of this attribute item is the character string specified by the NCNameValue in the Prefix. In examples in the remainder of this document, the namespace prefix "tns:" is used to stand for the target namespace of the module being translated. An attribute item with the [local name] "name" SHALL be added to the [attributes] of the <asnx:module> element item. The [normalized value] of this attribute item is the modulereference in the ModuleIdentifier in the ModuleDefinition. If the DefinitiveIdentifier in the ModuleIdentifier in the ModuleDefinition is not empty, then an attribute item with the [local name] "identifier" SHALL be added to the [attributes] of the <asnx:module> element item. The [normalized value] of this attribute item is the RXER character data translation [RXER] of the DefinitiveIdentifier. If the TagDefault in the ModuleDefinition is empty, then an attribute item with the [local name] "tagDefault" and [normalized value] "explicit" SHALL be added to the [attributes] of the <asnx:module> element item. If the TagDefault in the ModuleDefinition is not empty and the first keyword in the TagDefault is not "AUTOMATIC", then an attribute item with the [local name] "tagDefault" SHALL be added to the [attributes] of the <asnx:module> element item. The [normalized value] of this attribute item is the first keyword in the TagDefault with all letters downcased, i.e., "explicit" or "implicit". If the TagDefault in the ModuleDefinition is not empty and the first keyword in the TagDefault is "AUTOMATIC", then an attribute item with the [local name] "tagDefault" and [normalized value] "automatic" MAY be added to the [attributes] of the <asnx:module> element item. If the ExtensionDefault in the ModuleDefinition is not empty, then an attribute item with the [local name] "extensibilityImplied" and [normalized value] "true" or "1" SHALL be added to the [attributes] of the <asnx:module> element item. If the ExtensionDefault in the ModuleDefinition is empty, then an attribute item with the [local name] "extensibilityImplied" and [normalized value] "false" or "0" MAY be added to the [attributes] of the <asnx:module> element item.
An element item with the [local name] "annotation" MAY be added to the [children] of the <asnx:module> element item. The translation of each Assignment in the AssignmentList in the ModuleBody in the ModuleDefinition of the module being translated SHALL be appended to the [children] of the <asnx:module> element item. If the EncodingControlSections instance in the ModuleDefinition contains an EncodingControlSection for RXER, then the translation of each NamedType in a TopLevelComponent [RXEREI] nested in the EncodingInstructionAssignmentList SHALL be added to the [children] of the <asnx:module> element item. The relative order of the top-level components [RXEREI] SHOULD be preserved in the translation; however, the translations of the top-level components MAY be interspersed with the translations of the assignments in the AssignmentList. The translation of the EncodingControlSections instance in the ModuleDefinition of the module being translated SHALL be appended to the [children] of the <asnx:module> element item. Example MyModule DEFINITIONS IMPLICIT TAGS EXTENSIBILITY IMPLIED ::= BEGIN MyType ::= INTEGER ENCODING-CONTROL RXER SCHEMA-IDENTITY "http://example.com/id/MyModule" TARGET-NAMESPACE "http://example.com/ns/MyModule" COMPONENT myElement INTEGER END <asnx:module xmlns:asnx="urn:ietf:params:xml:ns:asnx" name="MyModule" schemaIdentity="http://example.com/id/MyModule" targetNamespace="http://example.com/ns/MyModule" tagDefault="implicit" extensibilityImplied="true"> <namedType name="MyType" type="asnx:INTEGER"/>
<element name="myElement" type="asnx:INTEGER"/> </asnx:module>5. Translation of Assignments
5.1. Referencing Named Constructs
An Assignment in ASN.1 associates a reference name with a Type, Value, ValueSet, ObjectClass, Object, or ObjectSet. For ASN.X, an Assignment is also regarded as associating an expanded name [XMLNS10][XMLNS11] with the Type, Value, ValueSet, ObjectClass, Object, or ObjectSet. ASN.X uses these expanded names, rendered as qualified names [XMLNS10][XMLNS11], in place of the references in an ASN.1 specification. In every case, the local name of the expanded name is the typereference, valuereference, objectclassreference, objectreference, or objectsetreference in the Assignment (i.e., the [normalized value] of the name attribute item in the translation of the Assignment, ignoring white space characters). If the target namespace of the ASN.1 module in which the Assignment is defined is not absent, then the namespace name of the expanded name is that target namespace; otherwise, the namespace name of the expanded name has no value. When the expanded name is rendered as a qualified name, the namespace prefix is determined according to Section 6.7.11.1 of the specification for RXER [RXER]. If an ASN.1 specification contains two or more modules where the target namespace is absent, then there exists the possibility that the expanded names defined by the ASN.X translations of those modules are not distinct. The expanded names are not distinct if: (1) two or more type or value set assignments define the same typereference, or (2) two or more value assignments define the same valuereference, or (3) two or more object class assignments define the same objectclassreference, or (4) two or more object assignments define the same objectreference, or (5) two or more object set assignments define the same objectsetreference, or
(6) two or more top-level element components [RXEREI] have the same local name, or (7) two or more top-level attribute components [RXEREI] have the same local name. If the expanded names are not distinct, then an unambiguous translation into ASN.X does not exist unless each of the modules has a SCHEMA-IDENTITY encoding instruction. Consequently, if two or more modules where the target namespace is absent are being translated into ASN.X and the reference names defined in those modules will not be distinct, then as a local action prior to the translation, a SCHEMA-IDENTITY encoding instruction MUST be added to each of the modules that defines one or more of the indistinct expanded names and that does not already have a SCHEMA-IDENTITY encoding instruction. The character string (a URI) specified by the AnyURIValue of each added SCHEMA-IDENTITY encoding instruction is freely chosen by the translator, subject to the condition that these character strings are distinct [RXEREI]. Aside: Although this means that different translators might produce ASN.X modules that are syntactically different for any given ASN.1 module, those ASN.X modules will be semantically equivalent to each other and to the original ASN.1 module. TARGET-NAMESPACE and SCHEMA-IDENTITY encoding instructions are RECOMMENDED for every ASN.1 module.5.2. Importing Namespaces
An Assignment is referenced from an ASN.X module if its associated expanded name appears as a qualified name in the [normalized value] of an attribute item with the [local name] "type", "value", "class", "object", or "objectSet". These references are categorized as direct references. An Assignment or top-level component is also referenced from an ASN.X module if its expanded name appears as a qualified name in the [normalized value] of an attribute item with the [local name] "ref". This reference is only categorized as direct if the ref attribute is not the result of the translation of a DefinedType subject to a TYPE-REF encoding instruction or a NamedType subject to an ATTRIBUTE-REF or ELEMENT-REF encoding instruction. Aside: In the case of an indirect reference, an attribute item with the [local name] "embedded" and [normalized value] "true" or "1" will also be present.
Definition (external module): An external module is any module other than the module being translated and the AdditionalBasicDefinitions module [RXER]. Aside: The AdditionalBasicDefinitions module is always assumed to be imported, as are all the built-in types and object classes of ASN.1. An element item with the [local name] "import" SHALL be added to the [children] of the <asnx:module> element item for each external module containing Assignments or top-level components that are directly referenced from the ASN.X module. An <import> element item MAY be added to the [children] of the <asnx:module> element item for any other external module. An attribute item with the [local name] "name" SHOULD be added to the [attributes] of the <import> element item. The [normalized value] of this attribute item is the modulereference in the ModuleIdentifier in the ModuleDefinition of the external module. If the DefinitiveIdentifier in the ModuleIdentifier in the ModuleDefinition of the external module is not empty, then an attribute item with the [local name] "identifier" SHALL be added to the [attributes] of the <import> element item. The [normalized value] of this attribute item is the RXER character data translation of the DefinitiveIdentifier. If the external module has a schema identity URI, then an attribute item with the [local name] "schemaIdentity" SHALL be added to the [attributes] of the <import> element item. The [normalized value] of this attribute item is the schema identity URI of the external module. If the target namespace of the external module is not absent, then an attribute item with the [local name] "namespace" SHALL be added to the [attributes] of the <import> element item. The [normalized value] of this attribute item is the target namespace of the external module. An attribute item with the [local name] "schemaLocation" MAY be added to the [attributes] of the <import> element item. The [normalized value] of this attribute item is a URI [URI] indicating the physical location of the ASN.X translation of the external module. The <import> element items MUST follow an <annotation> element item (if present) and MUST precede any other element items in the [children] of the <asnx:module> element item.
Note that because of the way parameterized references are expanded in ASN.X (see Section 13), the modules in the Imports in the ModuleBody in the ModuleDefinition may not correspond exactly to the <import> element items.5.3. TypeAssignment Translation
The translation of a TypeAssignment is an element item with the [local name] "namedType". An attribute item with the [local name] "name" SHALL be added to the [attributes] of the <namedType> element item. The [normalized value] of this attribute item is the typereference on the left-hand side of the assignment. An element item with the [local name] "annotation" MAY be added to the [children] of the <namedType> element item. The translation of the Type on the right-hand side of the assignment SHALL be added to the [children] or [attributes] of the <namedType> element item. Example MyType ::= INTEGER <namedType name="MyType" type="asnx:INTEGER"/>5.4. ValueAssignment and XMLValueAssignment Translation
The translation of a ValueAssignment is an element item with the [local name] "namedValue". An attribute item with the [local name] "name" SHALL be added to the [attributes] of the <namedValue> element item. The [normalized value] of this attribute item is the valuereference on the left-hand side of the assignment. An element item with the [local name] "annotation" MAY be added to the [children] of the <namedValue> element item. The translation of the Type on the left-hand side of the assignment SHALL be added to the [children] or [attributes] of the <namedValue> element item. The translation of the Value on the right-hand side of the assignment SHALL be added to the [children] or [attributes] of the <namedValue> element item. Example myValue INTEGER ::= 10 <namedValue name="myValue" type="asnx:INTEGER" literalValue="10"/>
An XMLValueAssignment is converted into the equivalent ValueAssignment and then translated as a ValueAssignment. Note that the ASN.X representation for a Value is unrelated to XMLTypedValue.5.5. ValueSetTypeAssignment Translation
The translation of a ValueSetTypeAssignment is an element item with the [local name] "namedValueSet". An attribute item with the [local name] "name" SHALL be added to the [attributes] of the <namedValueSet> element item. The [normalized value] of this attribute item is the typereference on the left-hand side of the assignment. An element item with the [local name] "annotation" MAY be added to the [children] of the <namedValueSet> element item. The translation of the Type on the left-hand side of the assignment SHALL be added to the [children] or [attributes] of the <namedValueSet> element item. The translation of the ValueSet on the right-hand side of the assignment SHALL be added to the [children] of the <namedValueSet> element item. Example MyValueSet INTEGER ::= { 10 } <namedValueSet name="MyValueSet" type="asnx:INTEGER"> <valueSet> <literalValue>10</literalValue> </valueSet> </namedValueSet>5.6. ObjectClassAssignment Translation
The translation of an ObjectClassAssignment is an element item with the [local name] "namedClass". An attribute item with the [local name] "name" SHALL be added to the [attributes] of the <namedClass> element item. The [normalized value] of this attribute item is the objectclassreference on the left-hand side of the assignment. An element item with the [local name] "annotation" MAY be added to the [children] of the <namedClass> element item. The translation of the ObjectClass on the right-hand side of the assignment SHALL be added to the [children] or [attributes] of the <namedClass> element item.
Example MY-CLASS ::= TYPE-IDENTIFIER <namedClass name="MY-CLASS" class="asnx:TYPE-IDENTIFIER"/>5.7. ObjectAssignment Translation
The translation of an ObjectAssignment is an element item with the [local name] "namedObject". An attribute item with the [local name] "name" SHALL be added to the [attributes] of the <namedObject> element item. The [normalized value] of this attribute item is the objectreference on the left-hand side of the assignment. An element item with the [local name] "annotation" MAY be added to the [children] of the <namedObject> element item. The translation of the DefinedObjectClass on the left-hand side of the assignment SHALL be added to the [children] or [attributes] of the <namedObject> element item. The translation of the Object on the right-hand side of the assignment SHALL be added to the [children] or [attributes] of the <namedObject> element item. Example myObject TYPE-IDENTIFIER ::= { NULL IDENTIFIED BY { 1 3 14 3 2 26 } } <namedObject name="myObject" class="asnx:TYPE-IDENTIFIER"> <object> <field name="id" literalValue="1.3.14.3.2.26"/> <field name="Type" type="asnx:NULL"/> </object> </namedObject>5.8. ObjectSetAssignment Translation
The translation of an ObjectSetAssignment is an element item with the [local name] "namedObjectSet". An attribute item with the [local name] "name" SHALL be added to the [attributes] of the <namedObjectSet> element item. The [normalized value] of this attribute item is the objectsetreference on the left-hand side of the assignment. An element item with the [local name] "annotation" MAY be added to the [children] of the <namedObjectSet> element item. The translation of the DefinedObjectClass on the left-hand side of the assignment SHALL be added to the [children] or [attributes] of the <namedObjectSet> element item. The translation of the ObjectSet on
the right-hand side of the assignment SHALL be added to the [children] or [attributes] of the <namedObjectSet> element item. Example MyObjectSet TYPE-IDENTIFIER ::= { myObject } <namedObjectSet name="MyObjectSet" class="asnx:TYPE-IDENTIFIER"> <objectSet> <object ref="tns:myObject"/> </objectSet> </namedObjectSet>5.9. ParameterizedAssignment Translation
The translation of an ASN.1 specification into ASN.X replaces any reference to a parameterized definition [X.683] with the definition expanded in-line. Consequently, there is no direct translation for a ParameterizedAssignment, though its definition may come into play in the translation of references to the parameterized definition (see Section 13).