Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 4910

Robust XML Encoding Rules (RXER) for Abstract Syntax Notation One (ASN.1)

Pages: 80
Experimental
Part 2 of 4 – Pages 15 to 34
First   Prev   Next

Top   ToC   RFC4910 - Page 15   prevText

5. Expanded Names for ASN.1 Types

A TypeAssignment in ASN.1 associates a typereference with a Type. For RXER and Abstract Syntax Notation X (ASN.X) [ASN.X], a TypeAssignment is also regarded as associating an expanded name [XMLNS10] with the Type. The local name of the expanded name is the typereference on the left-hand side of the TypeAssignment. If the target namespace [RXEREI] of the ASN.1 module in which the TypeAssignment is defined is not absent, then the namespace name of the expanded name is that target namespace; otherwise, the namespace name of the expanded name has no value. A Type that is a BuiltinType or ReferencedType that is one of the productions in Table 1 is regarded as a reference to a built-in ASN.1 type. These built-in types also have expanded names. In each case, the local name of the expanded name is as indicated in Table 1, and the namespace name of the expanded name is "urn:ietf:params:xml:ns:asnx".
Top   ToC   RFC4910 - Page 16
   Table 1: Local Names for Built-in Types

      +------------------------------------+-------------------+
      | ASN.1 Production                   | Local Name        |
      +====================================+===================+
      | BitStringType                      |                   |
      |    without a NamedBitList          | BIT-STRING        |
      +------------------------------------+-------------------+
      | BooleanType                        | BOOLEAN           |
      +------------------------------------+-------------------+
      | CharacterStringType                |                   |
      |    RestrictedCharacterStringType   |                   |
      |       BMPString                    | BMPString         |
      |       GeneralString                | GeneralString     |
      |       GraphicString                | GraphicString     |
      |       IA5String                    | IA5String         |
      |       ISO646String                 | ISO646String      |
      |       NumericString                | NumericString     |
      |       PrintableString              | PrintableString   |
      |       TeletexString                | TeletexString     |
      |       T61String                    | T61String         |
      |       UniversalString              | UniversalString   |
      |       UTF8String                   | UTF8String        |
      |       VideotexString               | VideotexString    |
      |       VisibleString                | VisibleString     |
      |    UnrestrictedCharacterStringType | CHARACTER-STRING  |
      +------------------------------------+-------------------+
      | EmbeddedPDVType                    | EMBEDDED-PDV      |
      | ExternalType                       | EXTERNAL          |
      +------------------------------------+-------------------+
      | IntegerType                        |                   |
      |    without a NamedNumberList       | INTEGER           |
      +------------------------------------+-------------------+
      | NullType                           | NULL              |
      | ObjectIdentifierType               | OBJECT-IDENTIFIER |
      | OctetStringType                    | OCTET-STRING      |
      | RealType                           | REAL              |
      | RelativeOIDType                    | RELATIVE-OID      |
      +------------------------------------+-------------------+
      | UsefulType                         |                   |
      |    GeneralizedTime                 | GeneralizedTime   |
      |    UTCTime                         | UTCTime           |
      |    ObjectDescriptor                | ObjectDescriptor  |
      +------------------------------------+-------------------+
Top   ToC   RFC4910 - Page 17
   When the expanded name for an ASN.1 type is used in an RXER encoding,
   it appears as a qualified name [XMLNS10][XMLNS11].  The namespace
   prefix for the qualified name is determined according to
   Section 6.7.11.1.

   If a compatible XML Schema translation of an ASN.1 specification is
   provided (see Section 6.4), then that schema SHOULD associate the
   same expanded name with the XML Schema translation of an ASN.1 type.

   Definition (namespace-qualified reference): An ASN.1 Type is a
   namespace-qualified reference if one of the following applies:

   (1) the Type is a typereference (not a DummyReference) or an
       ExternalTypeReference in a DefinedType in a ReferencedType, the
       ASN.1 module in which the referenced type is defined has a
       TARGET-NAMESPACE encoding instruction, the referenced type is not
       directly or indirectly an open type [X.681], and the referenced
       type is not directly or indirectly the Markup type (Section 4.1),
       or

   (2) the Type is a BuiltinType or ReferencedType that is one of the
       productions in Table 1.

   The type definition referenced by a namespace-qualified reference
   will have an expanded name with a value for the namespace name.

6. Encoding Rules

With respect to RXER, ASN.1 abstract values are uniformly regarded as analogous to the content and attributes of an element, or just an attribute value, not complete elements or attributes in their own right. Elements and attributes in an RXER encoding are defined by ASN.1 NamedType notation. Since elements are the fundamental discrete structures of an XML document, the notion of a NamedType having a value that can be encoded is useful for descriptive purposes (particularly for describing the RXER encoding of values of the ASN.1 combining types). There is no conceptual basis in X.680 [X.680] for talking about the value of a NamedType, or its encoding, so the terminology is introduced here. Definition (value of a NamedType): An abstract value of the Type in a NamedType is also a value of that NamedType. The RXER encoding of the value of a NamedType is the RXER encoding of the abstract value of the Type encapsulated according to the definition of that NamedType.
Top   ToC   RFC4910 - Page 18
   This document does not refer to a value of a NamedType as being an
   abstract value so as to remain consistent with X.680.  An abstract
   value is exclusively a value of an ASN.1 type.

   A complete ASN.1 encoding is traditionally the encoding of an
   abstract value, but it is more natural to think of an XML document as
   being the RXER encoding of a value of a NamedType (because an XML
   document has a single root element that contains all the other
   elements and attributes).  The ASN.1 basic notation does not allow a
   NamedType to appear on its own, outside of an enclosing combining
   type.  That is, the basic notation does not have a concept analogous
   to a global element or attribute definition.  However, an ASN.1
   specification may use an RXER encoding control section [RXEREI] to
   define global elements and attributes using the NamedType notation.
   A NamedType that is not contained in an ASN.1 type definition is
   called a top-level NamedType [RXEREI].  Thus, an RXER encoding would
   typically be described as the encoding of a value of a top-level
   NamedType.

   Section 6.2 describes how a value of a NamedType is encoded.
   Section 6.3 defines an alternative method for encoding the document
   element of an XML document when a top-level NamedType is not
   specified.  Section 6.4 describes how the encodings of ASN.1 values
   can be embedded in an XML document where the other parts of the
   document are validated by an XML Schema.

   The RXER encoding of an abstract value, or the encoding of a value of
   a NamedType, is described as a translation into a synthetic Infoset,
   which is then serialized as XML.  This separation has been chosen for
   descriptive convenience and is not intended to impose any particular
   architecture on RXER implementations.  An RXER encoder is free to
   encode an ASN.1 value directly to XML provided the result is
   equivalent to following the two stage procedure described in this
   document.

   The process of translating an abstract value into an Infoset is
   described as producing either:

   (1) a string of characters that either becomes part of the
       [normalized value] of an attribute item or becomes character
       items among the [children] of an enclosing element item, or

   (2) a collection of zero or more attribute items contributing to the
       [attributes] of an enclosing element item, plus a series of zero
       or more character, element, processing instruction (PI), or
       comment items contributing to the [children] of the enclosing
       element item.
Top   ToC   RFC4910 - Page 19
   NamedType notation in the ASN.1 specification controls whether the
   translation of an abstract value is encapsulated in an element item
   or in an attribute item.

   Sections 6.5 to 6.10 describe the translation of abstract values into
   an Infoset for each of the ASN.1 type notations.

   Section 6.11 describes post-processing of namespace prefixes for
   CRXER encodings.

   Section 6.12 specifies how the Infoset translation is serialized as
   XML.

   This specification assumes that the COMPONENTS OF transformation
   specified in X.680, Clause 24.4 [X.680] has already been applied to
   all relevant types.

   Examples of RXER encodings in the following sections use a <value>
   start-tag and </value> end-tag to hold attributes and delimit the
   content.  These start-tags and end-tags are for illustration only and
   are not part of the encoding of an abstract value.  In normal use,
   the name of the enclosing element is provided by the context of the
   type of the abstract value, e.g., a NamedType in an enclosing
   SEQUENCE type.

   An RXER decoder is a conforming XML processor [XML10][XML11].

6.1. Identifiers

An identifier, as defined in ASN.1 notation (Clause 11.3 of X.680 [X.680]), is a character string that begins with a Latin lowercase letter (U+0061-U+007A) and is followed by zero, one or more Latin letters (U+0041-U+005A, U+0061-U+007A), decimal digits (U+0030- U+0039), and hyphens (U+002D). A hyphen is not permitted to be the last character, and a hyphen is not permitted to be followed by another hyphen. The case of letters in an identifier is always significant. ASN.1 identifiers are used for the [local name] of attribute and element items, and may also appear in the character data content of elements or the values of attributes. RXER encoding instructions can be used to substitute an NCName [XMLNS10] for an identifier.
Top   ToC   RFC4910 - Page 20

6.2. Component Encodings

The translation of the value of a NamedType is the translation of the abstract value of the Type of the NamedType encapsulated according to the definition of that NamedType. This section specifies the form of this encapsulation.

6.2.1. Referenced Components

A value of a NamedType that is subject to a COMPONENT-REF encoding instruction is translated as a value of the top-level NamedType referenced by the encoding instruction.

6.2.2. Element Components

A value of a NamedType that is not subject to an ATTRIBUTE, ATTRIBUTE-REF, GROUP, or SIMPLE-CONTENT encoding instruction is translated as an element item, either as a child element item added to the [children] of the enclosing element item or as the document element item added to the [children] and [document element] of the document item. If the element item is a child element item, then the [parent] is the enclosing element item; otherwise, the [parent] is the document item. The [local name] of the element item is the local name of the expanded name of the NamedType (see [RXEREI]). Aside: If there are no NAME, ATTRIBUTE-REF, COMPONENT-REF, ELEMENT-REF, or REF-AS-ELEMENT encoding instructions, then the local name of the expanded name of a NamedType is the same as the identifier of the NamedType. If the namespace name of the expanded name has no value, then the [namespace name] of the element item has no value (i.e., the element's name is not namespace qualified); otherwise, the [namespace name] is the namespace name of the expanded name. If the type of the NamedType is directly or indirectly the Markup type, then the [in-scope namespaces] and [namespace attributes] of the element item are constructed as specified in Section 6.10; otherwise, the [in-scope namespaces] and [namespace attributes] of the element item are constructed as specified in Section 6.2.2.1. If the [namespace name] of the element item has no value, then the [prefix] of the element item has no value; else if the type of the NamedType is not directly or indirectly the Markup type, then the
Top   ToC   RFC4910 - Page 21
   [prefix] of the element item is determined as specified in
   Section 6.2.2.2; otherwise, the [prefix] is determined by the Markup
   value as specified in Section 6.10.

   The element item becomes the enclosing element item for the
   translation of the value of the Type of the NamedType.

   For a non-canonical RXER encoding, if the type of the NamedType is
   not directly or indirectly the Markup type, then PI and comment items
   MAY be added to the [children] of the element item (before or after
   any other items).  The element item becomes the [parent] for each PI
   and comment item.  These particular PI and comment items in a
   received RXER encoding MAY be discarded by an application.

      Aside: There is no provision for representing comments and PIs in
      ASN.1 abstract values of types other than the Markup type.  These
      items will be lost if the abstract value is re-encoded using a
      different set of encoding rules.

   For a non-canonical RXER encoding, an attribute item with the
   [local name] "type" and the [namespace name]
   "http://www.w3.org/2001/XMLSchema-instance" (i.e., xsi:type [XSD1])
   SHOULD be added to the [attributes] of the element item if the
   corresponding NamedType is subject to a TYPE-AS-VERSION encoding
   instruction and MAY be added to the [attributes] of the element item
   if the Type of the corresponding NamedType is a namespace-qualified
   reference (see Section 5).  The [prefix] of this attribute item is
   determined as specified in Section 6.2.3.1.  The [normalized value]
   of this attribute item is a qualified name for the expanded name of
   the referenced type, with the namespace prefix determined as
   specified in Section 6.7.11.1.  The element item is the
   [owner element] for the attribute item.

      Aside: Where a compatible XML Schema translation of the ASN.1
      specification has been provided, the xsi:type attribute indicates
      to an XML Schema validator which type definition it should use for
      validating the RXER encoding.

      Aside: An xsi:type attribute is generally not permitted in a CRXER
      encoding.  Section 6.4 describes some circumstances where it is
      required in a CRXER encoding.  An xsi:type attribute might also
      appear in a CRXER encoding if it is contained in a value of the
      Markup type.

   For a non-canonical RXER encoding, if the type of the NamedType is
   not directly or indirectly the Markup type, then attribute items with
   the [local name] "schemaLocation" or "noNamespaceSchemaLocation" and
   the [namespace name] "http://www.w3.org/2001/XMLSchema-instance"
Top   ToC   RFC4910 - Page 22
   [XSD1] MAY be added to the [attributes] of the element item.  The
   [prefix] for each of these attribute items is determined as specified
   in Section 6.2.3.1.  The [normalized value] of these attribute items
   MUST reference a compatible XML Schema translation of the ASN.1
   specification.  The element item is the [owner element] for the
   attribute items.

6.2.2.1. Namespace Properties for Elements
This section describes how the [in-scope namespaces] and [namespace attributes] of an element item are constructed when the content and attributes of the element item are not described by a value of the Markup type (otherwise, see Section 6.10). The [in-scope namespaces] property of the element item initially contains only the mandatory namespace item for the "xml" prefix [INFOSET]. For a CRXER encoding, if the element item is not the [document element] of the document item and the [in-scope namespaces] property of the element item's [parent] contains a namespace item for the default namespace, then a namespace declaration attribute item that undeclares the default namespace (see Section 3) SHALL be added to the element item's [namespace attributes]. Definition (default namespace restricted): With respect to an element item, the default namespace is restricted if: (1) the [namespace name] of the element item has no value (i.e., the element's name is not namespace qualified), or (2) the element item is the enclosing element item for a value of the UNION type where the member attribute will be required (see Section 6.7.14), or (3) the element item is the enclosing element item for a value of the QName type where the namespace-name component is absent (see Section 6.7.11). This includes the case where the translation of the QName value is contained in the [normalized value] of an attribute item in the [attributes] of the element item. For a non-canonical RXER encoding, if the element item is not the [document element] of the document item and the [in-scope namespaces] property of the element item's [parent] contains a namespace item for the default namespace, then either: (1) that item is copied to the [in-scope namespaces] of the element item, or
Top   ToC   RFC4910 - Page 23
   (2) a namespace declaration attribute item that declares the default
       namespace is added to the element item's [namespace attributes]
       (the namespace name is the encoder's choice), and an equivalent
       namespace item is added to the [in-scope namespaces] of the
       element item, or

   (3) a namespace declaration attribute item that undeclares the
       default namespace is added to the element item's
       [namespace attributes].

   Options (1) and (2) SHALL NOT be used if the default namespace is
   restricted with respect to the element item.

   For a CRXER encoding, if the element item is not the
   [document element] of the document item and the element item is not
   required to be self-contained, then all the namespace items in the
   [in-scope namespaces] of the [parent], excluding the namespace item
   for the "xml" prefix and any namespace item for the default
   namespace, are copied to the [in-scope namespaces] of the element
   item.

   For a non-canonical RXER encoding, if the element item is not the
   [document element] of the document item and the element item is not
   required to be self-contained, then any subset (including none or
   all) of the namespace items in the [in-scope namespaces] of the
   [parent], excluding certain items, is copied to the
   [in-scope namespaces] of the element item.  The excluded items that
   MUST NOT be copied are:  the namespace item for the "xml" prefix, any
   namespace item for the default namespace, and any namespace item that
   matches the [prefix], but not the [namespace name], of a namespace
   item retained for the re-encoding of an unknown attribute item (see
   Section 6.8.8) or an unknown alternative of a UNION (see
   Section 6.7.14).

      Aside: The descriptive approach used by this document only allows
      a namespace prefix to be used by a new namespace item if it is not
      currently used by another namespace item in the
      [in-scope namespaces].  By not inheriting a namespace item, the
      prefix of that namespace is again available for reuse without fear
      of breaking an existing dependency on the prefix.

   Element items that are required to be self-contained inherit none of
   the namespace items in the [in-scope namespaces] of the [parent].

   Any namespace item that is retained for the re-encoding of an unknown
   attribute item (Section 6.8.8) or an unknown alternative of a UNION
   (Section 6.7.14) and which is not in the [in-scope namespaces] of the
   element item MUST be added to the [in-scope namespaces].  An
Top   ToC   RFC4910 - Page 24
   equivalent namespace declaration attribute item MUST be added to the
   [namespace attributes] of the element item.

   Definition (unused namespace prefix): A namespace prefix is unused if
   it does not match the [prefix] of any namespace item in the
   [in-scope namespaces] of the element item.

   For a non-canonical RXER encoding, if the type of the NamedType is
   not directly or indirectly the Markup type, then additional namespace
   declaration attribute items for currently unused namespace prefixes
   MAY be added to the [namespace attributes] of the element item.  An
   equivalent namespace item MUST be added to the [in-scope namespaces]
   of the element item for each additional namespace declaration
   attribute item.

   For a non-canonical RXER encoding, if the type of the NamedType is
   not directly or indirectly the Markup type, and the
   [in-scope namespaces] property of the element item does not contain a
   namespace item for the default namespace, and the default namespace
   is not restricted with respect to the element item, then a namespace
   declaration attribute item for the default namespace MAY be added to
   the [namespace attributes] of the element item, in which case an
   equivalent namespace item MUST be added to the [in-scope namespaces]
   of the element item.

   Whenever a namespace declaration attribute item is added to an
   element item's [namespace attributes], the [owner element] of the
   attribute item is set to the element item.

6.2.2.2. Namespace Prefixes for Element Names
This section describes how the [prefix] of an element item is determined when the element item has a value for its [namespace name] and the content and attributes of the element item are not described by a value of the Markup type (otherwise, see Section 6.10). For a CRXER encoding, if the [namespace name] of the element item has a value, then the [prefix] of the element item is any unused non-canonical namespace prefix unless the [in-scope namespaces] property of the element item contains a namespace item with the same [namespace name] as the element item. In that case, the [prefix] of that namespace item SHALL be used as the [prefix] of the element item. Aside: These prefixes will be rewritten to canonical namespace prefixes during the final step in producing the Infoset translation (see Section 6.11). Canonical namespace prefixes are not used here in the first instance because canonicalization
Top   ToC   RFC4910 - Page 25
      depends on knowing the final [namespace attributes] produced by
      encoding the abstract value of the type of the NamedType.  If an
      implementation looks ahead to determine this final set prior to
      translating the abstract value, then it can assign the appropriate
      canonical namespace prefix in this step and skip the rewriting
      step.

   For a non-canonical RXER encoding, if the [namespace name] has a
   value, then the [prefix] of the element item is any unused namespace
   prefix unless the [in-scope namespaces] property of the element item
   contains a namespace item with the same [namespace name] as the
   element item.  In that case, the [prefix] of that namespace item MAY
   be used as the [prefix] of the element item.  Note that the [prefix]
   of a namespace item for the default namespace has no value.

   If the [prefix] of the element item is an unused namespace prefix,
   then a namespace declaration attribute item associating the namespace
   prefix with the namespace name MUST be added to the
   [namespace attributes] of the element item, and a corresponding
   namespace item MUST be added to the [in-scope namespaces] of the
   element item.

      Aside: The [local name] of the namespace declaration attribute
      item is the same as the [prefix] of the element item, the
      [namespace name] of the attribute item is
      "http://www.w3.org/2000/xmlns/", and the [normalized value] of the
      attribute item is the same as the [namespace name] of the element
      item.  The namespace item has the same [prefix] and
      [namespace name] as the element item.

6.2.3. Attribute Components

A value of a NamedType subject to an ATTRIBUTE or ATTRIBUTE-REF encoding instruction is translated as an attribute item added to the [attributes] of the enclosing element item (which becomes the [owner element] of the attribute item). The [local name] of the attribute item is the local name of the expanded name of the NamedType (see [RXEREI]). If the namespace name of the expanded name has no value, then the [namespace name] of the attribute item has no value; otherwise, the [namespace name] is the namespace name of the expanded name. If the [namespace name] has a value, then the [prefix] of the attribute item is determined as specified in Section 6.2.3.1; otherwise, the [prefix] of the attribute item has no value.
Top   ToC   RFC4910 - Page 26
   The [normalized value] of the attribute item is the translation of
   the value of the Type of the NamedType.

   For completeness, the [specified] property is set to true, the
   [attribute type] has no value, and the value of the [references]
   property is set to unknown.

6.2.3.1. Namespace Prefixes for Attribute Names
This section applies when an attribute item with a value for its [namespace name] is added to the [attributes] of an element item. For a CRXER encoding, the [prefix] of the attribute item is any unused non-canonical namespace prefix unless the [in-scope namespaces] property of the [owner element] contains a namespace item with a value for the [prefix] (i.e., is not a namespace item for the default namespace) and the same [namespace name] as the attribute item. In that case, the [prefix] of that namespace item SHALL be used as the [prefix] of the attribute item. For a non-canonical RXER encoding, the [prefix] of the attribute item is any unused namespace prefix unless the [in-scope namespaces] property of the [owner element] contains a namespace item with a value for the [prefix] and the same [namespace name] as the attribute item. In that case, the [prefix] of that namespace item MAY be used as the [prefix] of the attribute item. If the [prefix] of the attribute item is an unused namespace prefix, then a namespace declaration attribute item associating the namespace prefix with the namespace name MUST be added to the [namespace attributes] of the [owner element], and a corresponding namespace item MUST be added to the [in-scope namespaces] of the [owner element].

6.2.4. Unencapsulated Components

A value of a NamedType subject to a GROUP or SIMPLE-CONTENT encoding instruction is translated as the value of the Type of the NamedType, i.e., without encapsulation in an element item or attribute item. Consequently, the enclosing element item for the translation of the value of the NamedType is also the enclosing element item for the translation of the value of the Type of the NamedType.
Top   ToC   RFC4910 - Page 27

6.2.5. Examples

Consider this type definition: CHOICE { one [0] BOOLEAN, two [1] [RXER:ATTRIBUTE] INTEGER, three [2] [RXER:NAME AS "THREE"] OBJECT IDENTIFIER, four [3] [RXER:ATTRIBUTE-REF { namespace-name "http://www.example.com", local-name "foo" }] UTF8String, five [4] [RXER:ELEMENT-REF { namespace-name "http://www.example.com", local-name "bar" }] Markup, six [5] [RXER:GROUP] SEQUENCE { seven [0] [RXER:ATTRIBUTE] INTEGER, eight [1] INTEGER } } The content and attributes of each of the following <value> elements are the RXER encoding of a value of the above type: <value> <one>true</one> </value> <value two="100"/> <value> <THREE>2.5.4.3</THREE> </value> <value xmlns:ex="http://www.example.com" ex:foo="a string"/> <value> <ex:bar xmlns:ex="http://www.example.com">another string</ex:bar> </value> <value seven="200"> <eight>300</eight> </value>
Top   ToC   RFC4910 - Page 28

6.3. Standalone Encodings

A typical RXER encoding is the encoding of a value of a nominated top-level NamedType. An abstract value MAY be encoded as an XML document without nominating an explicit top-level NamedType by invoking a Standalone RXER Encoding or Standalone CRXER Encoding. In a Standalone RXER Encoding or Standalone CRXER Encoding, the abstract value is encoded as the value of a notional NamedType where the identifier of the NamedType is "value" and the Type of the NamedType is the type of the abstract value. The NamedType is assumed to be subject to no encoding instructions. Aside: Thus, the element item corresponding to the document element will have the [local name] "value" and no value for the [namespace name] and [prefix]. If RXER is chosen as the transfer syntax in an EMBEDDED PDV value, then the data-value OCTET STRING SHALL contain a Standalone RXER encoding. If CRXER is chosen as the transfer syntax in an EMBEDDED PDV value, then the data-value OCTET STRING SHALL contain a Standalone CRXER encoding. If RXER is chosen as the transfer syntax in an EXTERNAL value, then the octet-aligned OCTET STRING or arbitrary BIT STRING SHALL contain a Standalone RXER encoding. If CRXER is chosen as the transfer syntax in an EXTERNAL value, then the octet-aligned OCTET STRING or arbitrary BIT STRING SHALL contain a Standalone CRXER encoding.

6.4. Embedded ASN.1 Values

The reference encoding instructions [RXEREI] allow XML Schema definitions to be referenced from an ASN.1 specification. It is also possible to reference an ASN.1 type or top-level NamedType from an XML Schema definition or from an information item validated by an XML Schema wildcard. The manner in which an XML Schema definition references an ASN.1 type or top-level NamedType has an effect on the CRXER encoding of a value of the type or top-level NamedType. This section also applies to XML Schema definitions that validate information items that are contained in a value of the Markup type.
Top   ToC   RFC4910 - Page 29
      Aside: So the document element of an XML document might be
      described by an XML Schema definition that at some point
      references an ASN.1 definition that uses a reference encoding
      instruction to reference another XML Schema definition that then
      references another ASN.1 definition, and so on.

   In each of the following cases, an element or attribute item is only
   permitted to be, or to encapsulate, an RXER Infoset translation of an
   ASN.1 value if an XML Schema element declaration or ASN.1 NamedType
   is known for the [parent] element item ([owner element] in the case
   of an attribute declaration), for the [parent] of the [parent]
   element item, and so on, to the document element of the XML document.
   This condition is not satisfied by a NamedType where the Type is
   directly or indirectly the Markup type and the NamedType is not
   subject to a reference encoding instruction.

      Aside: An element declaration becomes known for an element item
      through assessment [XSD1].  A NamedType becomes known for an
      element item through decoding.

      Aside: If an XML Schema element declaration or ASN.1 NamedType is
      not known for an element item, then the type of the element item
      and the type of every nested element item are treated as unknown.
      Although an xsi:type attribute definitively identifies the type of
      an element item even if an element declaration for the element
      item is not known, this attribute is generally optional in an RXER
      encoding and so cannot be relied upon when seen in isolation from
      an element declaration.  Although only top-level NamedType
      instances can have namespace-qualified names in the current RXER
      specification, a future version may allow nested NamedType
      instances to also have namespace-qualified names, in which case it
      will not necessarily be possible to distinguish a nested NamedType
      from a top-level NamedType without knowledge of the type of the
      [parent] element item.

   An ASN.1 type with an expanded name (Section 5) MAY be referenced by
   the type attribute of an XML Schema element declaration.  The
   reference takes the form of a qualified name for the expanded name.
   An element item validated by such an element declaration encapsulates
   the Infoset translation of an abstract value of the ASN.1 type.  The
   [namespace name] and [local name] of the element item are determined
   by the XML Schema element declaration.  The remaining properties are
   determined according to RXER.  The element item MUST be
   self-contained for a CRXER encoding.

      Aside: The element item is not required to be self-contained for a
      non-canonical RXER encoding.
Top   ToC   RFC4910 - Page 30
   A top-level NamedType MAY be referenced by the ref attribute of an
   XML Schema element declaration if the NamedType is not subject to an
   ATTRIBUTE encoding instruction.  The reference takes the form of a
   qualified name for the expanded name of the top-level NamedType
   [RXEREI].  An element item validated by such an element declaration
   is the Infoset translation of a value of the referenced top-level
   NamedType.  All the properties of the element item are determined
   according to RXER.  The element item MUST be self-contained for a
   CRXER encoding.

   A top-level NamedType MAY be referenced by the ref attribute of an
   XML Schema attribute declaration if the NamedType is subject to an
   ATTRIBUTE encoding instruction and the definition of the type of the
   NamedType does not depend on the QName type in any way.  An attribute
   item validated by such an attribute declaration is the Infoset
   translation of a value of the referenced top-level NamedType, except
   that whatever valid [prefix] is initially chosen for the attribute
   item MUST be preserved in any re-encoding.  The remaining properties
   of the attribute item are determined according to RXER.

      Aside: The exclusion of the QName type means that the attribute
      value is not dependent upon any namespace declarations of its
      parent element item.

   An element item that is validated by an XML Schema element
   declaration that has the ur-type (i.e., anyType) as its type
   definition MAY encapsulate the Infoset translation of a value of an
   ASN.1 type with an expanded name.  The [namespace name] and
   [local name] of the element item are determined by the XML Schema
   element declaration.  The remaining properties of the element item
   are determined according to RXER.  The [attributes] of the element
   item SHALL contain an attribute item with the [local name] "type" and
   the [namespace name] "http://www.w3.org/2001/XMLSchema-instance"
   (i.e., an xsi:type attribute).  The [prefix] of this attribute item
   is determined as specified in Section 6.2.3.1.  The
   [normalized value] of this attribute item is a qualified name for the
   expanded name of the ASN.1 type, with the namespace prefix determined
   as specified in Section 6.7.11.1.  The element item MUST be
   self-contained for a CRXER encoding.

   An element item that is validated by an XML Schema wildcard (i.e.,
   <xs:any/>) MAY be the Infoset translation of a value of a top-level
   NamedType that is not subject to an ATTRIBUTE encoding instruction
   and comes from an ASN.1 module with a target namespace [RXEREI] that
   satisfies the namespace constraint of the wildcard.  All the
   properties of the element item are determined according to RXER.  The
   element item MUST be self-contained for a CRXER encoding.
Top   ToC   RFC4910 - Page 31
   An attribute item that is validated by an XML Schema wildcard (i.e.,
   <xs:anyAttribute/>) MAY be the Infoset translation of a value of a
   top-level NamedType if the NamedType is subject to an ATTRIBUTE
   encoding instruction, comes from an ASN.1 module with a target
   namespace that satisfies the namespace constraint of the wildcard,
   and has a type that does not depend on the QName type in any way.
   Whatever valid [prefix] is initially chosen for the attribute item
   MUST be preserved in any re-encoding.  The remaining properties of
   the attribute item are determined according to RXER.

   No other mechanisms for referencing an ASN.1 type or top-level
   NamedType from a different XML schema language are supported in this
   version of RXER.  In particular, this excludes an ASN.1 type being
   used as the base type in an XML Schema derivation by extension or
   restriction, as a member type for an XML Schema union type, as an
   item type for an XML Schema list type, or as the type in an
   XML Schema attribute declaration.

   A fully conformant RXER implementation will understand both ASN.1 and
   XML Schema and will recognize the transitions between information
   items controlled by ASN.1 definitions and those controlled by
   XML Schema definitions.  However, a purely XML Schema validator used
   to assess the validity of an RXER encoding will perceive any
   reference to an ASN.1 type or top-level NamedType as an unresolved
   reference.  In order to enable such assessment, it is desirable to
   provide an XML Schema translation of the ASN.1 definitions being
   referenced from an XML Schema.  Although XML Schema and ASN.1 are
   broadly similar, they each have unique features that cannot be
   adequately expressed in the other language, so a semantically
   equivalent translation is not possible in the general case.
   Fortunately, to simply achieve successful assessment it is sufficient
   for the XML Schema translation of an ASN.1 specification to be
   compatible with that ASN.1 specification.  That is, the XML Schema
   translation MUST be constructed such that every correct RXER encoding
   is assessed as valid.  Although not ideal, it is acceptable for the
   XML Schema to assess some incorrect RXER encodings as also being
   valid (a conformant RXER decoder will, of course, reject such an
   encoding).

   The simplest compatible XML Schema translation of an ASN.1 module is
   one in which every type is equivalent to the XML Schema ur-type.  For
   example, given an ASN.1 type with the reference name MyType, a
   sufficient compatible XML Schema type definition is:
Top   ToC   RFC4910 - Page 32
      <xs:complexType name="MyType" mixed="true">
       <xs:sequence>
        <xs:any processContents="lax"
                 minOccurs="0" maxOccurs="unbounded"/>
       </xs:sequence>
       <xs:anyAttribute processContents="lax"/>
      </xs:complexType>

          OR

      <xs:complexType name="MyType">
       <xs:complexContent>
        <xs:extension base="xs:anyType"/>
       </xs:complexContent>
      </xs:complexType>

      Aside: Because of the possible presence of an asnx:context
      attribute (Section 6.8.8.1), it is easiest to assume that all
      ASN.1 types translate into XML Schema complex types.

   Given an ASN.1 top-level NamedType that is not subject to an
   ATTRIBUTE encoding instruction and has the reference name myElement,
   a sufficient compatible XML Schema element declaration is:

      <xs:element name="myElement"/>

   Given an ASN.1 top-level NamedType that is subject to an ATTRIBUTE
   encoding instruction and has the reference name myAttribute, a
   sufficient compatible XML Schema attribute declaration is:

      <xs:attribute name="myAttribute"/>

   An application specification that mixes ASN.1 and XML Schema is free
   to provide a stricter translation of its ASN.1 definitions; however,
   a more thorough treatment for translating an ASN.1 module into an
   XML Schema is out of scope for this document.

6.5. Type Referencing Notations

A value of a type with a defined type name is translated according to the type definition on the right-hand side of the type assignment for the type name. A value of a type denoted by the use of a parameterized type with actual parameters is translated according to the parameterized type with the DummyReferences [X.683] substituted with the actual parameters.
Top   ToC   RFC4910 - Page 33
   A value of a constrained type is translated as a value of the type
   without the constraint.  See X.680 [X.680] and X.682 [X.682] for the
   details of ASN.1 constraint notation.

   A prefixed type [X.680-1] associates an encoding instruction with a
   type.  A value of a prefixed type is translated as a value of the
   type without the prefix.

      Aside: This does not mean that RXER encoding instructions are
      ignored.  It is simply easier to describe their effects in
      relation to specific built-in types, rather than as the
      translation of a value of a prefixed type.

   A tagged type is a special case of a prefixed type.  A value of a
   tagged type is translated as a value of the type without the tag.
   ASN.1 tags do not appear in the XML encodings defined by this
   document.

   A value of a fixed type denoted by an ObjectClassFieldType is
   translated according to that fixed type (see Section 6.9 for the case
   of an ObjectClassFieldType denoting an open type).

   A value of a selection type is translated according to the type
   referenced by the selection type.  Note that component encoding
   instructions are not inherited by the type referenced by a selection
   type [RXEREI].

   A value of a type described by TypeFromObject notation [X.681] is
   translated according to the denoted type.

   A value of a type described by ValueSetFromObjects notation [X.681]
   is translated according to the governing type.

6.6. TypeWithConstraint, SEQUENCE OF Type, and SET OF Type

For the purposes of this document, a TypeWithConstraint is treated as if it were the parent type [X.680] (either a SEQUENCE OF or SET OF type). For example, SEQUENCE SIZE(1..MAX) OF SomeType is treated like SEQUENCE OF SomeType
Top   ToC   RFC4910 - Page 34
   Additionally, a "SEQUENCE OF Type" (including the case where it is
   the parent type for a TypeWithConstraint) is treated as if it were a
   "SEQUENCE OF NamedType", where the identifier of the NamedType is
   assumed to be "item".  Similarly, a "SET OF Type" (including the case
   where it is the parent type for a TypeWithConstraint) is treated as
   if it were a "SET OF NamedType", where the identifier of the
   NamedType is assumed to be "item".

   For example,

      SEQUENCE SIZE(1..MAX) OF SomeType

         is ultimately treated like

      SEQUENCE OF item SomeType



(page 34 continued on part 3)

Next Section