tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 4911

 
 
 

Encoding Instructions for the Robust XML Encoding Rules (RXER)

Part 2 of 4, p. 20 to 56
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 20 
15.  The REF-AS-TYPE Encoding Instruction

   The REF-AS-TYPE encoding instruction causes values of the Markup
   ASN.1 type to be restricted to conform to the content and attributes
   permitted by a nominated element type declaration and its associated
   attribute-list declarations in an external DTD subset.

Top      Up      ToC       Page 21 
   The notation for a REF-AS-TYPE encoding instruction is defined as
   follows:

      RefAsTypeInstruction ::= "REF-AS-TYPE" NameValue RefParameters

   Taken together, the NameValue and the ContextParameter of the
   RefParameters (if present) MUST reference an element type declaration
   in an external DTD subset that is conformant with Namespaces in XML
   1.0 [XMLNS10].

   The referenced element type declaration MUST NOT require the presence
   of attributes of type ENTITY or ENTITIES.

      Aside: Entity declarations are not supported by CRXER.

   Example

      The product element type declaration can be referenced as a type
      in an ASN.1 definition:

         SEQUENCE OF
             inventoryItem
                 [REF-AS-TYPE "product"
                     CONTEXT "http://www.example.com/inventory"]
                 Markup

      Here is the ASN.X translation of this definition:

         <sequenceOf>
          <element name="inventoryItem">
           <type elementType="product"
                 context="http://www.example.com/inventory"/>
          </element>
         </sequenceOf>

      Note that when an element type declaration is referenced as a
      type, the Name of the element type declaration does not contribute
      to RXER encodings.  For example, child elements in the RXER
      encoding of values of the above SEQUENCE OF type would resemble
      the following:

         <inventoryItem name="hammer" partNumber="1543" quantity="29"/>

Top      Up      ToC       Page 22 
16.  The SCHEMA-IDENTITY Encoding Instruction

   The SCHEMA-IDENTITY encoding instruction associates a unique
   identifier, a URI [URI], with the ASN.1 module containing the
   encoding instruction.  This encoding instruction has no effect on an
   RXER encoder but does have an effect on the translation of an ASN.1
   specification into an ASN.X representation.

   The notation for a SCHEMA-IDENTITY encoding instruction is defined as
   follows:

      SchemaIdentityInstruction ::= "SCHEMA-IDENTITY" AnyURIValue

   The character string specified by the AnyURIValue of each
   SCHEMA-IDENTITY encoding instruction MUST be distinct.  In
   particular, successive versions of an ASN.1 module must each have a
   different schema identity URI value.

17.  The SIMPLE-CONTENT Encoding Instruction

   The SIMPLE-CONTENT encoding instruction causes an RXER encoder to
   encode a value of a component of a SEQUENCE or SET type without
   encapsulation in a child element.

   The notation for a SIMPLE-CONTENT encoding instruction is defined as
   follows:

      SimpleContentInstruction ::= "SIMPLE-CONTENT"

   A NamedType subject to a SIMPLE-CONTENT encoding instruction SHALL be
   in a ComponentType in a ComponentTypeList in a RootComponentTypeList.
   At most one such NamedType of a SEQUENCE or SET type is permitted to
   be subject to a SIMPLE-CONTENT encoding instruction.  If any
   component is subject to a SIMPLE-CONTENT encoding instruction, then
   all other components in the same SEQUENCE or SET type definition MUST
   be attribute components.  These tests are applied after the
   COMPONENTS OF transformation specified in X.680, Clause 24.4 [X.680].

      Aside: Child elements and simple content are mutually exclusive.
      Specification writers should note that use of the SIMPLE-CONTENT
      encoding instruction on a component of an extensible SEQUENCE or
      SET type means that all future extensions to the SEQUENCE or SET
      type are restricted to being attribute components with the limited
      set of types that are permitted for attribute components.  Using
      an ATTRIBUTE encoding instruction instead of a SIMPLE-CONTENT
      encoding instruction avoids this limitation.

Top      Up      ToC       Page 23 
   The base type of the type of a NamedType that is subject to a
   SIMPLE-CONTENT encoding instruction SHALL NOT be:

   (1) a SET or SET OF type, or

   (2) a CHOICE type where the ChoiceType is not subject to a UNION
       encoding instruction, or

   (3) a SEQUENCE type other than the one defining the QName type from
       the AdditionalBasicDefinitions module [RXER] (i.e., QName is
       allowed), or

   (4) a SEQUENCE OF type where the SequenceOfType is not subject to a
       LIST encoding instruction, or

   (5) an open type.

   If the type of a NamedType subject to a SIMPLE-CONTENT encoding
   instruction has abstract values with an empty character data
   translation [RXER] (i.e., an empty encoding), then the NamedType
   SHALL NOT be marked OPTIONAL or DEFAULT.

   Example

      SEQUENCE {
          units   [ATTRIBUTE] UTF8String,
          amount  [SIMPLE-CONTENT] INTEGER
      }

18.  The TARGET-NAMESPACE Encoding Instruction

   The TARGET-NAMESPACE encoding instruction associates an XML namespace
   name [XMLNS10], a URI [URI], with the type, object class, value,
   object, and object set references defined in the ASN.1 module
   containing the encoding instruction.  In addition, it associates the
   namespace name with each top-level NamedType in the RXER encoding
   control section.

   The notation for a TARGET-NAMESPACE encoding instruction is defined
   as follows:

      TargetNamespaceInstruction ::=
          "TARGET-NAMESPACE" AnyURIValue Prefix ?

      Prefix ::= "PREFIX" NCNameValue

   The AnyURIValue SHALL NOT specify an empty string.

Top      Up      ToC       Page 24 
   Definition (target namespace):  If an ASN.1 module contains a
   TARGET-NAMESPACE encoding instruction, then the target namespace of
   the module is the character string specified by the AnyURIValue of
   the TARGET-NAMESPACE encoding instruction; otherwise, the target
   namespace of the module is said to be absent.

   Two or more ASN.1 modules MAY have the same non-absent target
   namespace if and only if the expanded names of the top-level
   attribute components are distinct across all those modules, the
   expanded names of the top-level element components are distinct
   across all those modules, and the defined type, object class, value,
   object, and object set references are distinct in their category
   across all those modules.

   The Prefix, if present, suggests an NCName to use as the namespace
   prefix in namespace declarations involving the target namespace.  An
   RXER encoder is not obligated to use the nominated namespace prefix.

   If there are no top-level components, then the RXER encodings
   produced using a module with a TARGET-NAMESPACE encoding instruction
   are backward compatible with the RXER encodings produced by the same
   module without the TARGET-NAMESPACE encoding instruction.

19.  The TYPE-AS-VERSION Encoding Instruction

   The TYPE-AS-VERSION encoding instruction causes an RXER encoder to
   include an xsi:type attribute in the encoding of a value of the
   component to which the encoding instruction is applied.  This
   attribute allows an XML Schema [XSD1] validator to select, if
   available, the appropriate XML Schema translation for the version of
   the ASN.1 specification used to create the encoding.

      Aside: Translations of an ASN.1 specification into a compatible
      XML Schema are expected to be slightly different across versions
      because of progressive extensions to the ASN.1 specification.  Any
      incompatibilities between these translations can be accommodated
      if each version uses a different target namespace.  The target
      namespace will be evident in the value of the xsi:type attribute
      and will cause an XML Schema validator to use the appropriate
      version.  This mechanism also accommodates an ASN.1 type that is
      renamed in a later version of the ASN.1 specification.

   The notation for a TYPE-AS-VERSION encoding instruction is defined as
   follows:

      TypeAsVersionInstruction ::= "TYPE-AS-VERSION"

Top      Up      ToC       Page 25 
   The Type in a NamedType that is subject to a TYPE-AS-VERSION encoding
   instruction MUST be a namespace-qualified reference [RXER].

   The addition of a TYPE-AS-VERSION encoding instruction does not
   affect the backward compatibility of RXER encodings.

      Aside: In a translation of an ASN.1 specification into XML Schema,
      any Type in a NamedType that is subject to a TYPE-AS-VERSION
      encoding instruction is expected to be translated into the
      XML Schema anyType so that the xsi:type attribute acts as a switch
      to select the appropriate version.

20.  The TYPE-REF Encoding Instruction

   The TYPE-REF encoding instruction causes values of the Markup ASN.1
   type to be restricted to conform to a specific XML Schema named type,
   RELAX NG named pattern or an ASN.1 defined type.

      Aside: Referencing an ASN.1 type in a TYPE-REF encoding
      instruction does not have the effect of imposing a requirement to
      preserve the Infoset [INFOSET] representation of the RXER encoding
      of an abstract value of the type.  It is still sufficient to
      preserve just the abstract value.

   The notation for a TYPE-REF encoding instruction is defined as
   follows:

      TypeRefInstruction ::= "TYPE-REF" QNameValue RefParameters

   Taken together, the QNameValue and the ContextParameter of the
   RefParameters (if present) MUST reference an XML Schema named type, a
   RELAX NG named pattern, or an ASN.1 defined type.

   A referenced XML Schema type MUST NOT require the presence of values
   for the XML Schema ENTITY or ENTITIES types.

      Aside: Entity declarations are not supported by CRXER.

   The QNameValue SHALL NOT be a direct reference to the XML Schema
   NOTATION type [XSD2] (i.e., the namespace name
   "http://www.w3.org/2001/XMLSchema" and local name "NOTATION");
   however, a reference to an XML Schema type derived from the NOTATION
   type is permitted.

      Aside: This restriction is to ensure that the lexical space [XSD2]
      of the referenced type is actually populated with the names of
      notations [XSD1].

Top      Up      ToC       Page 26 
   Example

      MyDecimal ::=
          [TYPE-REF {
              namespace-name "http://www.w3.org/2001/XMLSchema",
              local-name     "decimal" }]
          Markup

      Note that the ASN.X translation of this ASN.1 type definition
      provides a more natural way to reference the XML Schema decimal
      type:

         <namedType xmlns:xs="http://www.w3.org/2001/XMLSchema"
                    name="MyDecimal">
          <type ref="xs:decimal" embedded="true"/>
         </namedType>

21.  The UNION Encoding Instruction

   The UNION encoding instruction causes an RXER encoder to encode the
   value of an alternative of a CHOICE type without encapsulation in a
   child element.  The chosen alternative is optionally indicated with a
   member attribute.  The optional PrecedenceList also allows a
   specification writer to alter the order in which an RXER decoder will
   consider the alternatives of the CHOICE as it determines which
   alternative has been used (if the actual alternative has not been
   specified through the member attribute).

   The notation for a UNION encoding instruction is defined as follows:

      UnionInstruction ::= "UNION" AlternativesPrecedence ?

      AlternativesPrecedence ::= "PRECEDENCE" PrecedenceList

      PrecedenceList ::= identifier PrecedenceList ?

   The Type in the EncodingPrefixedType for a UNION encoding instruction
   SHALL be either:

   (1) a BuiltinType that is a ChoiceType, or

   (2) a ConstrainedType that is not a TypeWithConstraint where the Type
       in the ConstrainedType is one of (1) to (4), or

   (3) a BuiltinType that is a PrefixedType that is a TaggedType where
       the Type in the TaggedType is one of (1) to (4), or

Top      Up      ToC       Page 27 
   (4) a BuiltinType that is a PrefixedType that is an
       EncodingPrefixedType where the Type in the EncodingPrefixedType
       is one of (1) to (4).

   The ChoiceType in case (1) is said to be "subject to" the UNION
   encoding instruction.

   The base type of the type of each alternative of a ChoiceType that is
   subject to a UNION encoding instruction SHALL NOT be:

   (1) a CHOICE, SET, or SET OF type, or

   (2) a SEQUENCE type other than the one defining the QName type from
       the AdditionalBasicDefinitions module [RXER] (i.e., QName is
       allowed), or

   (3) a SEQUENCE OF type where the SequenceOfType is not subject to a
       LIST encoding instruction, or

   (4) an open type.

   Each identifier in the PrecedenceList MUST be the identifier of a
   NamedType in the ChoiceType.

   A particular identifier SHALL NOT appear more than once in the same
   PrecedenceList.

   Every NamedType in a ChoiceType that is subject to a UNION encoding
   instruction MUST NOT be subject to an ATTRIBUTE, ATTRIBUTE-REF,
   COMPONENT-REF, GROUP, ELEMENT-REF, REF-AS-ELEMENT, SIMPLE-CONTENT, or
   TYPE-AS-VERSION encoding instruction.

   Example

      [UNION PRECEDENCE basicName] CHOICE {
          extendedName  UTF8String,
          basicName     PrintableString
      }

22.  The VALUES Encoding Instruction

   The VALUES encoding instruction causes an RXER encoder to use
   nominated names instead of the identifiers that would otherwise
   appear in the encoding of a value of a BIT STRING, ENUMERATED, or
   INTEGER type.

Top      Up      ToC       Page 28 
   The notation for a VALUES encoding instruction is defined as follows:

      ValuesInstruction ::=
          "VALUES" AllValuesMapped ? ValueMappingList ?

      AllValuesMapped ::= AllCapitalized | AllUppercased

      AllCapitalized ::= "ALL" "CAPITALIZED"

      AllUppercased ::= "ALL" "UPPERCASED"

      ValueMappingList ::= ValueMapping ValueMappingList ?

      ValueMapping ::= "," identifier "AS" NCNameValue

   The Type in the EncodingPrefixedType for a VALUES encoding
   instruction SHALL be either:

   (1) a BuiltinType that is a BitStringType with a NamedBitList, or

   (2) a BuiltinType that is an EnumeratedType, or

   (3) a BuiltinType that is an IntegerType with a NamedNumberList, or

   (4) a ConstrainedType that is not a TypeWithConstraint where the Type
       in the ConstrainedType is one of (1) to (6), or

   (5) a BuiltinType that is a PrefixedType that is a TaggedType where
       the Type in the TaggedType is one of (1) to (6), or

   (6) a BuiltinType that is a PrefixedType that is an
       EncodingPrefixedType where the Type in the EncodingPrefixedType
       is one of (1) to (6).

   The effect of this condition is to force the VALUES encoding
   instruction to be textually co-located with the type definition to
   which it applies.

   The BitStringType, EnumeratedType, or IntegerType in case (1), (2),
   or (3), respectively, is said to be "subject to" the VALUES encoding
   instruction.

   A BitStringType, EnumeratedType, or IntegerType SHALL NOT be subject
   to more than one VALUES encoding instruction.

   Each identifier in a ValueMapping MUST be an identifier appearing in
   the NamedBitList, Enumerations, or NamedNumberList, as the case may
   be.

Top      Up      ToC       Page 29 
   The identifier in a ValueMapping SHALL NOT be the same as the
   identifier in any other ValueMapping for the same ValueMappingList.

   Definition (replacement name):  Each identifier in a BitStringType,
   EnumeratedType, or IntegerType subject to a VALUES encoding
   instruction has a replacement name.  If there is a ValueMapping for
   the identifier, then the replacement name is the character string
   specified by the NCNameValue in the ValueMapping; else if
   AllCapitalized is used, then the replacement name is the identifier
   with the first character uppercased; else if AllUppercased is used,
   then the replacement name is the identifier with all its characters
   uppercased; otherwise, the replacement name is the identifier.

   The replacement names for the identifiers in a BitStringType subject
   to a VALUES encoding instruction MUST be distinct.

   The replacement names for the identifiers in an EnumeratedType
   subject to a VALUES encoding instruction MUST be distinct.

   The replacement names for the identifiers in an IntegerType subject
   to a VALUES encoding instruction MUST be distinct.

   Example

      Traffic-Light ::= [VALUES ALL CAPITALIZED, red AS "RED"]
          ENUMERATED {
              red,    -- Replacement name is RED.
              amber,  -- Replacement name is Amber.
              green   -- Replacement name is Green.
          }

23.  Insertion Encoding Instructions

   Certain of the RXER encoding instructions are categorized as
   insertion encoding instructions.  The insertion encoding instructions
   are the NO-INSERTIONS, HOLLOW-INSERTIONS, SINGULAR-INSERTIONS,
   UNIFORM-INSERTIONS, and MULTIFORM-INSERTIONS encoding instructions
   (whose notations are described respectively by
   NoInsertionsInstruction, HollowInsertionsInstruction,
   SingularInsertionsInstruction, UniformInsertionsInstruction, and
   MultiformInsertionsInstruction).

   The notation for the insertion encoding instructions is defined as
   follows:

Top      Up      ToC       Page 30 
      InsertionsInstruction ::=
          NoInsertionsInstruction |
          HollowInsertionsInstruction |
          SingularInsertionsInstruction |
          UniformInsertionsInstruction |
          MultiformInsertionsInstruction

      NoInsertionsInstruction ::= "NO-INSERTIONS"

      HollowInsertionsInstruction ::= "HOLLOW-INSERTIONS"

      SingularInsertionsInstruction ::= "SINGULAR-INSERTIONS"

      UniformInsertionsInstruction ::= "UNIFORM-INSERTIONS"

      MultiformInsertionsInstruction ::= "MULTIFORM-INSERTIONS"

   Using the GROUP encoding instruction on components with extensible
   types can lead to situations where an unknown extension could be
   associated with more than one extension insertion point.  The
   insertion encoding instructions remove this ambiguity by limiting the
   form that extensions can take.  That is, the insertion encoding
   instructions indicate what extensions can be made to an ASN.1
   specification without breaking forward compatibility for RXER
   encodings.

      Aside: Forward compatibility means the ability for a decoder to
      successfully decode an encoding containing extensions introduced
      into a version of the specification that is more recent than the
      one used by the decoder.

   In the most general case, an extension to a CHOICE, SET, or SEQUENCE
   type will generate zero or more attributes and zero or more elements,
   due to the potential use of the GROUP and ATTRIBUTE encoding
   instructions by the extension.

   The MULTIFORM-INSERTIONS encoding instruction indicates that the RXER
   encodings produced by forward-compatible extensions to a type will
   always consist of one or more elements and zero or more attributes.
   No restriction is placed on the names of the elements.

      Aside: Of necessity, the names of the attributes will all be
      different in any given encoding.

   The UNIFORM-INSERTIONS encoding instruction indicates that the RXER
   encodings produced by forward-compatible extensions to a type will
   always consist of one or more elements having the same expanded name,
   and zero or more attributes.  The expanded name shared by the

Top      Up      ToC       Page 31 
   elements in one particular encoding is not required to be the same as
   the expanded name shared by the elements in any other encoding of the
   extension.  For example, in one encoding of the extension the
   elements might all be called "foo", while in another encoding of the
   extension they might all be called "bar".

   The SINGULAR-INSERTIONS encoding instruction indicates that the RXER
   encodings produced by forward-compatible extensions to a type will
   always consist of a single element and zero or more attributes.  The
   name of the single element is not required to be the same in every
   possible encoding of the extension.

   The HOLLOW-INSERTIONS encoding instruction indicates that the RXER
   encodings produced by forward-compatible extensions to a type will
   always consist of zero elements and zero or more attributes.

   The NO-INSERTIONS encoding instruction indicates that no forward-
   compatible extensions can be made to a type.

   Examples of forward-compatible extensions are provided in Appendix C.

   The Type in the EncodingPrefixedType for an insertion encoding
   instruction SHALL be either:

   (1) a BuiltinType that is a ChoiceType where the ChoiceType is not
       subject to a UNION encoding instruction, or

   (2) a BuiltinType that is a SequenceType or SetType, or

   (3) a ConstrainedType that is not a TypeWithConstraint where the Type
       in the ConstrainedType is one of (1) to (5), or

   (4) a BuiltinType that is a PrefixedType that is a TaggedType where
       the Type in the TaggedType is one of (1) to (5), or

   (5) a BuiltinType that is a PrefixedType that is an
       EncodingPrefixedType where the Type in the EncodingPrefixedType
       is one of (1) to (5).

   Case (2) is not permitted when the insertion encoding instruction is
   the SINGULAR-INSERTIONS, UNIFORM-INSERTIONS, or MULTIFORM-INSERTIONS
   encoding instruction.

Top      Up      ToC       Page 32 
      Aside: Because extensions to a SET or SEQUENCE type are serial and
      effectively optional, the SINGULAR-INSERTIONS, UNIFORM-INSERTIONS,
      and MULTIFORM-INSERTIONS encoding instructions offer no advantage
      over unrestricted extensions (for a SET or SEQUENCE).  For
      example, an optional series of singular insertions generates zero
      or more elements and zero or more attributes, just like an
      unrestricted extension.

   The Type in case (1) or case (2) is said to be "subject to" the
   insertion encoding instruction.

   The Type in case (1) or case (2) MUST be extensible, either
   explicitly or by default.

   A Type SHALL NOT be subject to more than one insertion encoding
   instruction.

   The insertion encoding instructions indicate what kinds of extensions
   can be made to a type without breaking forward compatibility, but
   they do not prohibit extensions that do break forward compatibility.
   That is, it is not an error for a type's base type to contain
   extensions that do not satisfy an insertion encoding instruction
   affecting the type.  However, if any such extensions are made, then a
   new value SHOULD be introduced into the extensible set of permitted
   values for a version indicator attribute, or attributes (see
   Section 24), whose scope encompasses the extensions.  An example is
   provided in Appendix C.

24.  The VERSION-INDICATOR Encoding Instruction

   The VERSION-INDICATOR encoding instruction provides a mechanism for
   RXER decoders to be alerted that an encoding contains extensions that
   break forward compatibility (see the preceding section).

   The notation for a VERSION-INDICATOR encoding instruction is defined
   as follows:

      VersionIndicatorInstruction ::= "VERSION-INDICATOR"

   A NamedType that is subject to a VERSION-INDICATOR encoding
   instruction MUST also be subject to an ATTRIBUTE encoding
   instruction.

   The type of the NamedType that is subject to the VERSION-INDICATOR
   encoding instruction MUST be directly or indirectly a constrained
   type where the set of permitted values is defined to be extensible.
   Each value represents a different version of the ASN.1 specification.
   Ordinarily, an application will set the value of a version indicator

Top      Up      ToC       Page 33 
   attribute to be the last of these permitted values.  An application
   MAY set the value of the version indicator attribute to the value
   corresponding to an earlier version of the specification if it has
   not used any of the extensions added in a subsequent version.

   If an RXER decoder encounters a value of the type that is not one of
   the root values or extension additions (but that is still allowed
   since the set of permitted values is extensible), then this indicates
   that the decoder is using a version of the ASN.1 specification that
   is not compatible with the version used to produce the encoding.  In
   such cases, the decoder SHOULD treat the element containing the
   attribute as having an unknown ASN.1 type.

      Aside: A version indicator attribute only indicates an
      incompatibility with respect to RXER encodings.  Other encodings
      are not affected because the GROUP encoding instruction does not
      apply to them.

   Examples

      In this first example, the decoder is using an incompatible older
      version if the value of the version attribute in a received RXER
      encoding is not 1, 2, or 3.

         SEQUENCE {
             version  [ATTRIBUTE] [VERSION-INDICATOR]
                          INTEGER (1, ..., 2..3),
             message  MessageType
         }

      In this second example, the decoder is using an incompatible older
      version if the value of the format attribute in a received RXER
      encoding is not "1.0", "1.1", or "2.0".

         SEQUENCE {
             format   [ATTRIBUTE] [VERSION-INDICATOR]
                          UTF8String ("1.0", ..., "1.1" | "2.0"),
             message  MessageType
         }

      An extensive example is provided in Appendix C.

   It is not necessary for every extensible type to have its own version
   indicator attribute.  It would be typical for only the types of
   top-level element components to include a version indicator
   attribute, which would serve as the version indicator for all of the
   nested components.

Top      Up      ToC       Page 34 
25.  The GROUP Encoding Instruction

   The GROUP encoding instruction causes an RXER encoder to encode a
   value of the component to which it is applied without encapsulation
   as an element.  It allows the construction of non-trivial content
   models for element content.

   The notation for a GROUP encoding instruction is defined as follows:

      GroupInstruction ::= "GROUP"

   The base type of the type of a NamedType that is subject to a GROUP
   encoding instruction SHALL be either:

   (1) a SEQUENCE, SET, or SET OF type, or

   (2) a CHOICE type where the ChoiceType is not subject to a UNION
       encoding instruction, or

   (3) a SEQUENCE OF type where the SequenceOfType is not subject to a
       LIST encoding instruction.

   The SEQUENCE type in case (1) SHALL NOT be the associated type for a
   built-in type, SHALL NOT be a type from the
   AdditionalBasicDefinitions module [RXER], and SHALL NOT contain a
   component that is subject to a SIMPLE-CONTENT encoding instruction.

      Aside: Thus, the CHARACTER STRING, EMBEDDED PDV, EXTERNAL, REAL,
      and QName types are excluded.

   The CHOICE type in case (2) SHALL NOT be a type from the
   AdditionalBasicDefinitions module.

      Aside: Thus, the Markup type is excluded.

   Definition (visible component): Ignoring all type constraints, the
   visible components for a type that is directly or indirectly a
   combining ASN.1 type (i.e., SEQUENCE, SET, CHOICE, SEQUENCE OF, or
   SET OF) is the set of components of the combining type definition
   plus, for each NamedType (of the combining type definition) that is
   subject to a GROUP encoding instruction, the visible components for
   the type of the NamedType.  The visible components are determined
   after the COMPONENTS OF transformation specified in X.680, Clause
   24.4 [X.680].

Top      Up      ToC       Page 35 
      Aside: The set of visible attribute and element components for a
      type is the set of all the components of the type, and any nested
      types, that describe attributes and child elements appearing in
      the RXER encodings of values of the outer type.

   A GROUP encoding instruction MUST NOT be used where it would cause a
   NamedType to be a visible component of the type of that same
   NamedType (which is only possible if the type definition is
   recursive).

      Aside: Components subject to a GROUP encoding instruction might be
      translated into a compatible XML Schema [XSD1] as group
      definitions.  A NamedType that is visible to its own type is
      analogous to a circular group, which XML Schema disallows.

   Section 25.1 imposes additional conditions on the use of the GROUP
   encoding instruction.

   In any use of the GROUP encoding instruction, there is a type, the
   including type, that contains the component subject to the GROUP
   encoding instruction, and a type, the included type, that is the base
   type of that component.  Either type can have an extensible content
   model, either by directly using ASN.1 extensibility or by including
   through another GROUP encoding instruction some other type that is
   extensible.

   The including and included types may be defined in different ASN.1
   modules, in which case the owner of the including type, i.e., the
   person or organization having the authority to add extensions to the
   including type's definition, may be different from the owner of the
   included type.

   If the owner of the including type is not using the most recent
   version of the included type's definition, then the owner of the
   including type might add an extension to the including type that is
   valid with respect to the older version of the included type, but is
   later found to be invalid when the latest versions of the including
   and included type definitions are brought together (perhaps by a
   third party).  Although the owner of the including type must
   necessarily be aware of the existence of the included type, the
   reverse is not necessarily true.  The owner of the included type
   could add an extension to the included type without realizing that it
   invalidates someone else's including type.

Top      Up      ToC       Page 36 
   To avoid these problems, a GROUP encoding instruction MUST NOT be
   used if:

   (1) the included type is defined in a different module from the
       including type, and

   (2) the included type has an extensible content model, and

   (3) changes to the included type are not coordinated with the owner
       of the including type.

   Changes in the included type are coordinated with the owner of the
   including type if:

   (1) the owner of the included type is also the owner of the including
       type, or

   (2) the owner of the including type is collaborating with the owner
       of the included type, or

   (3) all changes will be vetted by a common third party before being
       approved and published.

25.1.  Unambiguous Encodings

   Unregulated use of the GROUP encoding instruction can easily lead to
   specifications in which distinct abstract values have
   indistinguishable RXER encodings, i.e., ambiguous encodings.  This
   section imposes restrictions on the use of the GROUP encoding
   instruction to ensure that distinct abstract values have distinct
   RXER encodings.  In addition, these restrictions ensure that an
   abstract value can be easily decoded in a single pass without
   back-tracking.

   An RXER decoder for an ASN.1 type can be abstracted as a recognizer
   for a notional language, consisting of element and attribute expanded
   names, where the type definition describes the grammar for that
   language (in fact it is a context-free grammar).  The restrictions on
   a type definition to ensure easy, unambiguous decoding are more
   conveniently, completely, and simply expressed as conditions on this
   associated grammar.  Implementations are not expected to verify type
   definitions exactly in the manner to be described; however, the
   procedure used MUST produce the same result.

   Section 25.1.1 describes the procedure for recasting as a grammar a
   type definition containing components subject to the GROUP encoding
   instruction.  Sections 25.1.2 and 25.1.3 specify conditions that the

Top      Up      ToC       Page 37 
   grammar must satisfy for the type definition to be valid.  Section
   25.1.4 describes how unrecognized attributes are accepted by the
   grammar for an extensible type.

   Appendices A and B have extensive examples.

25.1.1.  Grammar Construction

   A grammar consists of a collection of productions.  A production has
   a left-hand side and a right-hand side (in this document, separated
   by the "::=" symbol).  The left-hand side (in a context-free grammar)
   is a single non-terminal symbol.  The right-hand side is a sequence
   of non-terminal and terminal symbols.  The terminal symbols are the
   lexical items of the language that the grammar describes.  One of the
   non-terminals is nominated to be the start symbol.  A valid sequence
   of terminals for the language can be generated from the grammar by
   beginning with the start symbol and repeatedly replacing any
   non-terminal with the right-hand side of one of the productions where
   that non-terminal is on the production's left-hand side.  The final
   sequence of terminals is achieved when there are no remaining
   non-terminals to replace.

      Aside: X.680 describes the ASN.1 basic notation using a
      context-free grammar.

   Each NamedType has an associated primary and secondary non-terminal.

      Aside: The secondary non-terminal for a NamedType is used when the
      base type of the type in the NamedType is a SEQUENCE OF type or
      SET OF type.

   Each ExtensionAddition and ExtensionAdditionAlternative has an
   associated non-terminal.  There is a non-terminal associated with the
   extension insertion point of each extensible type.  There is also a
   primary start non-terminal (this is the start symbol) and a secondary
   start non-terminal.  The exact nature of the non-terminals is not
   important, however all the non-terminals MUST be mutually distinct.

   It is adequate for most of the examples in this document (though not
   in the most general case) for the primary non-terminal for a
   NamedType to be the identifier of the NamedType, for the primary
   start non-terminal to be S, for the non-terminals for the instances
   of ExtensionAddition and ExtensionAdditionAlternative to be E1, E2,
   E3, and so on, and for the non-terminals for the extension insertion
   points to be I1, I2, I3, and so on.  The secondary non-terminals are
   labelled by appending a "'" character to the primary non-terminal
   label, e.g., the primary and secondary start non-terminals are S and
   S', respectively.

Top      Up      ToC       Page 38 
   Each NamedType and extension insertion point has an associated
   terminal.  There exists a terminal called the general extension
   terminal that is not associated with any specific notation.  The
   general extension terminal and the terminals for the extension
   insertion points are used to represent elements in unknown
   extensions.  The exact nature of the terminals is not important;
   however, the aforementioned terminals MUST be mutually distinct.  The
   terminals are further categorized as either element terminals or
   attribute terminals.  A terminal for a NamedType is an attribute
   terminal if its associated NamedType is an attribute component;
   otherwise, it is an element terminal.  The general extension terminal
   and the terminals for the extension insertion points are categorized
   as element terminals.

   Terminals for attributes in unknown extensions are not explicitly
   provided in the grammar.  Certain productions in the grammar are
   categorized as insertion point productions, and their role in
   accepting unknown attributes is described in Section 25.1.4.

   In the examples in this document, the terminal for a component other
   than an attribute component will be represented as the local name of
   the expanded name of the component enclosed in double quotes, and the
   terminal for an attribute component will be represented as the local
   name of the expanded name of the component prefixed by the '@'
   character and enclosed in double quotes.  The general extension
   terminal will be represented as "*" and the terminals for the
   extension insertion points will be represented as "*1", "*2", "*3",
   and so on.

   The productions generated from a NamedType depend on the base type of
   the type of the NamedType.  The productions for the start
   non-terminals depend on the combining type definition being tested.
   In either case, the procedure for generating productions takes a
   primary non-terminal, a secondary non-terminal (sometimes), and a
   type definition.

   The grammar is constructed beginning with the start non-terminals and
   the combining type definition being tested.

   A grammar is constructed after the COMPONENTS OF transformation
   specified in X.680, Clause 24.4 [X.680].

   Given a primary non-terminal, N, and a type where the base type is a
   SEQUENCE or SET type, a production is added to the grammar with N as
   the left-hand side.  The right-hand side is constructed from an
   initial empty state according to the following cases considered in
   order:

Top      Up      ToC       Page 39 
   (1) If an initial RootComponentTypeList is present in the base type,
       then the sequence of primary non-terminals for the components
       nested in that RootComponentTypeList are appended to the right-
       hand side in the order of their definition.

   (2) If an ExtensionAdditions instance is present in the base type and
       not empty, then the non-terminal for the first ExtensionAddition
       nested in the ExtensionAdditions instance is appended to the
       right-hand side.

   (3) If an ExtensionAdditions instance is empty or not present in the
       base type, and the base type is extensible (explicitly or by
       default), and the base type is not subject to a NO-INSERTIONS or
       HOLLOW-INSERTIONS encoding instruction, then the non-terminal for
       the extension insertion point of the base type is appended to the
       right-hand side.

   (4) If a final RootComponentTypeList is present in the base type,
       then the primary non-terminals for the components nested in that
       RootComponentTypeList are appended to the right-hand side in the
       order of their definition.

   The production is an insertion point production if an
   ExtensionAdditions instance is empty or not present in the base type,
   and the base type is extensible (explicitly or by default), and the
   base type is not subject to a NO-INSERTIONS encoding instruction.

   If a component in a ComponentTypeList (in either a
   RootComponentTypeList or an ExtensionAdditionGroup) is marked
   OPTIONAL or DEFAULT, then a production with the primary non-terminal
   of the component as the left-hand side and an empty right-hand side
   is added to the grammar.

   If a component (regardless of the ASN.1 combining type containing it)
   is subject to a GROUP encoding instruction, then one or more
   productions constructed according to the component's type are added
   to the grammar.  Each of these productions has the primary
   non-terminal of the component as the left-hand side.

   If a component (regardless of the ASN.1 combining type containing it)
   is not subject to a GROUP encoding instruction, then a production is
   added to the grammar with the primary non-terminal of the component
   as the left-hand side and the terminal of the component as the
   right-hand side.

Top      Up      ToC       Page 40 
   Example

      Consider the following ASN.1 type definition:

         SEQUENCE {
             -- Start of initial RootComponentTypeList.
             one    [ATTRIBUTE] UTF8String,
             two    BOOLEAN OPTIONAL,
             three  INTEGER
             -- End of initial RootComponentTypeList.
         }

      Here is the grammar derived from this type:

         S ::= one two three
         one ::= "@one"
         two ::= "two"
         two ::=
         three ::= "three"

   For each ExtensionAddition (of a SEQUENCE or SET base type), a
   production is added to the grammar where the left-hand side is the
   non-terminal for the ExtensionAddition and the right-hand side is
   initially empty.  If the ExtensionAddition is a ComponentType, then
   the primary non-terminal for the NamedType in the ComponentType is
   appended to the right-hand side; otherwise (an
   ExtensionAdditionGroup), the sequence of primary non-terminals for
   the components nested in the ComponentTypeList in the
   ExtensionAdditionGroup are appended to the right-hand side in the
   order of their definition.  If the ExtensionAddition is followed by
   another ExtensionAddition, then the non-terminal for the next
   ExtensionAddition is appended to the right-hand side; otherwise, if
   the base type is not subject to a NO-INSERTIONS or HOLLOW-INSERTIONS
   encoding instruction, then the non-terminal for the extension
   insertion point of the base type is appended to the right-hand side.
   If the ExtensionAddition is not followed by another ExtensionAddition
   and the base type is not subject to a NO-INSERTIONS encoding
   instruction, then the production is an insertion point production.
   If the empty sequence of terminals cannot be generated from the
   production (it may be necessary to wait until the grammar is
   otherwise complete before making this determination), then another
   production is added to the grammar where the left-hand side is the
   non-terminal for the ExtensionAddition and the right-hand side is
   empty.

      Aside: An extension is always effectively optional since a sender
      may be using an earlier version of the ASN.1 specification where
      none, or only some, of the extensions have been defined.

Top      Up      ToC       Page 41 
      Aside: The grammar generated for ExtensionAdditions is structured
      to take account of the condition that an extension can only be
      used if all the earlier extensions are also used [X.680].

   If a SEQUENCE or SET base type is extensible (explicitly or by
   default) and is not subject to a NO-INSERTIONS or HOLLOW-INSERTIONS
   encoding instruction, then:

   (1) a production is added to the grammar where the left-hand side is
       the non-terminal for the extension insertion point of the base
       type and the right-hand side is the general extension terminal
       followed by the non-terminal for the extension insertion point,
       and

   (2) a production is added to the grammar where the left-hand side is
       the non-terminal for the extension insertion point and the
       right-hand side is empty.

   Example

      Consider the following ASN.1 type definition:

         SEQUENCE {
             -- Start of initial RootComponentTypeList.
             one    BOOLEAN,
             two    INTEGER OPTIONAL,
             -- End of initial RootComponentTypeList.
             ...,
             -- Start of ExtensionAdditions.
             four  INTEGER,  -- First ExtensionAddition (E1).
             five  BOOLEAN OPTIONAL,  -- Second ExtensionAddition (E2).
             [[ -- An ExtensionAdditionGroup.
                 six    UTF8String,
                 seven  INTEGER OPTIONAL
             ]], -- Third ExtensionAddition (E3).
             -- End of ExtensionAdditions.
             -- The extension insertion point is here (I1).
             ...,
             -- Start of final RootComponentTypeList.
             three  INTEGER
         }

      Here is the grammar derived from this type:

         S ::= one two E1 three

         E1 ::= four E2
         E1 ::=

Top      Up      ToC       Page 42 
         E2 ::= five E3
         E3 ::= six seven I1
         E3 ::=

         I1 ::= "*" I1
         I1 ::=

         one ::= "one"
         two ::= "two"
         two ::=
         three ::= "three"
         four ::= "four"
         five ::= "five"
         five ::=
         six ::= "six"
         seven ::= "seven"
         seven ::=

      If the SEQUENCE type were subject to a NO-INSERTIONS or
      HOLLOW-INSERTIONS encoding instruction, then the productions for
      I1 would not appear, and the first production for E3 would be:

         E3 ::= six seven

   Given a primary non-terminal, N, and a type where the base type is a
   CHOICE type:

   (1) A production is added to the grammar for each NamedType nested in
       the RootAlternativeTypeList of the base type, where the left-hand
       side is N and the right-hand side is the primary non-terminal for
       the NamedType.

   (2) A production is added to the grammar for each
       ExtensionAdditionAlternative of the base type, where the left-
       hand side is N and the right-hand side is the non-terminal for
       the ExtensionAdditionAlternative.

   (3) If the base type is extensible (explicitly or by default) and the
       base type is not subject to an insertion encoding instruction,
       then:

       (a) A production is added to the grammar where the left-hand side
           is N and the right-hand side is the non-terminal for the
           extension insertion point of the base type.  This production
           is an insertion point production.

Top      Up      ToC       Page 43 
       (b) A production is added to the grammar where the left-hand side
           is the non-terminal for the extension insertion point of the
           base type and the right-hand side is the general extension
           terminal followed by the non-terminal for the extension
           insertion point.

       (c) A production is added to the grammar where the left-hand side
           is the non-terminal for the extension insertion point of the
           base type and the right-hand side is empty.

   (4) If the base type is subject to a HOLLOW-INSERTIONS encoding
       instruction, then a production is added to the grammar where the
       left-hand side is N and the right-hand side is empty.  This
       production is an insertion point production.

   (5) If the base type is subject to a SINGULAR-INSERTIONS encoding
       instruction, then a production is added to the grammar where the
       left-hand side is N and the right-hand side is the general
       extension terminal.  This production is an insertion point
       production.

   (6) If the base type is subject to a UNIFORM-INSERTIONS encoding
       instruction, then:

       (a) A production is added to the grammar where the left-hand side
           is N and the right-hand side is the general extension
           terminal.

              Aside: This production is used to verify the correctness
              of an ASN.1 type definition, but would not be used in the
              implementation of an RXER decoder.  The next production
              takes precedence over it for accepting an unknown element.

       (b) A production is added to the grammar where the left-hand side
           is N and the right-hand side is the terminal for the
           extension insertion point of the base type followed by the
           non-terminal for the extension insertion point.  This
           production is an insertion point production.

       (c) A production is added to the grammar where the left-hand side
           is the non-terminal for the extension insertion point of the
           base type and the right-hand side is the terminal for the
           extension insertion point followed by the non-terminal for
           the extension insertion point.

       (d) A production is added to the grammar where the left-hand side
           is the non-terminal for the extension insertion point of the
           base type and the right-hand side is empty.

Top      Up      ToC       Page 44 
   (7) If the base type is subject to a MULTIFORM-INSERTIONS encoding
       instruction, then:

       (a) A production is added to the grammar where the left-hand side
           is N and the right-hand side is the general extension
           terminal followed by the non-terminal for the extension
           insertion point of the base type.  This production is an
           insertion point production.

       (b) A production is added to the grammar where the left-hand side
           is the non-terminal for the extension insertion point of the
           base type and the right-hand side is the general extension
           terminal followed by the non-terminal for the extension
           insertion point.

       (c) A production is added to the grammar where the left-hand side
           is the non-terminal for the extension insertion point of the
           base type and the right-hand side is empty.

   If an ExtensionAdditionAlternative is a NamedType, then a production
   is added to the grammar where the left-hand side is the non-terminal
   for the ExtensionAdditionAlternative and the right-hand side is the
   primary non-terminal for the NamedType.

   If an ExtensionAdditionAlternative is an
   ExtensionAdditionAlternativesGroup, then a production is added to the
   grammar for each NamedType nested in the
   ExtensionAdditionAlternativesGroup, where the left-hand side is the
   non-terminal for the ExtensionAdditionAlternative and the right-hand
   side is the primary non-terminal for the NamedType.

Top      Up      ToC       Page 45 
   Example

      Consider the following ASN.1 type definition:

         CHOICE {
             -- Start of RootAlternativeTypeList.
             one    BOOLEAN,
             two    INTEGER,
             -- End of RootAlternativeTypeList.
             ...,
             -- Start of ExtensionAdditionAlternatives.
             three  INTEGER, -- First ExtensionAdditionAlternative (E1).
             [[ -- An ExtensionAdditionAlternativesGroup.
                 four  UTF8String,
                 five  INTEGER
             ]] -- Second ExtensionAdditionAlternative (E2).
             -- The extension insertion point is here (I1).
         }

      Here is the grammar derived from this type:

         S ::= one
         S ::= two
         S ::= E1
         S ::= E2
         S ::= I1

         I1 ::= "*" I1
         I1 ::=

         E1 ::= three
         E2 ::= four
         E2 ::= five

         one ::= "one"
         two ::= "two"
         three ::= "three"
         four ::= "four"
         five ::= "five"

      If the CHOICE type were subject to a NO-INSERTIONS encoding
      instruction, then the fifth, sixth, and seventh productions would
      be removed.

      If the CHOICE type were subject to a HOLLOW-INSERTIONS encoding
      instruction, then the fifth, sixth, and seventh productions would
      be replaced by:

Top      Up      ToC       Page 46 
         S ::=

      If the CHOICE type were subject to a SINGULAR-INSERTIONS encoding
      instruction, then the fifth, sixth, and seventh productions would
      be replaced by:

         S ::= "*"

      If the CHOICE type were subject to a UNIFORM-INSERTIONS encoding
      instruction, then the fifth and sixth productions would be
      replaced by:

         S ::= "*"
         S ::= "*1" I1

         I1 ::= "*1" I1

      If the CHOICE type were subject to a MULTIFORM-INSERTIONS encoding
      instruction, then the fifth production would be replaced by:

         S ::= "*" I1

   Constraints on a SEQUENCE, SET, or CHOICE type are ignored.  They do
   not affect the grammar being generated.

      Aside: This avoids an awkward situation where values of a subtype
      have to be decoded differently from values of the parent type.  It
      also simplifies the verification procedure.

   Given a primary non-terminal, N, and a type that has a SEQUENCE OF or
   SET OF base type and that permits a value of size zero (i.e., an
   empty sequence or set):

   (1) a production is added to the grammar where the left-hand side of
       the production is N and the right-hand side is the primary
       non-terminal for the NamedType of the component of the
       SEQUENCE OF or SET OF base type, followed by N, and

   (2) a production is added to the grammar where the left-hand side of
       the production is N and the right-hand side is empty.

   Given a primary non-terminal, N, a secondary non-terminal, N', and a
   type that has a SEQUENCE OF or SET OF base type and that does not
   permit a value of size zero:

Top      Up      ToC       Page 47 
   (1) a production is added to the grammar where the left-hand side of
       the production is N and the right-hand side is the primary
       non-terminal for the NamedType of the component of the
       SEQUENCE OF or SET OF base type, followed by N', and

   (2) a production is added to the grammar where the left-hand side of
       the production is N' and the right-hand side is the primary
       non-terminal for the NamedType of the component of the
       SEQUENCE OF or SET OF base type, followed by N', and

   (3) a production is added to the grammar where the left-hand side of
       the production is N' and the right-hand side is empty.

   Example

      Consider the following ASN.1 type definition:

         SEQUENCE SIZE(1..MAX) OF number INTEGER

      Here is the grammar derived from this type:

         S ::= number S'
         S' ::= number S'
         S' ::=

         number ::= "number"

   All inner subtyping (InnerTypeContraints) is ignored for the purposes
   of deciding whether a value of size zero is permitted by a
   SEQUENCE OF or SET OF type.

   This completes the description of the transformation of ASN.1
   combining type definitions into a grammar.

25.1.2.  Unique Component Attribution

   This section describes conditions that the grammar must satisfy so
   that each element and attribute in a received RXER encoding can be
   uniquely associated with an ASN.1 component definition.

   Definition (used by the grammar):  A non-terminal, N, is used by the
   grammar if:

   (1) N is the start symbol or

   (2) N appears on the right-hand side of a production where the
       non-terminal on the left-hand side is used by the grammar.

Top      Up      ToC       Page 48 
   Definition (multiple derivation paths):  A non-terminal, N, has
   multiple derivation paths if:

   (1) N appears on the right-hand side of a production where the
       non-terminal on the left-hand side has multiple derivation paths,
       or

   (2) N appears on the right-hand side of more than one production
       where the non-terminal on the left-hand side is used by the
       grammar, or

   (3) N is the start symbol and it appears on the right-hand side of a
       production where the non-terminal on the left-hand side is used
       by the grammar.

   For every ASN.1 type with a base type containing components that are
   subject to a GROUP encoding instruction, the grammar derived by the
   method described in this document MUST NOT have:

   (1) two or more primary non-terminals that are used by the grammar
       and are associated with element components having the same
       expanded name, or

   (2) two or more primary non-terminals that are used by the grammar
       and are associated with attribute components having the same
       expanded name, or

   (3) a primary non-terminal that has multiple derivation paths and is
       associated with an attribute component.

      Aside: Case (1) is in response to component referencing notations
      that are evaluated with respect to the XML encoding of an abstract
      value.  Case (1) guarantees, without having to do extensive
      testing (which would necessarily have to take account of encoding
      instructions for all other encoding rules), that all sibling
      elements with the same expanded name will be associated with
      equivalent type definitions.  Such equivalence allows a component
      referenced by element name to be re-encoded using a different set
      of ASN.1 encoding rules without ambiguity as to which type
      definition and encoding instructions apply.

      Cases (2) and (3) ensure that an attribute name is always uniquely
      associated with one component that can occur at most once and is
      always nested in the same part of an abstract value.

Top      Up      ToC       Page 49 
   Example

      The following example types illustrate various uses and misuses of
      the GROUP encoding instruction with respect to unique component
      attribution:

         TA ::= SEQUENCE {
             a  [GROUP] TB,
             b  [GROUP] CHOICE {
                 a  [GROUP] TB,
                 b  [NAME AS "c"] [ATTRIBUTE] INTEGER,
                 c  INTEGER,
                 d  TB,
                 e  [GROUP] TD,
                 f  [ATTRIBUTE] UTF8String
             },
             c  [ATTRIBUTE] INTEGER,
             d  [GROUP] SEQUENCE OF
                 a [GROUP] SEQUENCE {
                     a  [ATTRIBUTE] OBJECT IDENTIFIER,
                     b  INTEGER
                 },
             e  [NAME AS "c"] INTEGER,
             COMPONENTS OF TD
         }

         TB ::= SEQUENCE {
             a  INTEGER,
             b  [ATTRIBUTE] BOOLEAN,
             COMPONENTS OF TC
         }

         TC ::= SEQUENCE {
             f  OBJECT IDENTIFIER
         }

         TD ::= SEQUENCE {
             g  OBJECT IDENTIFIER
         }

      The grammar for TA is constructed after performing the
      COMPONENTS OF transformation.  The result of this transformation
      is shown next.  This example will depart from the usual convention
      of using just the identifier of a NamedType to represent the
      primary non-terminal for that NamedType.  A label relative to the
      outermost type will be used instead to better illustrate unique
      component attribution.  The labels used for the non-terminals are
      shown down the right-hand side.

Top      Up      ToC       Page 50 
         TA ::= SEQUENCE {
             a  [GROUP] TB,                             -- TA.a
             b  [GROUP] CHOICE {                        -- TA.b
                 a  [GROUP] TB,                         -- TA.b.a
                 b  [NAME AS "c"] [ATTRIBUTE] INTEGER,  -- TA.b.b
                 c  INTEGER,                            -- TA.b.c
                 d  TB,                                 -- TA.b.d
                 e  [GROUP] TD,                         -- TA.b.e
                 f  [ATTRIBUTE] UTF8String              -- TA.b.f
             },
             c  [ATTRIBUTE] INTEGER,                    -- TA.c
             d  [GROUP] SEQUENCE OF                     -- TA.d
                 a [GROUP] SEQUENCE {                   -- TA.d.a
                     a  [ATTRIBUTE] OBJECT IDENTIFIER,  -- TA.d.a.a
                     b  INTEGER                         -- TA.d.a.b
                 },
             e  [NAME AS "c"] INTEGER,                  -- TA.e
             g  OBJECT IDENTIFIER                       -- TA.g
         }

         TB ::= SEQUENCE {
             a  INTEGER,                                -- TB.a
             b  [ATTRIBUTE] BOOLEAN,                    -- TB.b
             f  OBJECT IDENTIFIER                       -- TB.f
         }

         -- Type TC is no longer of interest. --

         TD ::= SEQUENCE {
             g  OBJECT IDENTIFIER                       -- TD.g
         }

      The associated grammar is:

         S ::= TA.a TA.b TA.c TA.d TA.e TA.g

         TA.a ::= TB.a TB.b TB.f

         TB.a ::= "a"
         TB.b ::= "@b"
         TB.f ::= "f"

         TA.b ::= TA.b.a
         TA.b ::= TA.b.b
         TA.b ::= TA.b.c
         TA.b ::= TA.b.d
         TA.b ::= TA.b.e
         TA.b ::= TA.b.f

Top      Up      ToC       Page 51 
         TA.b.a ::= TB.a TB.b TB.f
         TA.b.b ::= "@c"
         TA.b.c ::= "c"
         TA.b.d ::= "d"
         TA.b.e ::= TD.g
         TA.b.f ::= "@f"

         TD.g ::= "g"

         TA.c ::= "@c"

         TA.d ::= TA.d.a TA.d
         TA.d ::=

         TA.d.a ::= TA.d.a.a TA.d.a.b

         TA.d.a.a := "@a"
         TA.d.a.b ::= "b"

         TA.e ::= "c"

         TA.g ::= "g"

      All the non-terminals are used by the grammar.

      The type definition for TA is invalid because there are two
      instances where two or more primary non-terminals are associated
      with element components having the same expanded name:

      (1) TA.b.c and TA.e (both generate the terminal "c"), and

      (2) TD.g and TA.g (both generate the terminal "g").

      In case (2), TD.g and TA.g are derived from the same instance of
      NamedType notation, but become distinct components following the
      COMPONENTS OF transformation.  AUTOMATIC tagging is applied after
      the COMPONENTS OF transformation, which means that the types of
      the components corresponding to TD.g and TA.g will end up with
      different tags, and therefore the types will not be equivalent.

      The type definition for TA is also invalid because there is one
      instance where two or more primary non-terminals are associated
      with attribute components having the same expanded name:  TA.b.b
      and TA.c (both generate the terminal "@c").

Top      Up      ToC       Page 52 
      The non-terminals with multiple derivation paths are:  TA.d,
      TA.d.a, TA.d.a.a, TA.d.a.b, TB.a, TB.b, and TB.f.  The type
      definition for TA is also invalid because TA.d.a.a and TB.b are
      primary non-terminals that are associated with an attribute
      component.

25.1.3.  Deterministic Grammars

   Let the First Set of a production P, denoted First(P), be the set of
   all element terminals T where T is the first element terminal in a
   sequence of terminals that can be generated from the right-hand side
   of P.  There can be any number of leading attribute terminals before
   T.

   Let the Follow Set of a non-terminal N, denoted Follow(N), be the set
   of all element terminals T where T is the first element terminal
   following N in a sequence of non-terminals and terminals that can be
   generated from the grammar.  There can be any number of attribute
   terminals between N and T.  If a sequence of non-terminals and
   terminals can be generated from the grammar where N is not followed
   by any element terminals, then Follow(N) also contains a special end
   terminal, denoted by "$".

      Aside: If N does not appear on the right-hand side of any
      production, then Follow(N) will be empty.

   For a production P, let the predicate Empty(P) be true if and only if
   the empty sequence of terminals can be generated from P.  Otherwise,
   Empty(P) is false.

   Definition (base grammar):  The base grammar is a rewriting of the
   grammar in which the non-terminals for every ExtensionAddition and
   ExtensionAdditionAlternative are removed from the right-hand side of
   all productions.

   For a production P, let the predicate Preselected(P) be true if and
   only if every sequence of terminals that can be generated from the
   right-hand side of P using only the base grammar contains at least
   one attribute terminal.  Otherwise, Preselected(P) is false.

   The Select Set of a production P, denoted Select(P), is empty if
   Preselected(P) is true; otherwise, it contains First(P).  Let N be
   the non-terminal on the left-hand side of P.  If Empty(P) is true,
   then Select(P) also contains Follow(N).

Top      Up      ToC       Page 53 
      Aside: It may appear somewhat dubious to include the attribute
      components in the grammar because, in reality, attributes appear
      unordered within the start tag of an element, and not interspersed
      with the child elements as the grammar would suggest.  This is why
      attribute terminals are ignored in composing the First Sets and
      Follow Sets.  However, the attribute terminals are important in
      composing the Select Sets because they can preselect a production
      and can prevent a production from being able to generate an empty
      sequence of terminals.  In real terms, this corresponds to an RXER
      decoder using the attributes to determine the presence or absence
      of optional components and to select between the alternatives of a
      CHOICE, even before considering the child elements.

      An attribute appearing in an extension isn't used to preselect a
      production since, in general, a decoder using an earlier version
      of the specification would not be able to associate the attribute
      with any particular extension insertion point.

   Let the Reach Set of a non-terminal N, denoted Reach(N), be the set
   of all element terminals T where T appears in a sequence of terminals
   that can be generated from N.

      Aside: It can be readily shown that all the optional attribute
      components and all but one of the mandatory attribute components
      of a SEQUENCE or SET type can be ignored in constructing the
      grammar because their omission does not alter the First, Follow,
      Select, or Reach Sets, or the evaluation of the Preselected and
      Empty predicates.

   A grammar is deterministic (for the purposes of an RXER decoder) if
   and only if:

   (1) there do not exist two productions P and Q, with the same
       non-terminal on the left-hand side, where the intersection of
       Select(P) and Select(Q) is not empty, and

   (2) there does not exist a non-terminal E for an ExtensionAddition or
       ExtensionAdditionAlternative where the intersection of Reach(E)
       and Follow(E) is not empty.

      Aside: In case (1), if the intersection is not empty, then a
      decoder would have two or more possible ways to attempt to decode
      the input into an abstract value.  In case (2), if the
      intersection is not empty, then a decoder using an earlier version
      of the ASN.1 specification would confuse an element in an unknown
      (to that decoder) extension with a known component following the
      extension.

Top      Up      ToC       Page 54 
      Aside: In the absence of any attribute components, case (1) is the
      test for an LL(1) grammar.

   For every ASN.1 type with a base type containing components that are
   subject to a GROUP encoding instruction, the grammar derived by the
   method described in this document MUST be deterministic.

25.1.4.  Attributes in Unknown Extensions

   An insertion point production is able to accept unknown attributes if
   the non-terminal on the left-hand side of the production does not
   have multiple derivation paths.

      Aside: If the non-terminal has multiple derivation paths, then any
      future extension cannot possibly contain an attribute component
      because that would violate the requirements of Section 25.1.2.

   For a deterministic grammar, there is only one possible way to
   construct a sequence of element terminals matching the element
   content of an element in a correctly formed RXER encoding.  Any
   unknown attributes of the element are accepted if at least one
   insertion point production that is able to accept unknown attributes
   is used in that construction.

   Example

      Consider this type definition:

         CHOICE {
             one  UTF8String,
             two  [GROUP] SEQUENCE {
                  three  INTEGER,
                  ...
             }
         }

      The associated grammar is:

         S ::= one
         S ::= two

         two ::= three I1

         I1 ::= "*" I1
         I1 ::=

         one ::= "one"
         three ::= "three"

Top      Up      ToC       Page 55 
      The third production is an insertion point production, and it is
      able to accept unknown attributes.

      When decoding a value of this type, if the element content
      contains a <one> child element, then any unrecognized attribute
      would be illegal as the insertion point production would not be
      used to recognize the input (the "one" alternative does not admit
      an extension insertion point).  If the element content contains a
      <three> element, then an unrecognized attribute would be accepted
      because the insertion point production would be used to recognize
      the input (the "two" alternative that generates the <three>
      element has an extensible type).

      If the SEQUENCE type were prefixed by a NO-INSERTIONS encoding
      instruction, then the third, fourth, and fifth productions would
      be replaced by:

         two ::= three

      With this change, any unrecognized attribute would be illegal for
      the "two" alternative also, since the replacement production is
      not an insertion point production.

   If more than one insertion point production that is able to accept
   unknown attributes is used in constructing a matching sequence of
   element terminals, then a decoder is free to associate an
   unrecognized attribute with any one of the extension insertion points
   corresponding to those insertion point productions.  The
   justification for doing so comes from the following two observations:

   (1) If the encoding of an abstract value contains an extension where
       the type of the extension is unknown to the receiver, then it is
       generally impossible to re-encode the value using a different set
       of encoding rules, including the canonical variant of the
       received encoding.  This is true no matter which encoding rules
       are being used.  It is desirable for a decoder to be able to
       accept and store the raw encoding of an extension without raising
       an error, and to re-insert the raw encoding of the extension when
       re-encoding the abstract value using the same non-canonical
       encoding rules.  However, there is little more that an
       application can do with an unknown extension.

       An application using RXER can successfully accept, store, and
       re-encode an unrecognized attribute regardless of which extension
       insertion point it might be ascribed to.

Top      Up      ToC       Page 56 
   (2) Even if there is a single extension insertion point, an unknown
       extension could still be the encoding of a value of any one of an
       infinite number of valid type definitions.  For example, an
       attribute or element component could be nested to any arbitrary
       depth within CHOICEs whose components are subject to GROUP
       encoding instructions.

          Aside: A similar series of nested CHOICEs could describe an
          unknown extension in a Basic Encoding Rules (BER) encoding
          [X.690].



(page 56 continued on part 3)

Next RFC Part