rfc4912
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.
Legg Experimental [Page 1]
RFC 4912 Abstract Syntax Notation X July 2007
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
Legg Experimental [Page 2]
RFC 4912 Abstract Syntax Notation X July 2007
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
Legg Experimental [Page 3]
RFC 4912 Abstract Syntax Notation X July 2007
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
Legg Experimental [Page 4]
RFC 4912 Abstract Syntax Notation X July 2007
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.
Legg Experimental [Page 5]
RFC 4912 Abstract Syntax Notation X July 2007
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".
Legg Experimental [Page 6]
RFC 4912 Abstract Syntax Notation X July 2007
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.
Legg Experimental [Page 7]
RFC 4912 Abstract Syntax Notation X July 2007
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
Legg Experimental [Page 8]
RFC 4912 Abstract Syntax Notation X July 2007
<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.
Legg Experimental [Page 9]
RFC 4912 Abstract Syntax Notation X July 2007
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"/>
Legg Experimental [Page 10]
RFC 4912 Abstract Syntax Notation X July 2007
<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
Legg Experimental [Page 11]
RFC 4912 Abstract Syntax Notation X July 2007
(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.
Legg Experimental [Page 12]
RFC 4912 Abstract Syntax Notation X July 2007
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.
Legg Experimental [Page 13]
RFC 4912 Abstract Syntax Notation X July 2007
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"/>
Legg Experimental [Page 14]
RFC 4912 Abstract Syntax Notation X July 2007
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.
Legg Experimental [Page 15]
RFC 4912 Abstract Syntax Notation X July 2007
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
Legg Experimental [Page 16]
RFC 4912 Abstract Syntax Notation X July 2007
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).
6. Translation of Types
The rules for translating the different varieties of Type are
detailed in this section.
Note that the notation of ASN.1 is ambiguous where a Type is both
prefixed [X.680-1] (e.g., tagged) and constrained. For example, the
notation "[0] INTEGER (0..10)" could be interpreted as either a
tagged ConstrainedType or a constrained TaggedType. For the purposes
of the translation into ASN.X, the constraint is assumed to have
higher precedence than the prefix, so the above notation would be
taken to be a tagged ConstrainedType.
6.1. Identifier Replacement
Various RXER encoding instructions can be used to override an
identifier in an ASN.1 specification with an NCName [XMLNS10]. The
NCName is given preeminence in the ASN.X representation, and the
identifier is not explicitly given if it is algorithmically related
to the NCName. The cases where an NCName overrides an identifier are
covered individually in other parts of this specification and make
use of the following definition.
Definition (reduction): The reduction of an NCName is the string of
characters resulting from the following operations performed in order
on the NCName:
Legg Experimental [Page 17]
RFC 4912 Abstract Syntax Notation X July 2007
(1) replace each full stop ('.', U+002E) and low line ('_', U+005F)
character with a hyphen character ('-', U+002D),
(2) remove every character except Latin letters (U+0041-U+005A,
U+0061-U+007A), decimal digits (U+0030-U+0039), and hyphens
(U+002D),
(3) remove leading and trailing hyphen characters,
(4) replace sequences of two or more hyphen characters with a single
hyphen, and
(5) convert the first character to lowercase if it is an uppercase
letter.
Aside: If the reduction of an NCName is not the same as the
identifier that the NCName replaces, then the identifier will be
explicitly given in the translation into ASN.X.
6.2. DefinedType Translation
If a Type is a DefinedType in a ReferencedType, then the translation
of the Type is the translation of the DefinedType.
If a DefinedType is not a ParameterizedType,
ParameterizedValueSetType, or DummyReference and is not subject to a
TYPE-REF or REF-AS-TYPE encoding instruction, then the translation of
the DefinedType is either the attribute form translation of a type
reference, or the element form translation of a type reference.
The attribute form translation of a type reference is an attribute
item with the [local name] "type". The [normalized value] of this
attribute item is a qualified name for the expanded name of the
referenced type definition (see Section 5.1). The attribute form
translation SHALL NOT be used if this expanded name is not distinct
with respect to the current module and the modules referenced by its
<import> element items (see Section 5.1).
The element form translation of a type reference is an element item
with the [local name] "type". An element item with the [local name]
"annotation" MAY be added to the [children] of the <type> element
item. An attribute item with the [local name] "ref" SHALL be added
to the [attributes] of the <type> element item. The
[normalized value] of this attribute item is a qualified name for the
expanded name of the referenced type definition. If this expanded
name is not distinct with respect to the current module and the
modules referenced by its <import> element items, then an attribute
item with the [local name] "context" SHALL be added to the
Legg Experimental [Page 18]
RFC 4912 Abstract Syntax Notation X July 2007
[attributes] of the <type> element item; otherwise, if the module
containing the referenced type definition has a schema identity URI,
then an attribute item with the [local name] "context" MAY be added
to the [attributes] of the <type> element item. The
[normalized value] of this attribute item is the schema identity URI
of the module containing the type definition referenced by the
DefinedType.
Aside: If a reference name is not distinct, then the module
containing the referenced definition must have a schema identity
URI (see Section 5.1).
An attribute item with the [local name] "embedded" and
[normalized value] "false" or "0" MAY be added to the [attributes] of
the <type> element item.
The translation of the DefinedType is the same whether the type
definition is referenced by a typereference or an
ExternalTypeReference.
If a DefinedType is subject to a TYPE-REF encoding instruction, then
the translation of the DefinedType is an element item with the
[local name] "type". An element item with the [local name]
"annotation" MAY be added to the [children] of the <type> element
item. An attribute item with the [local name] "ref" SHALL be added
to the [attributes] of the <type> element item. The
[normalized value] of this attribute item is the RXER character data
translation of the QNameValue in the TYPE-REF encoding instruction.
If a ContextParameter is present in the RefParameters in the TYPE-REF
encoding instruction, then an attribute item with the [local name]
"context" SHALL be added to the [attributes] of the <type> element
item. The [normalized value] of this attribute item is the string
value of the AnyURIValue in the ContextParameter. An attribute item
with the [local name] "embedded" and [normalized value] "true" or "1"
SHALL be added to the [attributes] of the <type> element item.
Aside: The embedded attribute item indicates whether a type is
directly referenced as a DefinedType or indirectly referenced
through a TYPE-REF encoding instruction. An ASN.1 type can be
referenced either way. Type definitions in other schema languages
cannot be directly referenced.
If a DefinedType is subject to a REF-AS-TYPE encoding instruction,
then the translation of the DefinedType is an element item with the
[local name] "type". An element item with the [local name]
"annotation" MAY be added to the [children] of the <type> element
item. An attribute item with the [local name] "elementType" SHALL be
added to the [attributes] of the <type> element item. The
Legg Experimental [Page 19]
RFC 4912 Abstract Syntax Notation X July 2007
[normalized value] of this attribute item is the RXER character data
translation of the NameValue in the REF-AS-TYPE encoding instruction.
If a ContextParameter is present in the RefParameters in the
REF-AS-TYPE encoding instruction, then an attribute item with the
[local name] "context" SHALL be added to the [attributes] of the
<type> element item. The [normalized value] of this attribute item
is the string value of the AnyURIValue in the ContextParameter.
Example
CHOICE {
one Foo,
two [RXER:TYPE-REF
{ namespace-name "http://www.example.com/PO1",
local-name "PurchaseOrderType" }]
Markup,
three [RXER:REF-AS-TYPE "product"
CONTEXT "http://www.example.com/inventory"]
Markup
}
<type>
<choice>
<element name="one" type="tns:Foo"/>
<element name="two" xmlns:po="http://www.example.com/PO1">
<type ref="po:PurchaseOrderType" embedded="true"/>
</element>
<element name="three">
<type elementType="product"
context="http://www.example.com/inventory"/>
</element>
</choice>
</type>
If a DefinedType is a DummyReference, ParameterizedType, or
ParameterizedValueSetType, then the translation of the Type is the
translation of that DummyReference, ParameterizedType, or
ParameterizedValueSetType (see Section 13).
6.3. Translation of Built-in Types
If a Type is a BuiltinType or ReferencedType that is one of the
productions in Table 1 in Section 5 of the specification for RXER
[RXER], then the translation of the Type is either the attribute form
or element form translation of that type.
Legg Experimental [Page 20]
RFC 4912 Abstract Syntax Notation X July 2007
The attribute form translation of a Type that is a BuiltinType or
ReferencedType that is one of the productions in Table 1 is an
attribute item with the [local name] "type". The [normalized value]
of this attribute item is a qualified name for the expanded name of
the built-in type (see Section 5 of the specification for RXER
[RXER]).
The element form translation of a Type that is a BuiltinType or
ReferencedType that is one of the productions in Table 1 is an
element item with the [local name] "type". An element item with the
[local name] "annotation" MAY be added to the [children] of the
<type> element item. An attribute item with the [local name] "ref"
SHALL be added to the [attributes] of the <type> element item. The
[normalized value] of this attribute item is a qualified name for the
expanded name of the built-in type.
Example
BOOLEAN
<type ref="asnx:BOOLEAN"/>
Usually the translator is free to choose either the attribute form or
element form translation for a Type; however, in some contexts
attribute forms for a Type are explicitly disallowed.
6.4. BitStringType Translation
The translation of a BitStringType with a NamedBitList is an element
item with the [local name] "type". An element item with the
[local name] "annotation" MAY be added to the [children] of the
<type> element item. An element item with the [local name]
"namedBitList" SHALL be appended to the [children] of the <type>
element item. The translation of each NamedBit in the NamedBitList
SHALL be appended to the [children] of the <namedBitList> element
item.
The translation of a NamedBit is an element item with the
[local name] "namedBit". An attribute item with the [local name]
"name" SHALL be added to the [attributes] of the <namedBit> element
item. If the BitStringType is subject to a VALUES encoding
instruction, then the [normalized value] of this attribute item is
the replacement name [RXEREI] for the identifier in the NamedBit;
otherwise, it is the identifier in the NamedBit. If the
BitStringType is subject to a VALUES encoding instruction and the
reduction of the replacement name (see Section 6.1) is not the same
as the identifier, then an attribute item with the [local name]
"identifier" SHALL be added to the [attributes] of the <namedBit>
Legg Experimental [Page 21]
RFC 4912 Abstract Syntax Notation X July 2007
element item; otherwise, an attribute item with the [local name]
"identifier" MAY be added to the [attributes] of the <namedBit>
element item. The [normalized value] of this attribute item is the
identifier in the NamedBit. An attribute item with the [local name]
"bit" SHALL be added to the [attributes] of the <namedBit> element
item. The [normalized value] of this attribute item is the digit
string representation of the integer value of the number or
DefinedValue in the NamedBit.
Examples
BIT STRING { zero(0), one(1), two(2) }
<type>
<namedBitList>
<namedBit name="zero" bit="0"/>
<namedBit name="one" bit="1"/>
<namedBit name="two" bit="2"/>
</namedBitList>
</type>
[RXER:VALUES ALL CAPITALIZED, wednesday AS "Midweek"]
BIT STRING {
monday(0), tuesday(1), wednesday(2),
thursday(3), friday(4)
}
<type>
<namedBitList>
<namedBit name="Monday" bit="0"/>
<namedBit name="Tuesday" bit="1"/>
<namedBit name="Midweek" identifier="wednesday" bit="2"/>
<namedBit name="Thursday" bit="3"/>
<namedBit name="Friday" bit="4"/>
</namedBitList>
</type>
6.5. IntegerType Translation
The translation of an IntegerType with a NamedNumberList is an
element item with the [local name] "type". An element item with the
[local name] "annotation" MAY be added to the [children] of the
<type> element item. An element item with the [local name]
"namedNumberList" SHALL be appended to the [children] of the <type>
element item. The translation of each NamedNumber in the
NamedNumberList SHALL be appended to the [children] of the
<namedNumberList> element item.
Legg Experimental [Page 22]
RFC 4912 Abstract Syntax Notation X July 2007
The translation of a NamedNumber is an element item with the
[local name] "namedNumber". An attribute item with the [local name]
"name" SHALL be added to the [attributes] of the <namedNumber>
element item. If the IntegerType is subject to a VALUES encoding
instruction, then the [normalized value] of this attribute item is
the replacement name [RXEREI] for the identifier in the NamedNumber;
otherwise, it is the identifier in the NamedNumber. If the
IntegerType is subject to a VALUES encoding instruction and the
reduction of the replacement name (see Section 6.1) is not the same
as the identifier, then an attribute item with the [local name]
"identifier" SHALL be added to the [attributes] of the <namedNumber>
element item; otherwise, an attribute item with the [local name]
"identifier" MAY be added to the [attributes] of the <namedNumber>
element item. The [normalized value] of this attribute item is the
identifier in the NamedNumber. An attribute item with the
[local name] "number" SHALL be added to the [attributes] of the
<namedNumber> element item. The [normalized value] of this attribute
item is the digit string representation of the integer value of the
SignedNumber or DefinedValue in the NamedNumber.
Examples
INTEGER { nothing(0), a-little(1), a-lot(100) }
<type>
<namedNumberList>
<namedNumber name="nothing" number="0"/>
<namedNumber name="a-little" number="1"/>
<namedNumber name="a-lot" number="100"/>
</namedNumberList>
</type>
[RXER:VALUES ALL CAPITALIZED, very-high AS "DANGEROUS"]
INTEGER { low(25), medium(50), high(75), very-high(100) }
<type>
<namedNumberList>
<namedNumber name="Low" number="25"/>
<namedNumber name="Medium" number="50"/>
<namedNumber name="High" number="75"/>
<namedNumber name="DANGEROUS" identifier="very-high"
number="100"/>
</namedNumberList>
</type>
Legg Experimental [Page 23]
RFC 4912 Abstract Syntax Notation X July 2007
6.6. EnumeratedType Translation
The translation of an EnumeratedType is an element item with the
[local name] "type". An element item with the [local name]
"annotation" MAY be added to the [children] of the <type> element
item. An element item with the [local name] "enumerated" SHALL be
appended to the [children] of the <type> element item. The
translation of each EnumerationItem nested in the RootEnumeration in
the Enumerations instance in the EnumeratedType SHALL be appended to
the [children] of the <enumerated> element item.
If an ellipsis ("...") is present in the Enumerations instance, then
an element item with the [local name] "extension" SHALL be appended
to the [children] of the <enumerated> element item and the
translation of the ExceptionSpec (possibly empty) SHALL be added to
the [children] of the <extension> element item. If an
AdditionalEnumeration is present in the Enumerations instance, then
the translation of each EnumerationItem nested in the
AdditionalEnumeration SHALL be appended to the [children] of the
<extension> element item.
The translation of an EnumerationItem is an element item with the
[local name] "enumeration".
If the EnumerationItem is of the "identifier" form, then an attribute
item with the [local name] "name" SHALL be added to the [attributes]
of the <enumeration> element item. If the EnumeratedType is subject
to a VALUES encoding instruction, then the [normalized value] of this
attribute item is the replacement name [RXEREI] for the identifier;
otherwise, it is the identifier. If the EnumeratedType is subject to
a VALUES encoding instruction and the reduction of the replacement
name (see Section 6.1) is not the same as the identifier, then an
attribute item with the [local name] "identifier" SHALL be added to
the [attributes] of the <enumeration> element item; otherwise, an
attribute item with the [local name] "identifier" MAY be added to the
[attributes] of the <enumeration> element item. The
[normalized value] of this attribute item is the identifier.
If the EnumerationItem is of the "NamedNumber" form, then an
attribute item with the [local name] "name" SHALL be added to the
[attributes] of the <enumeration> element item. If the
EnumeratedType is subject to a VALUES encoding instruction, then the
[normalized value] of this attribute item is the replacement name
[RXEREI] for the identifier in the NamedNumber; otherwise, it is the
identifier in the NamedNumber. If the EnumeratedType is subject to a
VALUES encoding instruction and the reduction of the replacement name
is not the same as the identifier, then an attribute item with the
[local name] "identifier" SHALL be added to the [attributes] of the
Legg Experimental [Page 24]
RFC 4912 Abstract Syntax Notation X July 2007
<enumeration> element item; otherwise, an attribute item with the
[local name] "identifier" MAY be added to the [attributes] of the
<enumeration> element item. The [normalized value] of this attribute
item is the identifier in the NamedNumber. An attribute item with
the [local name] "number" SHALL be added to the [attributes] of the
<enumeration> element item. The [normalized value] of this attribute
item is the digit string representation of the integer value of the
SignedNumber or DefinedValue in the NamedNumber.
Examples
ENUMERATED { red(0), green(1), ..., blue(2) }
<type>
<enumerated>
<enumeration name="red" number="0"/>
<enumeration name="green" number="1"/>
<extension>
<enumeration name="blue" number="2"/>
</extension>
</enumerated>
</type>
[RXER:VALUES ALL CAPITALIZED, red AS "Crimson"]
ENUMERATED { red, yellow, green, blue }
<type>
<enumerated>
<enumeration name="Crimson" identifier="red"/>
<enumeration name="Yellow"/>
<enumeration name="Green"/>
<enumeration name="Blue"/>
</enumerated>
</type>
6.7. PrefixedType Translation
The translation of a PrefixedType [X.680-1] that is a TaggedType is
either the short form translation (Section 6.7.1) or long form
translation (Section 6.7.2) of the TaggedType.
Aside: The short form translation is provided because TaggedType
notation is heavily used in existing ASN.1 specifications. The
long form translation has the same structure as the translation of
an EncodingPrefixedType and can be simplified where there is a
series of nested PrefixedType instances.
Legg Experimental [Page 25]
RFC 4912 Abstract Syntax Notation X July 2007
If a PrefixedType is an EncodingPrefixedType and the
EncodingReference is RXER, or the EncodingReference is empty and the
default encoding reference [X.680-1] for the module is RXER, then the
translation of the PrefixedType is the translation of the Type in the
EncodingPrefixedType.
Aside: This is not suggesting that RXER encoding instructions are
ignored. Encoding instructions for RXER are not explicitly
represented in ASN.X, but rather affect how an ASN.1 module is
translated into an ASN.X module (since the content of an ASN.X
module is also the RXER encoding of an abstract value of the
ModuleDefinition ASN.1 type in Appendix A). The individual
effects of RXER encoding instructions on the translation are
addressed in other parts of this specification. Encoding
instructions for other encoding rules have explicit
representations in ASN.X.
If a PrefixedType is an EncodingPrefixedType and the
EncodingReference is not RXER, or the EncodingReference is empty and
the default encoding reference for the module is not RXER, then the
translation of the PrefixedType is an element item with the
[local name] "prefixed". The translation of the EncodingPrefix in
the EncodingPrefixedType SHALL be added to the [children] of the
<prefixed> element item.
If the EncodingReference of an EncodingPrefix is not empty, then the
translation of the EncodingPrefix is an element item with the
encodingreference in the EncodingReference as the [local name]. The
translation of the EncodingInstruction in the EncodingPrefix SHALL be
added to the [children] of this element item.
If the EncodingReference of an EncodingPrefix is empty, then the
translation of the EncodingPrefix is an element item with the default
encoding reference for the module as the [local name]. The
translation of the EncodingInstruction in the EncodingPrefix SHALL be
added to the [children] of this element item.
The EncodingInstruction notation is different for each set of
encoding instructions, and their translations into ASN.X are
specified in separate documents [GSEREIT][XEREIT]. At the time of
writing, only three sets of encoding instructions have been defined
(for RXER [RXEREI], GSER [GSEREI], and EXTENDED-XER [X.693-1]).
If the child <type> element item of a <prefixed> element item has no
attribute items and has a child <prefixed> element item, then that
child <type> element item MAY be replaced by the [children] and
[attributes] of the inner <prefixed> element item. Note that the
long form translation of a TaggedType is also eligible for this
Legg Experimental [Page 26]
RFC 4912 Abstract Syntax Notation X July 2007
rewriting step. This rewriting step MAY be applied to the result of
a previous rewriting step if the necessary condition still holds.
Example
These three definitions are equivalent.
[XER:ATTRIBUTE] [XER:USE-UNION] [GSER:CHOICE-OF-STRINGS] CHOICE {
one PrintableString,
two UTF8String
}
<type>
<prefixed>
<XER><attribute/></XER>
<type>
<prefixed>
<XER><useUnion/></XER>
<type>
<prefixed>
<GSER><choiceOfStrings/></GSER>
<type>
<choice>
<element name="one" type="asnx:PrintableString"/>
<element name="two" type="asnx:UTF8String"/>
</choice>
</type>
</prefixed>
</type>
</prefixed>
</type>
</prefixed>
</type>
<type>
<prefixed>
<XER><attribute/></XER>
<XER><useUnion/></XER>
<GSER><choiceOfStrings/></GSER>
<type>
<choice>
<element name="one" type="asnx:PrintableString"/>
<element name="two" type="asnx:UTF8String"/>
</choice>
</type>
</prefixed>
</type>
Legg Experimental [Page 27]
RFC 4912 Abstract Syntax Notation X July 2007
6.7.1. Short Form TaggedType Translation
The short form translation of a TaggedType is an element item with
the [local name] "type". An element item with the [local name]
"annotation" MAY be added to the [children] of the <type> element
item. An element item with the [local name] "tagged" SHALL be
appended to the [children] of the <type> element item.
If the Class in the Tag in the TaggedType is not empty, then an
attribute item with the [local name] "tagClass" SHALL be added to the
[attributes] of the <tagged> element item. The [normalized value] of
this attribute item is the Class of the Tag with all letters
downcased, i.e., either "universal", "application", or "private".
An attribute item with the [local name] "number" SHALL be added to
the [attributes] of the <tagged> element item. The
[normalized value] of this attribute item is the digit string
representation of the integer value of the number or DefinedValue in
the ClassNumber in the Tag.
If the Tag is immediately followed by the "IMPLICIT" keyword, then an
attribute item with the [local name] "tagging" and [normalized value]
"implicit" SHALL be added to the [attributes] of the <tagged> element
item.
If the Tag is immediately followed by the "EXPLICIT" keyword, then an
attribute item with the [local name] "tagging" and [normalized value]
"explicit" SHALL be added to the [attributes] of the <tagged> element
item.
The translation of the Type in the TaggedType SHALL be added to the
[children] or [attributes] of the <tagged> element item.
Examples
[0] INTEGER
<type>
<tagged number="0" type="asnx:INTEGER"/>
</type>
[APPLICATION 10] IMPLICIT BOOLEAN
<type>
<tagged tagClass="application" number="10" tagging="implicit"
type="asnx:BOOLEAN"/>
</type>
Legg Experimental [Page 28]
RFC 4912 Abstract Syntax Notation X July 2007
6.7.2. Long Form TaggedType Translation
The long form translation of a TaggedType is an element item with the
[local name] "type". An element item with the [local name]
"annotation" MAY be added to the [children] of the <type> element
item. An element item with the [local name] "prefixed" SHALL be
appended to the [children] of the <type> element item. The
translation of the Tag in the TaggedType SHALL be added to the
[children] of the <prefixed> element item.
The translation of a Tag is an element item with the [local name]
"TAG".
If the Class of the Tag is not empty, then an attribute item with the
[local name] "tagClass" SHALL be added to the [attributes] of the
<TAG> element item. The [normalized value] of this attribute item is
the Class of the Tag with all letters downcased, i.e., either
"universal", "application", or "private".
An attribute item with the [local name] "number" SHALL be added to
the [attributes] of the <TAG> element item. The [normalized value]
of this attribute item is the digit string representation of the
integer value of the number or DefinedValue in the ClassNumber in the
Tag.
If the Tag is immediately followed by the "IMPLICIT" keyword, then an
attribute item with the [local name] "tagging" and [normalized value]
"implicit" SHALL be added to the [attributes] of the <TAG> element
item.
If the Tag is immediately followed by the "EXPLICIT" keyword, then an
attribute item with the [local name] "tagging" and [normalized value]
"explicit" SHALL be added to the [attributes] of the <TAG> element
item.
The translation of the Type in the TaggedType SHALL be added to the
[children] or [attributes] of the <prefixed> element item.
Examples
[0] INTEGER
<type>
<prefixed type="asnx:INTEGER">
<TAG number="0"/>
</prefixed>
</type>
Legg Experimental [Page 29]
RFC 4912 Abstract Syntax Notation X July 2007
[APPLICATION 10] IMPLICIT BOOLEAN
<type>
<prefixed type="asnx:BOOLEAN">
<TAG tagClass="application" number="10" tagging="implicit"/>
</prefixed>
</type>
6.8. SelectionType Translation
The translation of a SelectionType is an element item with the
[local name] "type". An element item with the [local name]
"annotation" MAY be added to the [children] of the <type> element
item. An element item with the [local name] "selection" SHALL be
appended to the [children] of the <type> element item.
The identifier in a SelectionType identifies a NamedType in the
definition of the Type in the SelectionType. The translation of that
NamedType will be an element item with the [local name] either
"attribute", "element", "component", "group", or "member". An
attribute item with the same [local name] as the translation of the
NamedType SHALL be added to the [attributes] of the <selection>
element item. The [normalized value] of this attribute item is a
qualified name for the expanded name of the NamedType [RXEREI].
The translation of the Type in the SelectionType SHALL be added to
the [children] or [attributes] of the <selection> element item.
Examples
field1 < MyChoiceType
<type>
<selection element="field1" type="tns:MyChoiceType"/>
</type>
field2 < CHOICE {
field2 [RXER:ATTRIBUTE][RXER:NAME AS "field-two"] INTEGER
}
<type>
<selection attribute="field-two">
<type>
<choice>
<attribute name="field-two" identifier="field2"
type="asnx:INTEGER"/>
</choice>
</type>
Legg Experimental [Page 30]
RFC 4912 Abstract Syntax Notation X July 2007
</selection>
</type>
6.9. InstanceOfType Translation
The translation of an InstanceOfType is an element item with the
[local name] "type". An element item with the [local name]
"annotation" MAY be added to the [children] of the <type> element
item. An element item with the [local name] "instanceOf" SHALL be
appended to the [children] of the <type> element item. The
translation of the DefinedObjectClass in the InstanceOfType SHALL be
added to the [children] or [attributes] of the <instanceOf> element
item.
Example
INSTANCE OF TYPE-IDENTIFIER
<type>
<instanceOf class="asnx:TYPE-IDENTIFIER"/>
</type>
6.10. ObjectClassFieldType Translation
The translation of an ObjectClassFieldType is an element item with
the [local name] "type". An element item with the [local name]
"annotation" MAY be added to the [children] of the <type> element
item. An element item with the [local name] "fromClass" SHALL be
appended to the [children] of the <type> element item. The
translation of the DefinedObjectClass in the ObjectClassFieldType
SHALL be added to the [children] or [attributes] of the <fromClass>
element item. The translation of the FieldName (see Section 9.2.6)
in the ObjectClassFieldType SHALL be added to the [children] or
[attributes] of the <fromClass> element item.
Example
OPERATION.&Linked.&ArgumentType
<type>
<fromClass class="tns:OPERATION"
fieldName="Linked/ArgumentType"/>
</type>
Legg Experimental [Page 31]
RFC 4912 Abstract Syntax Notation X July 2007
6.11. TypeFromObject and ValueSetFromObjects Translation
The translation of a TypeFromObject or ValueSetFromObjects is an
element item with the [local name] "type". An element item with the
[local name] "annotation" MAY be added to the [children] of the
<type> element item. An element item with the [local name]
"fromObjects" SHALL be appended to the [children] of the <type>
element item.
The translation of the ReferencedObjects instance in the
TypeFromObject or ValueSetFromObjects SHALL be added to the
[children] or [attributes] of the <fromObjects> element item.
The translation of the FieldName in the TypeFromObject or
ValueSetFromObjects SHALL be added to the [children] or [attributes]
of the <fromObjects> element item.
Example
invertMatrix.&Errors.&errorCode
<type>
<fromObjects object="tns:invertMatrix"
fieldName="Errors/errorCode"/>
</type>
6.12. Translation of Combining Types
This section details the translation of the ASN.1 combining types:
SET, SEQUENCE, CHOICE, SET OF, and SEQUENCE OF. The combining type
definitions all make use of the NamedType notation.
6.12.1. NamedType Translation
A NamedType is translated in one of three ways depending on the
context. These are the normal translation, the member translation,
and the item translation. These translations are not
interchangeable. One of the three will be explicitly invoked as part
of the translation of an enclosing combining type.
The normal translation of a NamedType is an element item with the
[local name] determined as follows:
(1) if the NamedType is subject to an ATTRIBUTE or ATTRIBUTE-REF
encoding instruction, or subject to a COMPONENT-REF encoding
instruction that references a top-level NamedType that is subject
to an ATTRIBUTE encoding instruction, then the [local name] is
"attribute",
Legg Experimental [Page 32]
RFC 4912 Abstract Syntax Notation X July 2007
(2) else if the NamedType is subject to a GROUP encoding instruction,
then the [local name] is "group",
(3) else if the NamedType is subject to a SIMPLE-CONTENT encoding
instruction, then the [local name] is "simpleContent",
(4) otherwise, the [local name] is "element" or "component"
(translator's choice).
Aside: The local names "element" and "component" are synonymous.
The "component" alternative is offered for specifying applications
that don't use RXER (except for the ASN.X specification itself, of
course), where referring to parts of an encoding as elements would
seem incongruous.
The member translation of a NamedType is an element item with the
[local name] "member".
The item translation of a NamedType is an element item with the
[local name] "item".
Aside: A Namedtype for which the member or item translation is
invoked will never be subject to an ATTRIBUTE, ATTRIBUTE-REF,
COMPONENT-REF, GROUP, SIMPLE-CONTENT, or TYPE-AS-VERSION encoding
instruction. These encoding instructions are also mutually
exclusive [RXEREI].
An element item with the [local name] "annotation" MAY be added to
the [children] of the <attribute>, <element>, <component>, <group>,
<item>, <member>, or <simpleContent> element item.
If a NamedType is subject to a TYPE-AS-VERSION encoding instruction,
then an attribute item with the [local name] "typeAsVersion" and
[normalized value] "true" or "1" SHALL be added to the <element> or
<component> element item. For the normal translation, if a NamedType
is not subject to an ATTRIBUTE, ATTRIBUTE-REF, COMPONENT-REF, GROUP,
SIMPLE-CONTENT, or TYPE-AS-VERSION encoding instruction, then an
attribute item with the [local name] "typeAsVersion" and
[normalized value] "false" or "0" MAY be added to the <element> or
<component> element item.
For the normal, member, and item translations, if a NamedType is not
subject to an ATTRIBUTE-REF, COMPONENT-REF, ELEMENT-REF, or
REF-AS-ELEMENT encoding instruction, then an attribute item with the
[local name] "name" SHALL be added to the [attributes] of the
<attribute>, <element>, <component>, <group>, <item>, <member>, or
Legg Experimental [Page 33]
RFC 4912 Abstract Syntax Notation X July 2007
<simpleContent> element item. The [normalized value] of this
attribute item is the local name of the expanded name of the
NamedType [RXEREI].
Aside: If there are no NAME, ATTRIBUTE-REF, COMPONENT_REF,
ELEMENT-REF or REF-AS-ELEMENT encoding instructions, then the
local name of the expanded name of a NamedType is the same as the
identifier in the NamedType.
If the reduction of the local name (an NCName) of the expanded name
of a NamedType is not the same as the identifier in the NamedType,
then an attribute item with the [local name] "identifier" SHALL be
added to the [attributes] of the <attribute>, <element>, <component>,
<group>, <item>, <member>, or <simpleContent> element item;
otherwise, an attribute item with the [local name] "identifier" MAY
be added to the [attributes] of the aforementioned element item. The
[normalized value] of this attribute item is the identifier in the
NamedType.
Aside: The identifier attribute is not contingent on there being a
name attribute. That is, an element item can have an identifier
attribute item without having a name attribute item.
If a NamedType is subject to a COMPONENT-REF encoding instruction,
then an attribute item with the [local name] "ref" SHALL be added to
the [attributes] of the <attribute>, <element>, or <component>
element item. The [normalized value] of this attribute item is a
qualified name for the expanded name of the top-level NamedType
referenced by the encoding instruction. If the expanded name is not
distinct with respect to the current module and the modules
referenced by its <import> element items (see Section 5.1), then an
attribute item with the [local name] "context" SHALL be added to the
[attributes] of the <attribute>, <element>, or <component> element
item; otherwise, if the module containing the referenced top-level
NamedType has a schema identity URI, then an attribute item with the
[local name] "context" MAY be added to the [attributes] of the
<attribute>, <element>, or <component> element item. The
[normalized value] of this attribute item is the schema identity URI
of the module containing the referenced top-level NamedType.
Aside: If an expanded name is not distinct, then the module
containing the referenced top-level NamedType must have a schema
identity URI (see Section 5.1).
If a NamedType is subject to a COMPONENT-REF encoding instruction,
then an attribute item with the [local name] "embedded" and
[normalized value] "false" or "0" MAY be added to the [attributes] of
the <attribute>, <element>, or <component> element item.
Legg Experimental [Page 34]
RFC 4912 Abstract Syntax Notation X July 2007
If a NamedType is subject to an ATTRIBUTE-REF or ELEMENT-REF encoding
instruction, then an attribute item with the [local name] "ref" SHALL
be added to the [attributes] of the <attribute>, <element>, or
<component> element item. The [normalized value] of this attribute
item is the RXER character data translation of the QNameValue in the
encoding instruction. An attribute item with the [local name]
"embedded" and [normalized value] "true" or "1" SHALL be added to the
[attributes] of the <attribute>, <element>, or <component> element
item.
If a NamedType is subject to a REF-AS-ELEMENT encoding instruction,
then an attribute item with the [local name] "elementType" SHALL be
added to the [attributes] of the <element> or <component> element
item. The [normalized value] of this attribute item is the RXER
character data translation of the NameValue in the REF-AS-ELEMENT
encoding instruction. If a Namespace is present in the
REF-AS-ELEMENT encoding instruction, then an attribute item with the
[local name] "namespace" SHALL be added to the [attributes] of the
<element> or <component> element item. The [normalized value] of
this attribute item is the string value of the AnyURIValue in the
Namespace.
If a ContextParameter is present in the RefParameters in the
ATTRIBUTE-REF, ELEMENT-REF, or REF-AS-ELEMENT encoding instruction,
then an attribute item with the [local name] "context" SHALL be added
to the [attributes] of the <attribute>, <element>, or <component>
element item. The [normalized value] of this attribute item is the
string value of the AnyURIValue in the ContextParameter.
If a NamedType is subject to both an ATTRIBUTE encoding instruction
and a VERSION-INDICATOR encoding instruction, then an attribute item
with the [local name] "versionIndicator" and [normalized value]
"true" or "1" SHALL be added to the <attribute> element item. If a
NamedType is subject to an ATTRIBUTE encoding instruction and not
subject to a VERSION-INDICATOR encoding instruction, then an
attribute item with the [local name] "versionIndicator" and
[normalized value] "false" or "0" MAY be added to the <attribute>
element item.
If a NamedType is not subject to an ATTRIBUTE-REF, COMPONENT-REF,
ELEMENT-REF, or REF-AS-ELEMENT encoding instruction, then the
translation of the Type in the NamedType SHALL be added to the
[children] or [attributes] of the <attribute>, <element>,
<component>, <group>, <item>, <member>, or <simpleContent> element
item.
Legg Experimental [Page 35]
RFC 4912 Abstract Syntax Notation X July 2007
If a NamedType is subject to an ATTRIBUTE-REF, COMPONENT-REF,
ELEMENT-REF, or REF-AS-ELEMENT encoding instruction, then the
translation of each EncodingPrefix (Section 6.7) and Tag
(Section 6.7.2) textually within the NamedType SHALL be added in
order to the [children] of the <attribute>, <element>, or <component>
element item.
Example
CHOICE {
one INTEGER,
two [RXER:ATTRIBUTE] BOOLEAN,
three [RXER:ATTRIBUTE-REF
{ namespace-name "http://www.example.com/schema",
local-name "foo" }]
UTF8String,
bar [RXER:ELEMENT-REF
{ namespace-name "http://www.example.com/schema",
local-name "bar" }]
Markup,
five [0] [RXER:REF-AS-ELEMENT "product"
CONTEXT "http://www.example.com/inventory"]
Markup,
six [RXER:GROUP] MySequence
}
<type>
<choice xmlns:ex="http://www.example.com/schema">
<element name="one" type="asnx:INTEGER"/>
<attribute name="two" type="asnx:BOOLEAN"/>
<attribute ref="ex:foo" identifier="three" embedded="true"/>
<element ref="ex:bar" embedded="true"/>
<element elementType="product"
context="http://www.example.com/inventory"
identifier="five">
<TAG number="0"/>
</element>
<group name="six" type="tns:MySequence"/>
</choice>
</type>
6.12.2. SequenceType Translation
The translation of a SequenceType is an element item with the
[local name] "type". An element item with the [local name]
"annotation" MAY be added to the [children] of the <type> element
item. An element item with the [local name] "sequence" SHALL be
appended to the [children] of the <type> element item. The
Legg Experimental [Page 36]
RFC 4912 Abstract Syntax Notation X July 2007
translation of each ComponentType nested in the ComponentTypeList in
the initial RootComponentTypeList, if present, SHALL be appended to
the [children] of the <sequence> element item.
If an ExtensionAndException is present, then an element item with the
[local name] "extension" SHALL be appended to the [children] of the
<sequence> element item. If an ExceptionSpec is present in the
ExtensionAndException, then the translation of the ExceptionSpec
(possibly empty) SHALL be added to the [children] of the <extension>
element item.
If an ExtensionAdditions instance is present, then the translation of
each ExtensionAdditionGroup or ComponentType nested in the
ExtensionAdditions (if any) SHALL be appended to the [children] of
the <extension> element item.
If an ExtensionEndMarker is present, then the translation of each
ComponentType nested in the ComponentTypeList in the final
RootComponentTypeList SHALL be appended to the [children] of the
<sequence> element item.
The translation of an ExtensionAdditionGroup is an element item with
the [local name] "extensionGroup". If the VersionNumber in the
ExtensionAdditionGroup is not empty, then an attribute item with the
[local name] "version" SHALL be added to the [attributes] of the
<extensionGroup> element item. The [normalized value] of this
attribute item is the number in the VersionNumber. The translation
of each ComponentType nested in the ExtensionAdditionGroup SHALL be
appended to the [children] of the <extensionGroup> element item.
The translation of a ComponentType of the "NamedType" form is the
normal translation of the NamedType.
The translation of a ComponentType of the "NamedType OPTIONAL" form
is an element item with the [local name] "optional". The normal
translation of the NamedType SHALL be added to the [children] of the
<optional> element item.
The translation of a ComponentType of the "NamedType DEFAULT Value"
form is an element item with the [local name] "optional". The normal
translation of the NamedType SHALL be added to the [children] of the
<optional> element item. An element item with the [local name]
"default" SHALL be appended to the [children] of the <optional>
element item. The translation of the Value SHALL be added to the
[children] or [attributes] of the <default> element item.
Legg Experimental [Page 37]
RFC 4912 Abstract Syntax Notation X July 2007
The translation of a ComponentType of the "COMPONENTS OF Type" form
is an element item with the [local name] "componentsOf". The
translation of the Type SHALL be added to the [children] or
[attributes] of the <componentsOf> element item.
Example
SEQUENCE {
one INTEGER,
two [RXER:ATTRIBUTE] BOOLEAN OPTIONAL,
...,
[[ 2:
four NULL
]],
COMPONENTS OF MySequence,
...,
three PrintableString DEFAULT "third"
}
<type>
<sequence>
<element name="one" type="asnx:INTEGER"/>
<optional>
<attribute name="two" type="asnx:BOOLEAN"/>
</optional>
<extension>
<extensionGroup version="2">
<element name="four" type="asnx:NULL"/>
</extensionGroup>
<componentsOf type="tns:MySequence"/>
</extension>
<optional>
<element name="three" type="asnx:PrintableString"/>
<default literalValue="third"/>
</optional>
</sequence>
</type>
6.12.3. SetType Translation
The translation of a SetType follows the same procedure as the
translation of a SequenceType except that SetType replaces
SequenceType, "SET" replaces "SEQUENCE", and the [local name] "set"
is used instead of "sequence".
Legg Experimental [Page 38]
RFC 4912 Abstract Syntax Notation X July 2007
6.12.4. ChoiceType Translation
The translation of a ChoiceType that is not subject to a UNION
encoding instruction is an element item with the [local name] "type".
An element item with the [local name] "annotation" MAY be added to
the [children] of the <type> element item. An element item with the
[local name] "choice" SHALL be appended to the [children] of the
<type> element item. The normal translation of each NamedType nested
in the AlternativeTypeList in the RootAlternativeTypeList in the
AlternativeTypeLists SHALL be appended to the [children] of the
<choice> element item.
If an ExtensionAndException is present in the AlternativeTypeLists,
then an element item with the [local name] "extension" SHALL be
appended to the [children] of the <choice> element item. If an
ExceptionSpec is present in the ExtensionAndException, then the
translation of the ExceptionSpec (possibly empty) is added to the
[children] of the <extension> element item.
If an ExtensionAdditionAlternatives instance is present in the
AlternativeTypeLists, then the translation of each
ExtensionAdditionAlternativesGroup or NamedType (if any) nested in
the ExtensionAdditionAlternatives SHALL be appended in order to the
[children] of the <extension> element item. The normal translation
of the NamedType is used.
The translation of an ExtensionAdditionAlternativesGroup is an
element item with the [local name] "extensionGroup". If the
VersionNumber in the ExtensionAdditionAlternativesGroup is not empty,
then an attribute item with the [local name] "version" SHALL be added
to the [attributes] of the <extensionGroup> element item. The
[normalized value] of this attribute item is the number in the
VersionNumber. The normal translation of each NamedType nested in
the AlternativeTypeList in the ExtensionAdditionAlternativesGroup
SHALL be appended to the [children] of the <extensionGroup> element
item.
Legg Experimental [Page 39]
RFC 4912 Abstract Syntax Notation X July 2007
Example
CHOICE {
one INTEGER,
two [RXER:NAME AS "Two"] BOOLEAN,
...,
[[ 2:
three NULL
]],
four PrintableString,
...
}
<type>
<choice>
<element name="one" type="asnx:INTEGER"/>
<element name="Two" type="asnx:BOOLEAN"/>
<extension>
<extensionGroup version="2">
<element name="three" type="asnx:NULL"/>
</extensionGroup>
<element name="four" type="asnx:PrintableString"/>
</extension>
</choice>
</type>
6.12.5. Translation of UNION Types
The translation of a ChoiceType that is subject to a UNION encoding
instruction follows the same procedure as the translation of a
ChoiceType that is not subject to a UNION encoding instruction except
that the [local name] "union" is used instead of "choice", and the
member translation of each NamedType is used instead of the normal
translation.
In addition, if the UNION encoding instruction has a PrecedenceList,
then an attribute item with the [local name] "precedence" SHALL be
added to the [attributes] of the <union> element item. The
[normalized value] of this attribute item is the white space
separated list of qualified names for the expanded names of the
NamedType instances [RXEREI] corresponding to the identifiers in the
PrecedenceList. A white space separator is one or more of the white
space characters.
Legg Experimental [Page 40]
RFC 4912 Abstract Syntax Notation X July 2007
Example
[RXER:UNION PRECEDENCE utf8 visible] CHOICE {
printable PrintableString,
teletex TeletexString,
visible [RXER:NAME AS "ascii"] VisibleString,
...,
utf8 UTF8String
}
<type>
<union precedence="utf8 ascii">
<member name="printable" type="asnx:PrintableString"/>
<member name="teletex" type="asnx:TeletexString"/>
<member name="ascii" identifier="visible"
type="asnx:VisibleString"/>
<extension>
<member name="utf8" type="asnx:UTF8String"/>
</extension>
</union>
</type>
6.12.6. SequenceOfType Translation
The translation of a SequenceOfType that is not subject to a LIST
encoding instruction is an element item with the [local name] "type".
An element item with the [local name] "annotation" MAY be added to
the [children] of the <type> element item. An element item with the
[local name] "sequenceOf" SHALL be appended to the [children] of the
<type> element item.
If the SequenceOfType is of the "SEQUENCE OF NamedType" form, then
the normal translation of the NamedType SHALL be added to the
[children] of the <sequenceOf> element item.
If the SequenceOfType is of the "SEQUENCE OF Type" form, then an
element item with the [local name] "element" or "component"
(translator's choice) SHALL be added to the [children] of the
<sequenceOf> element item. An attribute item with the [local name]
"name" and [normalized value] "item" SHALL be added to the
[attributes] of the <element> or <component> element item. An
attribute item with the [local name] "identifier" and empty
[normalized value] SHALL be added to the [attributes] of the
<element> or <component> element item. The translation of the Type
SHALL be added to the [children] or [attributes] of the <element> or
<component> element item.
Legg Experimental [Page 41]
RFC 4912 Abstract Syntax Notation X July 2007
Examples
SEQUENCE OF INTEGER
<type>
<sequenceOf>
<element name="item" identifier="" type="asnx:INTEGER"/>
</sequenceOf>
</type>
SEQUENCE OF counter INTEGER
<type>
<sequenceOf>
<element name="counter" type="asnx:INTEGER"/>
</sequenceOf>
</type>
6.12.7. Translation of LIST Types
The translation of a SequenceOfType that is subject to a LIST
encoding instruction is an element item with the [local name] "type".
An element item with the [local name] "annotation" MAY be added to
the [children] of the <type> element item. An element item with the
[local name] "list" SHALL be appended to the [children] of the <type>
element item. The item translation of the NamedType in the
SequenceOfType SHALL be added to the [children] of the <list> element
item.
Aside: A SequenceOfType is necessarily of the
"SEQUENCE OF NamedType" form for a LIST encoding instruction.
Example
[RXER:LIST] SEQUENCE OF number INTEGER
<type>
<list>
<item name="number" type="asnx:INTEGER"/>
</list>
</type>
6.12.8. SetOfType Translation
The translation of a SetOfType follows the same procedure as the
translation of a SequenceOfType except that SetOfType replaces
SequenceOfType, "SET" replaces "SEQUENCE", and the [local name]
"setOf" is used instead of "sequenceOf".
Legg Experimental [Page 42]
RFC 4912 Abstract Syntax Notation X July 2007
6.12.9. Effect of Insertion Encoding Instructions
If a Type is subject to a NO-INSERTIONS, HOLLOW-INSERTIONS,
SINGULAR-INSERTIONS, UNIFORM-INSERTIONS, or MULTIFORM-INSERTIONS
encoding instruction, then an attribute item with the [local name]
"insertions" SHALL be added to the [attributes] of the <choice>,
<sequence> or <set> element item in the [children] of the <type>
element item resulting from the translation of the Type. The
[normalized value] of this attribute item is "none" in the case of a
NO-INSERTIONS encoding instruction, "hollow" in the case of a
HOLLOW-INSERTIONS encoding instruction, "singular" in the case of a
SINGULAR-INSERTIONS encoding instruction, "uniform" in the case of a
UNIFORM-INSERTIONS encoding instruction, and "multiform" in the case
of a MULTIFORM-INSERTIONS encoding instruction.
Example
[NO-INSERTIONS] CHOICE {
one [RXER:GROUP] [RXER:SINGULAR-INSERTIONS] CHOICE {
two INTEGER,
...
},
...
}
<type>
<choice insertions="none">
<group name="one">
<type>
<choice insertions="singular">
<element name="two" type="asnx:INTEGER"/>
<extension/>
</choice>
</type>
</group>
<extension/>
</choice>
</type>
6.13. Translation of Constrained Types
If a ConstrainedType is of the "Type Constraint" form, then the
translation of the ConstrainedType is an element item with the
[local name] "type". An element item with the [local name]
"annotation" MAY be added to the [children] of the <type> element
item. An element item with the [local name] "constrained" SHALL be
appended to the [children] of the <type> element item. The
translation of the Type SHALL be added to the [children] or
Legg Experimental [Page 43]
RFC 4912 Abstract Syntax Notation X July 2007
[attributes] of the <constrained> element item. The translation of
the Constraint SHALL be added to the [children] of the <constrained>
element item.
The translation of a ContainedType that is a TypeWithConstraint is
the translation of the TypeWithConstraint.
Definition (simple endpoint): A LowerEndpoint or UpperEndpoint is a
simple endpoint if it is closed and its value is "MIN", "MAX", or a
SignedNumber in an IntegerValue in a BuiltinValue in the Value of the
endpoint.
Definition (simple range SizeConstraint): A SizeConstraint is a
simple range if the Constraint in the SizeConstraint contains only a
ValueRange (i.e., a ValueRange in a SubtypeElements instance in an
Elements instance in a lone IntersectionElements instance in a lone
Intersections instance in a Unions instance in an ElementSetSpec in a
RootElementSetSpec in an ElementSetSpecs instance without an
AdditionalElementSetSpec in a SubtypeConstraint in a ConstraintSpec
in the Constraint) and both endpoints are simple.
Definition (simple range Constraint): A Constraint is a simple range
if contains only a SizeConstraint that is a simple range (i.e., a
simple range SizeConstraint in a SubtypeElements instance in an
Elements instance in a lone IntersectionElements instance in a lone
Intersections instance in a Unions instance in an ElementSetSpec in a
RootElementSetSpec in an ElementSetSpecs instance without an
AdditionalElementSetSpec in a SubtypeConstraint in a ConstraintSpec
in the Constraint).
If the Constraint or SizeConstraint in a TypeWithConstraint is a
simple range, then the compact translation of the TypeWithConstraint
MAY be used; otherwise, the full translation of the
TypeWithConstraint is used.
The compact translation of a TypeWithConstraint is initially the
translation of its notional parent type. If the value of the lower
endpoint is not "MIN" or "0", then an attribute item with the
[local name] "minSize" SHALL be added to the [attributes] of the
<sequenceOf>, <setOf>, or <list> element item resulting from the
translation of the parent type. The [normalized value] of this
attribute item is the value of the lower endpoint. If the value of
the lower endpoint is "MIN" or "0", then an attribute item with the
[local name] "minSize" and [normalized value] "0" MAY be added to the
[attributes] of the <sequenceOf>, <setOf>, or <list> element item.
If the value of the upper endpoint is not "MAX", then an attribute
item with the [local name] "maxSize" SHALL be added to the
[attributes] of the <sequenceOf>, <setOf>, or <list> element item.
Legg Experimental [Page 44]
RFC 4912 Abstract Syntax Notation X July 2007
The [normalized value] of this attribute item is the value of the
upper endpoint.
The full translation of a TypeWithConstraint is an element item with
the [local name] "type". An element item with the [local name]
"annotation" MAY be added to the [children] of the <type> element
item. An element item with the [local name] "constrained" SHALL be
appended to the [children] of the <type> element item. The
translation of the notional parent type of the TypeWithConstraint
SHALL be added to the [children] or [attributes] of the <constrained>
element item. The translation of the Constraint or SizeConstraint in
the TypeWithConstraint SHALL be added to the [children] of the
<constrained> element item.
Examples
SEQUENCE (SIZE(1..MAX)) OF number INTEGER
<type>
<sequenceOf minSize="1">
<element name="number" type="asnx:INTEGER"/>
</sequenceOf>
</type>
SEQUENCE SIZE(0..10) OF number INTEGER
<type>
<sequenceOf maxSize="10">
<element name="number" type="asnx:INTEGER"/>
</sequenceOf>
</type>
SEQUENCE SIZE(1..limit) OF number INTEGER
<type>
<constrained>
<type>
<sequenceOf>
<element name="number" type="asnx:INTEGER"/>
</sequenceOf>
</type>
<size>
<range>
<minInclusive literalValue="1"/>
<maxInclusive value="tns:limit"/>
</range>
Legg Experimental [Page 45]
RFC 4912 Abstract Syntax Notation X July 2007
</size>
</constrained>
</type>
6.13.1. Constraint Translation
The translation of a Constraint is the translation of the
ConstraintSpec in the Constraint followed by the translation of the
ExceptionSpec (possibly empty) in the Constraint.
The translation of a ConstraintSpec is the translation of the
SubtypeConstraint or GeneralConstraint in the ConstraintSpec.
The translation of a SubtypeConstraint is the translation of the
ElementSetSpecs in the SubtypeConstraint.
The translation of a GeneralConstraint [X.682] is the translation of
the UserDefinedConstraint, TableConstraint, or ContentsConstraint in
the GeneralConstraint.
6.13.2. UserDefinedConstraint Translation
The translation of a UserDefinedConstraint is an element item with
the [local name] "constrainedBy". An element item with the
[local name] "annotation" MAY be added to the [children] of the
<constrainedBy> element item. The translation of each
UserDefinedConstraintParameter in the UserDefinedConstraint SHALL be
appended to the [children] of the <constrainedBy> element item.
The translation of a UserDefinedConstraintParameter of the
"Governor : Value" form is an element item with the [local name]
"valueParameter". The translation of the Type in the Governor SHALL
be added to the [children] or [attributes] of the <valueParameter>
element item. The translation of the Value SHALL be added to the
[children] or [attributes] of the <valueParameter> element item.
The translation of a UserDefinedConstraintParameter of the
"Governor : ValueSet" form is an element item with the [local name]
"valueSetParameter". The translation of the Type in the Governor
SHALL be added to the [children] or [attributes] of the
<valueSetParameter> element item. The translation of the ValueSet
SHALL be added to the [children] of the <valueSetParameter> element
item.
The translation of a UserDefinedConstraintParameter of the
"Governor : Object" form is an element item with the [local name]
"objectParameter". The translation of the DefinedObjectClass in the
Governor SHALL be added to the [children] or [attributes] of the
Legg Experimental [Page 46]
RFC 4912 Abstract Syntax Notation X July 2007
<objectParameter> element item. The translation of the Object SHALL
be added to the [children] or [attributes] of the <objectParameter>
element item.
The translation of a UserDefinedConstraintParameter of the
"Governor : ObjectSet" form is an element item with the [local name]
"objectSetParameter". The translation of the DefinedObjectClass in
the Governor SHALL be added to the [children] or [attributes] of the
<objectSetParameter> element item. The translation of the ObjectSet
SHALL be added to the [children] or [attributes] of the
<objectSetParameter> element item.
The translation of a UserDefinedConstraintParameter that is a Type is
an element item with the [local name] "typeParameter". The
translation of the Type SHALL be added to the [children] or
[attributes] of the <typeParameter> element item.
The translation of a UserDefinedConstraintParameter that is a
DefinedObjectClass is an element item with the [local name]
"classParameter". The translation of the DefinedObjectClass SHALL be
added to the [children] or [attributes] of the <classParameter>
element item.
Example
OCTET STRING
(CONSTRAINED BY {
-- contains the hash of the value -- MyType:myValue })
<type>
<constrained type="asnx:OCTET-STRING">
<constrainedBy>
<annotation> contains the hash of the value </annotation>
<valueParameter type="tns:MyType" value="tns:myValue"/>
</constrainedBy>
</constrained>
</type>
6.13.3. TableConstraint Translation
The translation of a TableConstraint that is a SimpleTableConstraint
is an element item with the [local name] "table". The translation of
the ObjectSet in the SimpleTableConstraint SHALL be added to the
[children] or [attributes] of the <table> element item.
The translation of a TableConstraint that is a
ComponentRelationConstraint is an element item with the [local name]
"table". The translation of the DefinedObjectSet in the
Legg Experimental [Page 47]
