tech-invite   World Map     

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

RFC 4911

Experimental
Pages: 91
Top     in Index     Prev     Next
in Group Index     Prev in Group     No Next: Highest Number in Group     Group: ~rxer

Encoding Instructions for the Robust XML Encoding Rules (RXER)

Part 1 of 4, p. 1 to 20
None       Next RFC Part

 


Top       ToC       Page 1 
Network Working Group                                            S. Legg
Request for Comments: 4911                                       eB2Bcom
Category: Experimental                                         July 2007


                     Encoding Instructions for the
                    Robust XML Encoding Rules (RXER)

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

   This document defines encoding instructions that may be used in an
   Abstract Syntax Notation One (ASN.1) specification to alter how ASN.1
   values are encoded by the Robust XML Encoding Rules (RXER) and
   Canonical Robust XML Encoding Rules (CRXER), for example, to encode a
   component of an ASN.1 value as an Extensible Markup Language (XML)
   attribute rather than as a child element.  Some of these encoding
   instructions also affect how an ASN.1 specification is translated
   into an Abstract Syntax Notation X (ASN.X) specification.  Encoding
   instructions that allow an ASN.1 specification to reference
   definitions in other XML schema languages are also defined.

Top       Page 2 
Table of Contents

   1. Introduction ....................................................3
   2. Conventions .....................................................3
   3. Definitions .....................................................4
   4. Notation for RXER Encoding Instructions .........................4
   5. Component Encoding Instructions .................................6
   6. Reference Encoding Instructions .................................8
   7. Expanded Names of Components ...................................10
   8. The ATTRIBUTE Encoding Instruction .............................11
   9. The ATTRIBUTE-REF Encoding Instruction .........................12
   10. The COMPONENT-REF Encoding Instruction ........................13
   11. The ELEMENT-REF Encoding Instruction ..........................16
   12. The LIST Encoding Instruction .................................17
   13. The NAME Encoding Instruction .................................19
   14. The REF-AS-ELEMENT Encoding Instruction .......................19
   15. The REF-AS-TYPE Encoding Instruction ..........................20
   16. The SCHEMA-IDENTITY Encoding Instruction ......................22
   17. The SIMPLE-CONTENT Encoding Instruction .......................22
   18. The TARGET-NAMESPACE Encoding Instruction .....................23
   19. The TYPE-AS-VERSION Encoding Instruction ......................24
   20. The TYPE-REF Encoding Instruction .............................25
   21. The UNION Encoding Instruction ................................26
   22. The VALUES Encoding Instruction ...............................27
   23. Insertion Encoding Instructions ...............................29
   24. The VERSION-INDICATOR Encoding Instruction ....................32
   25. The GROUP Encoding Instruction ................................34
      25.1. Unambiguous Encodings ....................................36
           25.1.1. Grammar Construction ..............................37
           25.1.2. Unique Component Attribution ......................47
           25.1.3. Deterministic Grammars ............................52
           25.1.4. Attributes in Unknown Extensions ..................54
   26. Security Considerations .......................................56
   27. References ....................................................56
      27.1. Normative References .....................................56
      27.2. Informative References ...................................57
   Appendix A. GROUP Encoding Instruction Examples ...................58
   Appendix B. Insertion Encoding Instruction Examples ...............74
   Appendix C. Extension and Versioning Examples .....................87

Top      ToC       Page 3 
1.  Introduction

   This document defines encoding instructions [X.680-1] that may be
   used in an Abstract Syntax Notation One (ASN.1) [X.680] specification
   to alter how ASN.1 values are encoded by the Robust XML Encoding
   Rules (RXER) [RXER] and Canonical Robust XML Encoding Rules (CRXER)
   [RXER], for example, to encode a component of an ASN.1 value as an
   Extensible Markup Language (XML) [XML10] attribute rather than as a
   child element.  Some of these encoding instructions also affect how
   an ASN.1 specification is translated into an Abstract Syntax Notation
   X (ASN.X) specification [ASN.X].

   This document also defines encoding instructions that allow an ASN.1
   specification to incorporate the definitions of types, elements, and
   attributes in specifications written in other XML schema languages.
   References to XML Schema [XSD1] types, elements, and attributes,
   RELAX NG [RNG] named patterns and elements, and XML document type
   definition (DTD) [XML10] element types are supported.

   In most cases, the effect of an encoding instruction is only briefly
   mentioned in this document.  The precise effects of these encoding
   instructions are described fully in the specifications for RXER
   [RXER] and ASN.X [ASN.X], at the points where they apply.

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, unless
   qualified otherwise.

   A reference to an ASN.1 production [X.680] (e.g., Type, NamedType) is
   a reference to text in an ASN.1 specification corresponding to that
   production.  Throughout this document, "component" is synonymous with
   NamedType.

   This document uses the namespace prefix "xsi:" to stand for the
   namespace name [XMLNS10] "http://www.w3.org/2001/XMLSchema-instance".

   Example ASN.1 definitions in this document are assumed to be defined
   in an ASN.1 module with a TagDefault of "AUTOMATIC TAGS" and an
   EncodingReferenceDefault [X.680-1] of "RXER INSTRUCTIONS".

Top      ToC       Page 4 
3.  Definitions

   The following definition of base type is used in specifying a number
   of encoding instructions.

   Definition (base type): If a type, T, is a constrained type, then the
   base type of T is the base type of the type that is constrained; else
   if T is a prefixed type, then the base type of T is the base type of
   the type that is prefixed; else if T is a type notation that
   references or denotes another type (i.e., DefinedType,
   ObjectClassFieldType, SelectionType, TypeFromObject, or
   ValueSetFromObjects), then the base type of T is the base type of the
   type that is referenced or denoted; otherwise, the base type of T is
   T itself.

      Aside: A tagged type is a special case of a prefixed type.

4.  Notation for RXER Encoding Instructions

   The grammar of ASN.1 permits the application of encoding instructions
   [X.680-1], through type prefixes and encoding control sections, that
   modify how abstract values are encoded by nominated encoding rules.

   The generic notation for type prefixes and encoding control sections
   is defined by the ASN.1 basic notation [X.680] [X.680-1], and
   includes an encoding reference to identify the specific encoding
   rules that are affected by the encoding instruction.

   The encoding reference that identifies the Robust XML Encoding rules
   is literally RXER.  An RXER encoding instruction applies equally to
   both RXER and CRXER encodings.

   The specific notation for an encoding instruction for a specific set
   of encoding rules is left to the specification of those encoding
   rules.  Consequently, this companion document to the RXER
   specification [RXER] defines the notation for RXER encoding
   instructions.  Specifically, it elaborates the EncodingInstruction
   and EncodingInstructionAssignmentList placeholder productions of the
   ASN.1 basic notation.

   In the context of the RXER encoding reference, the
   EncodingInstruction production is defined as follows, using the
   conventions of the ASN.1 basic notation:

Top      ToC       Page 5 
      EncodingInstruction ::=
          AttributeInstruction |
          AttributeRefInstruction |
          ComponentRefInstruction |
          ElementRefInstruction |
          GroupInstruction |
          InsertionsInstruction |
          ListInstruction |
          NameInstruction |
          RefAsElementInstruction |
          RefAsTypeInstruction |
          SimpleContentInstruction |
          TypeAsVersionInstruction |
          TypeRefInstruction |
          UnionInstruction |
          ValuesInstruction |
          VersionIndicatorInstruction

   In the context of the RXER encoding reference, the
   EncodingInstructionAssignmentList production (which only appears in
   an encoding control section) is defined as follows:

      EncodingInstructionAssignmentList ::=
          SchemaIdentityInstruction ?
          TargetNamespaceInstruction ?
          TopLevelComponents ?

      TopLevelComponents ::= TopLevelComponent TopLevelComponents ?

      TopLevelComponent ::= "COMPONENT" NamedType

   Definition (top-level NamedType): A NamedType is a top-level
   NamedType (equivalently, a top-level component) if and only if it is
   the NamedType in a TopLevelComponent.  A NamedType nested within the
   Type of the NamedType of a TopLevelComponent is not itself a
   top-level NamedType.

      Aside: Specification writers should note that non-trivial types
      defined within a top-level NamedType will not be visible to ASN.1
      tools that do not understand RXER.

   Although a top-level NamedType only appears in an RXER encoding
   control section, the default encoding reference for the module
   [X.680-1] still applies when parsing a top-level NamedType.

   Each top-level NamedType within a module SHALL have a distinct
   identifier.

Top      ToC       Page 6 
   The NamedType production is defined by the ASN.1 basic notation.  The
   other productions are described in subsequent sections and make use
   of the following productions:

      NCNameValue ::= Value

      AnyURIValue ::= Value

      QNameValue ::= Value

      NameValue ::= Value

   The Value production is defined by the ASN.1 basic notation.

   The governing type for the Value in an NCNameValue is the NCName type
   from the AdditionalBasicDefinitions module [RXER].

   The governing type for the Value in an AnyURIValue is the AnyURI type
   from the AdditionalBasicDefinitions module.

   The governing type for the Value in a QNameValue is the QName type
   from the AdditionalBasicDefinitions module.

   The governing type for the Value in a NameValue is the Name type from
   the AdditionalBasicDefinitions module.

   The Value in an NCNameValue, AnyURIValue, QNameValue, or NameValue
   SHALL NOT be a DummyReference [X.683] and SHALL NOT textually contain
   a nested DummyReference.

      Aside: Thus, encoding instructions are not permitted to be
      parameterized in any way.  This restriction will become important
      if a future specification for ASN.X explicitly represents
      parameterized definitions and parameterized references instead of
      expanding out parameterized references as in the current
      specification.  A parameterized definition could not be directly
      translated into ASN.X if it contained encoding instructions that
      were not fully specified.

5.  Component Encoding Instructions

   Certain of the RXER encoding instructions are categorized as
   component encoding instructions.  The component encoding instructions
   are the ATTRIBUTE, ATTRIBUTE-REF, COMPONENT-REF, GROUP, ELEMENT-REF,
   NAME, REF-AS-ELEMENT, SIMPLE-CONTENT, TYPE-AS-VERSION, and
   VERSION-INDICATOR encoding instructions (whose notations are
   described respectively by AttributeInstruction,
   AttributeRefInstruction, ComponentRefInstruction, GroupInstruction,

Top      ToC       Page 7 
   ElementRefInstruction, NameInstruction, RefAsElementInstruction,
   SimpleContentInstruction, TypeAsVersionInstruction, and
   VersionIndicatorInstruction).

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

   (1) the Type in a NamedType, or

   (2) the Type in an EncodingPrefixedType in a PrefixedType in a
       BuiltinType in a Type that is one of (1) to (4), or

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

   (4) the Type in a ConstrainedType (excluding a TypeWithConstraint) in
       a Type that is one of (1) to (4).

      Aside: The effect of this condition is to force the component
      encoding instructions to be textually within the NamedType to
      which they apply.  Only case (2) can be true on the first
      iteration as the Type belongs to an EncodingPrefixedType; however,
      any of (1) to (4) can be true on subsequent iterations.

   Case (4) is not permitted when the encoding instruction is the
   ATTRIBUTE-REF, COMPONENT-REF, ELEMENT-REF, or REF-AS-ELEMENT encoding
   instruction.

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

   A top-level NamedType SHALL NOT be subject to an ATTRIBUTE-REF,
   COMPONENT-REF, GROUP, ELEMENT-REF, REF-AS-ELEMENT, or SIMPLE-CONTENT
   encoding instruction.

      Aside: This condition does not preclude these encoding
      instructions being used on a nested NamedType.

   A NamedType SHALL NOT be subject to two or more component encoding
   instructions of the same kind, e.g., a NamedType is not permitted to
   be subject to two NAME encoding instructions.

   The ATTRIBUTE, ATTRIBUTE-REF, COMPONENT-REF, GROUP, ELEMENT-REF,
   REF-AS-ELEMENT, SIMPLE-CONTENT, and TYPE-AS-VERSION encoding
   instructions are mutually exclusive.  The NAME, ATTRIBUTE-REF,
   COMPONENT-REF, ELEMENT-REF, and REF-AS-ELEMENT encoding instructions
   are mutually exclusive.  A NamedType SHALL NOT be subject to two or
   more encoding instructions that are mutually exclusive.

Top      ToC       Page 8 
   A SelectionType [X.680] SHALL NOT be used to select the Type from a
   NamedType that is subject to an ATTRIBUTE-REF, COMPONENT-REF,
   ELEMENT-REF or REF-AS-ELEMENT encoding instruction.  The other
   component encoding instructions are not inherited by the type denoted
   by a SelectionType.

   Definition (attribute component):  An attribute component is a
   NamedType that 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.

   Definition (element component):  An element component is a NamedType
   that is not subject to an ATTRIBUTE, ATTRIBUTE-REF, GROUP, or
   SIMPLE-CONTENT encoding instruction, and not subject to a
   COMPONENT-REF encoding instruction that references a top-level
   NamedType that is subject to an ATTRIBUTE encoding instruction.

      Aside: A NamedType subject to a GROUP or SIMPLE-CONTENT encoding
      instruction is neither an attribute component nor an element
      component.

6.  Reference Encoding Instructions

   Certain of the RXER encoding instructions are categorized as
   reference encoding instructions.  The reference encoding instructions
   are the ATTRIBUTE-REF, COMPONENT-REF, ELEMENT-REF, REF-AS-ELEMENT,
   REF-AS-TYPE, and TYPE-REF encoding instructions (whose notations are
   described respectively by AttributeRefInstruction,
   ComponentRefInstruction, ElementRefInstruction,
   RefAsElementInstruction, RefAsTypeInstruction, and
   TypeRefInstruction).  These encoding instructions (except
   COMPONENT-REF) allow an ASN.1 specification to incorporate the
   definitions of types, elements, and attributes in specifications
   written in other XML schema languages, through implied constraints on
   the markup that may appear in values of the Markup ASN.1 type from
   the AdditionalBasicDefinitions module [RXER] (for ELEMENT-REF,
   REF-AS-ELEMENT, REF-AS-TYPE, and TYPE-REF) or the UTF8String type
   (for ATTRIBUTE-REF).  References to XML Schema [XSD1] types,
   elements, and attributes, RELAX NG [RNG] named patterns and elements,
   and XML document type definition (DTD) [XML10] element types are
   supported.  References to ASN.1 types and top-level components are
   also permitted.  The COMPONENT-REF encoding instruction provides a
   more direct method of referencing a top-level component.

   The Type in the EncodingPrefixedType for an ELEMENT-REF,
   REF-AS-ELEMENT, REF-AS-TYPE, or TYPE-REF encoding instruction SHALL
   be either:

Top      ToC       Page 9 
   (1) a ReferencedType that is a DefinedType that is a typereference
       (not a DummyReference) or ExternalTypeReference that references
       the Markup ASN.1 type from the AdditionalBasicDefinitions module
       [RXER], or

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

   (3) a BuiltinType that is a PrefixedType that is an
       EncodingPrefixedType where the Type in the EncodingPrefixedType
       is one of (1) to (3) and the EncodingPrefix in the
       EncodingPrefixedType does not contain a reference encoding
       instruction.

      Aside: Case (3) and similar cases for the ATTRIBUTE-REF and
      COMPONENT-REF encoding instructions have the effect of making the
      reference encoding instructions mutually exclusive as well as
      singly occurring.

   With respect to the REF-AS-TYPE and TYPE-REF encoding instructions,
   the DefinedType in case (1) is said to be "subject to" the encoding
   instruction.

   The restrictions on the Type in the EncodingPrefixedType for an
   ATTRIBUTE-REF encoding instruction are specified in Section 9.  The
   restrictions on the Type in the EncodingPrefixedType for a
   COMPONENT-REF encoding instruction are specified in Section 10.

   The reference encoding instructions make use of a common production
   defined as follows:

      RefParameters ::= ContextParameter ?

      ContextParameter ::= "CONTEXT" AnyURIValue

   A RefParameters instance provides extra information about a reference
   to a definition.  A ContextParameter is used when a reference is
   ambiguous, i.e., refers to definitions in more than one schema
   document or external DTD subset.  This situation would occur, for
   example, when importing types with the same name from independently
   developed XML Schemas defined without a target namespace [XSD1].
   When used in conjunction with a reference to an element type in an
   external DTD subset, the AnyURIValue in the ContextParameter is the
   system identifier (a Uniform Resource Identifier or URI [URI]) of the
   external DTD subset; otherwise, the AnyURIValue is a URI that
   indicates the intended schema document, either an XML Schema
   specification, a RELAX NG specification, or an ASN.1 or ASN.X
   specification.

Top      ToC       Page 10 
7.  Expanded Names of Components

   Each NamedType has an associated expanded name [XMLNS10], determined
   as follows:

   (1) if the NamedType is subject to a NAME encoding instruction, then
       the local name of the expanded name is the character string
       specified by the NCNameValue of the NAME encoding instruction,

   (2) else if the NamedType is subject to a COMPONENT-REF encoding
       instruction, then the expanded name is the same as the expanded
       name of the referenced top-level NamedType,

   (3) else if the NamedType is subject to an ATTRIBUTE-REF or
       ELEMENT-REF encoding instruction, then the namespace name of the
       expanded name is equal to the namespace-name component of the
       QNameValue of the encoding instruction, and the local name is
       equal to the local-name component of the QNameValue,

   (4) else if the NamedType is subject to a REF-AS-ELEMENT encoding
       instruction, then the local name of the expanded name is the
       LocalPart [XMLNS10] of the qualified name specified by the
       NameValue of the encoding instruction,

   (5) otherwise, the local name of the expanded name is the identifier
       of the NamedType.

   In cases (1) and (5), if the NamedType is a top-level NamedType and
   the module containing the NamedType has a TARGET-NAMESPACE encoding
   instruction, then the namespace name of the expanded name is the
   character string specified by the AnyURIValue of the TARGET-NAMESPACE
   encoding instruction; otherwise, the namespace name has no value.

      Aside: Thus, the TARGET-NAMESPACE encoding instruction applies to
      a top-level NamedType but not to any other NamedType.

   In case (4), if the encoding instruction contains a Namespace, then
   the namespace name of the expanded name is the character string
   specified by the AnyURIValue of the Namespace; otherwise, the
   namespace name has no value.

   The expanded names for the attribute components of a CHOICE,
   SEQUENCE, or SET type MUST be distinct.  The expanded names for the
   components of a CHOICE, SEQUENCE, or SET type that are not attribute
   components MUST be distinct.  These tests are applied after the
   COMPONENTS OF transformation specified in X.680, Clause 24.4 [X.680].

Top      ToC       Page 11 
      Aside: Two components of the same CHOICE, SEQUENCE, or SET type
      may have the same expanded name if one of them is an attribute
      component and the other is not.  Note that the "not" case includes
      components that are subject to a GROUP or SIMPLE-CONTENT encoding
      instruction.

   The expanded name of a top-level NamedType subject to an ATTRIBUTE
   encoding instruction MUST be distinct from the expanded name of every
   other top-level NamedType subject to an ATTRIBUTE encoding
   instruction in the same module.

   The expanded name of a top-level NamedType not subject to an
   ATTRIBUTE encoding instruction MUST be distinct from the expanded
   name of every other top-level NamedType not subject to an ATTRIBUTE
   encoding instruction in the same module.

      Aside: Two top-level components may have the same expanded name if
      one of them is an attribute component and the other is not.

8.  The ATTRIBUTE Encoding Instruction

   The ATTRIBUTE encoding instruction causes an RXER encoder to encode a
   value of the component to which it is applied as an XML attribute
   instead of as a child element.

   The notation for an ATTRIBUTE encoding instruction is defined as
   follows:

      AttributeInstruction ::= "ATTRIBUTE"

   The base type of the type of a NamedType that is subject to an
   ATTRIBUTE 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.

Top      ToC       Page 12 
   Example

      PersonalDetails ::= SEQUENCE {
          firstName   [ATTRIBUTE] UTF8String,
          middleName  [ATTRIBUTE] UTF8String,
          surname     [ATTRIBUTE] UTF8String
      }

9.  The ATTRIBUTE-REF Encoding Instruction

   The ATTRIBUTE-REF encoding instruction causes an RXER encoder to
   encode a value of the component to which it is applied as an XML
   attribute instead of as a child element, where the attribute's name
   is a qualified name of the attribute declaration referenced by the
   encoding instruction.  In addition, the ATTRIBUTE-REF encoding
   instruction causes values of the UTF8String type to be restricted to
   conform to the type of the attribute declaration.

   The notation for an ATTRIBUTE-REF encoding instruction is defined as
   follows:

      AttributeRefInstruction ::=
          "ATTRIBUTE-REF" QNameValue RefParameters

   Taken together, the QNameValue and the ContextParameter in the
   RefParameters (if present) MUST reference an XML Schema attribute
   declaration or a top-level NamedType that is subject to an ATTRIBUTE
   encoding instruction.

   The type of a referenced XML Schema attribute declaration SHALL NOT
   be, either directly or by derivation, the XML Schema type QName,
   NOTATION, ENTITY, ENTITIES, or anySimpleType.

      Aside: Values of these types require information from the context
      of the attribute for interpretation.  Because an ATTRIBUTE-REF
      encoding instruction is restricted to prefixing the ASN.1
      UTF8String type, there is no mechanism to capture such context.

   The type of a referenced top-level NamedType SHALL NOT be, either
   directly or by subtyping, the QName type from the
   AdditionalBasicDefinitions module [RXER].

   The Type in the EncodingPrefixedType for an ATTRIBUTE-REF encoding
   instruction SHALL be either:

   (1) the UTF8String type, or

Top      ToC       Page 13 
   (2) a BuiltinType that is a PrefixedType that is a TaggedType where
       the Type in the TaggedType is one of (1) to (3), or

   (3) a BuiltinType that is a PrefixedType that is an
       EncodingPrefixedType where the Type in the EncodingPrefixedType
       is one of (1) to (3) and the EncodingPrefix in the
       EncodingPrefixedType does not contain a reference encoding
       instruction.

   The identifier of a NamedType subject to an ATTRIBUTE-REF encoding
   instruction does not contribute to the name of attributes in an RXER
   encoding.  For the sake of consistency, the identifier SHOULD, where
   possible, be the same as the local name of the referenced attribute
   declaration.

10.  The COMPONENT-REF Encoding Instruction

   The ASN.1 basic notation does not have a concept of a top-level
   NamedType and therefore does not have a mechanism to reference a
   top-level NamedType.  The COMPONENT-REF encoding instruction provides
   a way to specify that a NamedType within a combining type definition
   is equivalent to a referenced top-level NamedType.

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

      ComponentRefInstruction ::= "COMPONENT-REF" ComponentReference

      ComponentReference ::=
          InternalComponentReference |
          ExternalComponentReference

      InternalComponentReference ::= identifier FromModule ?

      FromModule ::= "FROM" GlobalModuleReference

      ExternalComponentReference ::= modulereference "." identifier

   The GlobalModuleReference production is defined by the ASN.1 basic
   notation [X.680].  If the GlobalModuleReference is absent from an
   InternalComponentReference, then the identifier MUST be the
   identifier of a top-level NamedType in the same module.  If the
   GlobalModuleReference is present in an InternalComponentReference,
   then the identifier MUST be the identifier of a top-level NamedType
   in the referenced module.

Top      ToC       Page 14 
   The modulereference in an ExternalComponentReference is used in the
   same way as a modulereference in an ExternalTypeReference.  The
   identifier in an ExternalComponentReference MUST be the identifier of
   a top-level NamedType in the referenced module.

   The Type in the EncodingPrefixedType for a COMPONENT-REF encoding
   instruction SHALL be either:

   (1) a ReferencedType that is a DefinedType that is a typereference
       (not a DummyReference) or an ExternalTypeReference, or

   (2) a BuiltinType or ReferencedType that is one of the productions in
       Table 1 in Section 5 of the specification for RXER [RXER], 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

   (4) a BuiltinType that is a PrefixedType that is an
       EncodingPrefixedType where the Type in the EncodingPrefixedType
       is one of (1) to (4) and the EncodingPrefix in the
       EncodingPrefixedType does not contain a reference encoding
       instruction.

   The restrictions on the use of RXER encoding instructions are such
   that no other RXER encoding instruction is permitted within a
   NamedType if the NamedType is subject to a COMPONENT-REF encoding
   instruction.

   The Type in the top-level NamedType referenced by the COMPONENT-REF
   encoding instruction MUST be either:

   (a) if the preceding case (1) is used, a ReferencedType that is a
       DefinedType that is a typereference or ExternalTypeReference that
       references the same type as the DefinedType in case (1), or

   (b) if the preceding case (2) is used, a BuiltinType or
       ReferencedType that is the same as the BuiltinType or
       ReferencedType in case (2), or

   (c) a BuiltinType that is a PrefixedType that is an
       EncodingPrefixedType where the Type in the EncodingPrefixedType
       is one of (a) to (c), and the EncodingPrefix in the
       EncodingPrefixedType contains an RXER encoding instruction.

   In principle, the COMPONENT-REF encoding instruction creates a
   notional NamedType where the expanded name is that of the referenced
   top-level NamedType and the Type in case (1) or (2) is substituted by
   the Type of the referenced top-level NamedType.

Top      ToC       Page 15 
   In practice, it is sufficient for non-RXER encoders and decoders to
   use the original NamedType rather than the notional NamedType because
   the Type in case (1) or (2) can only differ from the Type of the
   referenced top-level NamedType by having fewer RXER encoding
   instructions, and RXER encoding instructions are ignored by non-RXER
   encoders and decoders.

   Although any prefixes for the Type in case (1) or (2) would be
   bypassed, it is sufficient for RXER encoders and decoders to use the
   referenced top-level NamedType instead of the notional NamedType
   because these prefixes cannot be RXER encoding instructions (except,
   of course, for the COMPONENT-REF encoding instruction) and can have
   no effect on an RXER encoding.

   Example

      Modules ::= SEQUENCE OF
          module [COMPONENT-REF module
                     FROM AbstractSyntaxNotation-X
                         { 1 3 6 1 4 1 21472 1 0 1 }]
                     ModuleDefinition

      Note that the "module" top-level NamedType in the
      AbstractSyntaxNotation-X module is defined like so:

         COMPONENT module ModuleDefinition

      The ASN.X translation of the SEQUENCE OF type definition provides
      a more natural representation:

         <namedType xmlns:asnx="urn:ietf:params:xml:ns:asnx"
                    name="Modules">
          <sequenceOf>
           <element ref="asnx:module"/>
          </sequenceOf>
         </namedType>

         Aside: The <namedType> element in ASN.X corresponds to a
         TypeAssignment, not a NamedType.

   The identifier of a NamedType subject to a COMPONENT-REF encoding
   instruction does not contribute to an RXER encoding.  For the sake of
   consistency with other encoding rules, the identifier SHOULD be the
   same as the identifier in the ComponentRefInstruction.

Top      ToC       Page 16 
11.  The ELEMENT-REF Encoding Instruction

   The ELEMENT-REF encoding instruction causes an RXER encoder to encode
   a value of the component to which it is applied as an element where
   the element's name is a qualified name of the element declaration
   referenced by the encoding instruction.  In addition, the ELEMENT-REF
   encoding instruction causes values of the Markup ASN.1 type to be
   restricted to conform to the type of the element declaration.

   The notation for an ELEMENT-REF encoding instruction is defined as
   follows:

      ElementRefInstruction ::= "ELEMENT-REF" QNameValue RefParameters

   Taken together, the QNameValue and the ContextParameter in the
   RefParameters (if present) MUST reference an XML Schema element
   declaration, a RELAX NG element definition, or a top-level NamedType
   that is not subject to an ATTRIBUTE encoding instruction.

   A referenced XML Schema element declaration MUST NOT have a type that
   requires the presence of values for the XML Schema ENTITY or ENTITIES
   types.

      Aside: Entity declarations are not supported by CRXER.

   Example

      AnySchema ::= CHOICE {
          module   [ELEMENT-REF {
                       namespace-name
                           "urn:ietf:params:xml:ns:asnx",
                       local-name "module" }]
                   Markup,
          schema   [ELEMENT-REF {
                       namespace-name
                           "http://www.w3.org/2001/XMLSchema",
                       local-name "schema" }]
                   Markup,
          grammar  [ELEMENT-REF {
                       namespace-name
                           "http://relaxng.org/ns/structure/1.0",
                       local-name "grammar" }]
                   Markup
      }

      The ASN.X translation of the choice type definition provides a
      more natural representation:

Top      ToC       Page 17 
         <namedType xmlns:asnx="urn:ietf:params:xml:ns:asnx"
                    xmlns:xs="http://www.w3.org/2001/XMLSchema"
                    xmlns:rng="http://relaxng.org/ns/structure/1.0"
                    name="AnySchema">
          <choice>
           <element ref="asnx:module" embedded="true"/>
           <element ref="xs:schema" embedded="true"/>
           <element ref="rng:grammar" embedded="true"/>
          </choice>
         </namedType>

   The identifier of a NamedType subject to an ELEMENT-REF encoding
   instruction does not contribute to the name of an element in an RXER
   encoding.  For the sake of consistency, the identifier SHOULD, where
   possible, be the same as the local name of the referenced element
   declaration.

12.  The LIST Encoding Instruction

   The LIST encoding instruction causes an RXER encoder to encode a
   value of a SEQUENCE OF type as a white-space-separated list of the
   component values.

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

      ListInstruction ::= "LIST"

   The Type in an EncodingPrefixedType for a LIST encoding instruction
   SHALL be either:

   (1) a BuiltinType that is a SequenceOfType of the
       "SEQUENCE OF NamedType" form, or

   (2) a ConstrainedType that is a TypeWithConstraint of the
       "SEQUENCE Constraint OF NamedType" form or
       "SEQUENCE SizeConstraint OF NamedType" form, 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).

Top      ToC       Page 18 
   The effect of this condition is to force the LIST encoding
   instruction to be textually co-located with the SequenceOfType or
   TypeWithConstraint to which it applies.

      Aside: This makes it clear to a reader that the encoding
      instruction applies to every use of the type no matter how it
      might be referenced.

   The SequenceOfType in case (1) and the TypeWithConstraint in case (2)
   are said to be "subject to" the LIST encoding instruction.

   A SequenceOfType or TypeWithConstraint SHALL NOT be subject to more
   than one LIST encoding instruction.

   The base type of the component type of a SequenceOfType or
   TypeWithConstraint that is subject to a LIST encoding instruction
   MUST be one of the following:

   (1) the BOOLEAN, INTEGER, ENUMERATED, REAL, OBJECT IDENTIFIER,
       RELATIVE-OID, GeneralizedTime, or UTCTime type, or

   (2) the NCName, AnyURI, Name, or QName type from the
       AdditionalBasicDefinitions module [RXER].

      Aside: While it would be feasible to allow the component type to
      also be any character string type that is constrained such that
      all its abstract values have a length greater than zero and none
      of its abstract values contain any white space characters, testing
      whether this condition is satisfied can be quite involved.  For
      the sake of simplicity, only certain immediately useful
      constrained UTF8String types, which are known to be suitable, are
      permitted (i.e., NCName, AnyURI, and Name).

   The NamedType in a SequenceOfType or TypeWithConstraint that is
   subject to a LIST 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

      UpdateTimes ::= [LIST] SEQUENCE OF updateTime GeneralizedTime

Top      ToC       Page 19 
13.  The NAME Encoding Instruction

   The NAME encoding instruction causes an RXER encoder to use a
   nominated character string instead of a component's identifier
   wherever that identifier would otherwise appear in the encoding
   (e.g., as an element or attribute name).

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

      NameInstruction ::= "NAME" "AS"? NCNameValue

   Example

      CHOICE {
          foo-att   [ATTRIBUTE] [NAME AS "Foo"] INTEGER,
          foo-elem  [NAME "Foo"] INTEGER
      }

14.  The REF-AS-ELEMENT Encoding Instruction

   The REF-AS-ELEMENT encoding instruction causes an RXER encoder to
   encode a value of the component to which it is applied as an element
   where the element's name is the name of the external DTD subset
   element type declaration referenced by the encoding instruction.  In
   addition, the REF-AS-ELEMENT encoding instruction causes values of
   the Markup ASN.1 type to be restricted to conform to the content and
   attributes permitted by that element type declaration and its
   associated attribute-list declarations.

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

      RefAsElementInstruction ::=
          "REF-AS-ELEMENT" NameValue Namespace ? RefParameters

      Namespace ::= "NAMESPACE" AnyURIValue

   Taken together, the NameValue and the ContextParameter in 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 Namespace is present if and only if the Name of the referenced
   element type declaration conforms to a PrefixedName (a QName)
   [XMLNS10], in which case the Namespace specifies the namespace name
   to be associated with the Prefix of the PrefixedName.

Top      ToC       Page 20 
   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

      Suppose that the following external DTD subset has been defined
      with a system identifier of "http://www.example.com/inventory":

         <?xml version='1.0'?>
         <!ELEMENT product EMPTY>
         <!ATTLIST product
             name       CDATA #IMPLIED
             partNumber CDATA #REQUIRED
             quantity   CDATA #REQUIRED >

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

         CHOICE {
             product  [REF-AS-ELEMENT "product"
                          CONTEXT "http://www.example.com/inventory"]
                      Markup
         }

      Here is the ASN.X translation of this ASN.1 type definition:

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

   The identifier of a NamedType subject to a REF-AS-ELEMENT encoding
   instruction does not contribute to the name of an element in an RXER
   encoding.  For the sake of consistency, the identifier SHOULD, where
   possible, be the same as the Name of the referenced element type
   declaration (or the LocalPart if the Name conforms to a
   PrefixedName).



(page 20 continued on part 2)

Next RFC Part