[要約] RFC 4911は、Robust XML Encoding Rules（RXER）のエンコーディング指示に関するドキュメントです。このRFCの目的は、RXERを使用してXMLデータを効果的にエンコードするための指針を提供することです。
Network Working Group S. Legg
Request for Comments: 4911 eB2Bcom
Category: Experimental July 2007
Encoding Instructions for the Robust XML Encoding Rules (RXER)
堅牢なXMLエンコードルール（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).
著作権（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.
このドキュメントでは、抽象的構文表記1（asn.1）仕様で使用されるエンコード命令を定義して、asn.1値が堅牢なXMLエンコードルール（RXER）および標準的な堅牢なXMLエンコードルール（CRXER）によってエンコードされる方法を変更する方法を変更します。たとえば、ASN.1値のコンポーネントを、子要素としてではなく、拡張可能なマークアップ言語（XML）属性としてエンコードします。これらのエンコード命令のいくつかは、asn.1仕様が抽象的構文表記x（asn.x）仕様にどのように変換されるかにも影響します。他のXMLスキーマ言語の定義を参照するためにASN.1仕様を許可する指示のエンコードも定義されています。
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
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].
このドキュメントでは、抽象的構文表記1（asn.1）[x.680]仕様で使用できるエンコード命令[x.680-1]を定義します。）[rxer]および標準的な堅牢なXMLエンコードルール（crxer）[rxer]、たとえば、asn.1値のコンポーネントを拡張可能なマークアップ言語（xml）[xml10]属性としてエンコードします。これらのエンコード命令のいくつかは、asn.1仕様が抽象的な構文表記x（asn.x）仕様[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.
このドキュメントでは、ASN.1の仕様が他のXMLスキーマ言語で記述された仕様にタイプ、要素、および属性の定義を組み込むことを可能にするエンコード命令も定義しています。XMLスキーマ[XSD1]タイプ、要素、および属性への参照、リラックスNG [RNG]という名前のパターンと要素、およびXMLドキュメントタイプ定義（DTD）[XML10]要素タイプがサポートされています。
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.
ほとんどの場合、エンコーディング命令の効果は、このドキュメントで簡単に言及されています。これらのエンコード命令の正確な効果は、それらが適用されるポイントで、Rxer [rxer]およびasn.x [asn.x]の仕様で完全に説明されています。
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.
「必須」、「必要」、「必須」、「「shall」、「shall」、「wuth」、「ofs」、 "buld"、 "becommended" and "may"は、記載されているように解釈されるべきです。BCP 14、RFC 2119 [BCP14]。キーワード「オプション」は、そのasn.1の意味でのみ使用されます。
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.
このドキュメント全体を通して、「タイプ」はASN.1タイプを意味すると見なされ、「値」は、特に適格でない限り、asn.1抽象値を意味すると見なされます。
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.
ASN.1生産[X.680]（例：Type、namedType）への参照は、その生産に対応するASN.1仕様のテキストへの参照です。このドキュメント全体で、「コンポーネント」はnamedTypeと同義です。
This document uses the namespace prefix "xsi:" to stand for the namespace name [XMLNS10] "http://www.w3.org/2001/XMLSchema-instance".
このドキュメントでは、名前空間プレフィックス「XSI：」を使用して、名前空間名[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".
このドキュメントのASN.1定義の例は、「自動タグ」のTagDefaultと「rxer Instructions」のエンコーディングリファレンスエフォルト[x.680-1]を備えたasn.1モジュールで定義されていると想定されています。
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.
定義（ベースタイプ）：タイプのtが制約されたタイプの場合、tのベースタイプは制約されている型のベースタイプです。それ以外の場合は、tがプレフィックス型の場合、tのベースタイプは、プレフィックスされたタイプのベースタイプです。それ以外の場合は、Tが別のタイプ（つまり、DefinedType、ObjectClassFieldType、SelectionType、TypefromObject、またはValueSetFromObjects）を参照または示すタイプ表記である場合、Tのベースタイプは参照または示されるタイプのベースタイプです。それ以外の場合、tのベースタイプはtそれ自体です。
Aside: A tagged type is a special case of a prefixed type.
さておき：タグ付きタイプは、接頭型タイプの特別なケースです。
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.
ASN.1の文法では、タイプのプレフィックスとエンコード制御セクションを介して、エンコード命令[x.680-1]の適用を許可します。これにより、指名されたエンコードルールによって抽象値がエンコードされる方法が変更されます。
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.
タイププレフィックスとエンコード制御セクションの汎用表記は、asn.1基本表記[x.680] [x.680-1]によって定義され、エンコード命令によって影響を受ける特定のエンコードルールを識別するエンコーディングリファレンスが含まれています。
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.
堅牢なXMLエンコードルールを識別するエンコーディングリファレンスは、文字通りRxerです。RXERエンコーディング命令は、RXERエンコーディングとCRXERエンコーディングの両方に等しく適用されます。
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.
エンコードルールの特定のセットのエンコード命令の特定の表記は、それらのエンコードルールの仕様に任されています。その結果、RXER仕様[RXER]のこのコンパニオンドキュメントは、RXERエンコード命令の表記を定義します。具体的には、ASN.1の基本表記のエンコーディンインストラクションとエンコーディンインストルアクセスのプレースホルダープロダクションを詳しく説明します。
In the context of the RXER encoding reference, the EncodingInstruction production is defined as follows, using the conventions of the ASN.1 basic notation:
RXERエンコーディングリファレンスのコンテキストでは、asn.1基本表記の規則を使用して、エンコーディンインストラクションの生成が次のように定義されます。
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:
RXERエンコーディングリファレンスのコンテキストでは、EncodingInstructionAssignmentListの生成（エンコード制御セクションにのみ表示）は次のように定義されます。
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.
定義（トップレベルのAngementType）：AnightTypeは、トップレベルコンポーネントのnamedTypeである場合にのみ、トップレベルのnamedType（同等に、トップレベルコンポーネント）です。ToplevelComponentの名前のdamentTypeのタイプ内にネストされたnamedTypeは、それ自体がトップレベルの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.
さておき：仕様ライターは、トップレベルのnamedType内で定義されている非自明なタイプがASN.1 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.
トップレベルのnamedTypeはRXERエンコード制御セクションにのみ表示されますが、モジュール[x.680-1]のデフォルトのエンコーディングリファレンスは、トップレベルのnamedTypeを解析する場合でも適用されます。
Each top-level NamedType within a module SHALL have a distinct identifier.
モジュール内の各トップレベルのnamedTypeには、明確な識別子が必要です。
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:
damendType生産は、ASN.1基本表記によって定義されます。他の作品については、後続のセクションで説明し、次のプロダクションを使用します。
NCNameValue ::= Value
AnyURIValue ::= Value
QNameValue ::= Value
NameValue ::= Value
The Value production is defined by the ASN.1 basic notation.
値の生成は、ASN.1基本表記によって定義されます。
The governing type for the Value in an NCNameValue is the NCName type from the AdditionalBasicDefinitions module [RXER].
NCNameValueの値の管理タイプは、追加のBasicDefinitionsモジュール[RXER]のNCNAMEタイプです。
The governing type for the Value in an AnyURIValue is the AnyURI type from the AdditionalBasicDefinitions module.
Anyurivalueの値の管理タイプは、追加のBasicDefinitionsモジュールのAnyuriタイプです。
The governing type for the Value in a QNameValue is the QName type from the AdditionalBasicDefinitions module.
QNameValueの値の管理タイプは、追加のBasicDefinitionsモジュールのQNameタイプです。
The governing type for the Value in a NameValue is the Name type from the AdditionalBasicDefinitions module.
NameValueの値の管理タイプは、追加のBasicDefinitionsモジュールの名前タイプです。
The Value in an NCNameValue, AnyURIValue, QNameValue, or NameValue SHALL NOT be a DummyReference [X.683] and SHALL NOT textually contain a nested DummyReference.
ncnamevalue、anyurivalue、qnamevalue、またはnamevalueの値は、dummyreference [x.683]ではなく、ネストされた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.
さておき：したがって、エンコーディング命令は、いかなる方法でもパラメーター化されることは許可されていません。ASN.Xの将来の仕様が、現在の仕様のようにパラメーター化された参照を展開するのではなく、パラメーター化された定義とパラメーター化された参照を明示的に表す場合、この制限が重要になります。パラメーター化された定義は、完全に指定されていないエンコード命令が含まれていた場合、asn.xに直接変換することはできませんでした。
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, ElementRefInstruction, NameInstruction, RefAsElementInstruction, SimpleContentInstruction, TypeAsVersionInstruction, and VersionIndicatorInstruction).
RXERエンコード命令の特定は、コンポーネントエンコード命令として分類されます。コンポーネントエンコーディング命令は、属性、属性-ref、コンポーネント-ref、グループ、要素ref、名前、ref-as-content、simple-content、version-as-version、およびversion-indicatorエンコード命令（表記法ですそれぞれ属性導入、属性内導入、コンポーネント再導入、グループ拡張、元素導入、逆導入、リファセルメント導入、simplecontentintintruction、typeAssioniontruction、およびversionindicatorInstruction）によって説明されています。
The Type in the EncodingPrefixedType for a component encoding instruction SHALL be either:
コンポーネントエンコーディング命令のencodingPrefixedTypeのタイプは次のとおりです。
(1) the Type in a NamedType, or
(1) aknigntypeのタイプ、または
(2) the Type in an EncodingPrefixedType in a PrefixedType in a BuiltinType in a Type that is one of (1) to (4), or
(2) （1）から（4）、またはまたは（または（4）、または
(3) the Type in an TaggedType in a PrefixedType in a BuiltinType in a Type that is one of (1) to (4), or
(3) （1）〜（4）、または（または（4）、または）の1つのタイプの組み込み型の接頭辞dtypeのtaggedTypeのタイプ
(4) the Type in a ConstrainedType (excluding a TypeWithConstraint) in a Type that is one of (1) to (4).
(4) （1）から（4）のいずれかのタイプの制限付きタイプ（typewithConstraintを除く）のタイプ。
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.
さておき：この条件の効果は、コンポーネントエンコード命令を強制的に適用する名前を描写することを強制することです。このタイプはecodingPrefixedTypeに属しているため、最初の反復ではケース（2）のみが当てはまります。ただし、（1）から（4）のいずれかは、後続の反復で真である可能性があります。
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.
（1）の場合の名前を付けたものは、コンポーネントエンコーディング命令に従うと言われています。
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.
トップレベルのnamedTypeは、属性-REF、コンポーネント-REF、グループ、要素-REF、ref-as-element、または単純なコンテンツエンコーディング命令の対象ではありません。
Aside: This condition does not preclude these encoding instructions being used on a nested NamedType.
さておき、この条件は、ネストされた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.
属性、属性-Ref、コンポーネント-Ref、グループ、要素ref、ref-as-content、simple-ontent、およびversion-as-as-as-as-as-as-as-as-versionエンコード命令は相互に排他的です。namedTypeには、相互に排他的な2つ以上のエンコード指示の対象となりません。
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.
selectionType [x.680]は、属性-ref、コンポーネント-ref、要素ref、または要素としてのref-as-as-as-as-as-as-elementエンコーディング命令の対象となるnamedTypeからタイプを選択するために使用してはなりません。他のコンポーネントエンコーディング命令は、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.
定義（属性コンポーネント）：属性コンポーネントは、属性または属性-REFエンコーディング命令の対象となる名前のnamedType、または属性エンコード命令の対象となるトップレベルのnamedTypeを参照するコンポーネント-REFエンコード命令の対象となります。
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.
定義（要素コンポーネント）：要素コンポーネントは、属性、属性-REF、グループ、または単純なコンテンツエンコーディング命令の対象ではなく、トップレベルのnamedTypeを参照するコンポーネント-REFエンコーディング命令の対象ではない名前を付けたものです。これは、属性エンコーディング命令の対象となります。
Aside: A NamedType subject to a GROUP or SIMPLE-CONTENT encoding instruction is neither an attribute component nor an element component.
さておき：グループまたは単純なコンテンツエンコード命令の対象となるnamedTypeは、属性コンポーネントでも要素コンポーネントでもありません。
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.
RXERエンコーディング命令の特定は、参照エンコード命令として分類されます。参照エンコーディング命令は、属性-Ref、コンポーネント-Ref、要素ref、ref-as-rement、ref-as-type、および型REFエンコード命令（その表記法、コンポーネントレフィントリューション、元素再導入、リフェンス化により記述されていることをそれぞれ記述します。、forastypeinstruction、およびtyperefinstruction）。これらのエンコード命令（コンポーネント-REFを除く）により、ASN.1仕様は、他のXMLスキーマ言語で記述された仕様にタイプ、要素、および属性の定義を組み込むことができます。.1追加のBasicDefinitionsモジュール[rxer]（rxer]（要素ref、ref-as-rement、ref-as-type、and-refの場合）またはutf8stringタイプ（属性-ref用）。XMLスキーマ[XSD1]タイプ、要素、および属性への参照、リラックスNG [RNG]という名前のパターンと要素、およびXMLドキュメントタイプ定義（DTD）[XML10]要素タイプがサポートされています。ASN.1タイプとトップレベルコンポーネントへの参照も許可されています。コンポーネント-REFエンコーディング命令は、トップレベルのコンポーネントを参照するより直接的な方法を提供します。
The Type in the EncodingPrefixedType for an ELEMENT-REF, REF-AS-ELEMENT, REF-AS-TYPE, or TYPE-REF encoding instruction SHALL be either: (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
要素ref、ref-as-rement、ref-as-type、または型refエンコーディング命令のencodingprefixedtypeのタイプは、（1）型である定義型である参照型である（dummyreferenceではない）のいずれかのいずれかです。）または、追加のBasicDefinitionsモジュール[rxer]のマークアップasn.1タイプを参照する外部式
(2) a BuiltinType that is a PrefixedType that is a TaggedType where the Type in the TaggedType is one of (1) to (3), or
(2) taggedTypeのタイプが（1）から（3）、またはまたは
(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.
(3) encodingPrefixedTypeのタイプが（1）から（3）の1つであり、encodingPrefixedTypeのエンコーディングPrefixの1つであるEncodingPrefixedTypeであるプレフィックス模様の組み込み。
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.
さてある：ケース（3）および属性-REFおよびコンポーネント-REFエンコーディング命令の同様のケースは、参照エンコード命令を相互に排他的にするだけでなく、単独で発生する効果があります。
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.
ref-as-typeおよびtype-refエンコーディング命令に関して、（1）がエンコード命令の「対象」であると言われているdefinedtype。
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.
属性-REFエンコーディング命令のエンコーディングPrefixedTypeのタイプの制限は、セクション9で指定されています。コンポーネント-REFエンコーディング命令のエンコーディングPrefixedTypeのタイプの制限は、セクション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.
Refparametersインスタンスは、定義への参照に関する追加の情報を提供します。参照が曖昧な場合、つまり、複数のスキーマドキュメントまたは外部DTDサブセットの定義を指します。たとえば、この状況は、ターゲットネームスペース[XSD1]なしで定義された独立して開発されたXMLスキーマから同じ名前のタイプをインポートするときに発生します。外部DTDサブセットの要素タイプへの参照と組み合わせて使用する場合、コンテキストパラメーターのAnyurivalueは、外部DTDサブセットのシステム識別子（均一なリソース識別子またはURI [URI]）です。それ以外の場合、Anyurivalueは、XMLスキーマ仕様、リラックスNG仕様、またはASN.1またはASN.X仕様のいずれかで、意図したスキーマドキュメントを示すURIです。
Each NamedType has an associated expanded name [XMLNS10], determined as follows:
それぞれのnamedTypeには、次のように決定された関連する拡張名[xmlns10]があります。
(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,
(1) namedTypeが名前をエンコードする命令の対象となる場合、展開された名前のローカル名は、名前エンコード命令のncnameValueによって指定された文字文字列です。
(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,
(2) それ以外の場合は、damedTypeがコンポーネント-REFエンコード命令の対象となる場合、展開された名前は参照されたトップレベルの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,
(3) その場合、namedTypeが属性-REFまたは要素REFエンコード命令の対象である場合、拡張名の名前空間名はエンコード命令のQNameValueの名前空間名コンポーネントに等しく、ローカル名は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,
(4) それ以外の場合は、namedTypeがref-as-as-as-element encoding命令の対象となる場合、拡張名のローカル名は、エンコード命令の名前で指定された適格名のlocalpart [xmlns10]です。
(5) otherwise, the local name of the expanded name is the identifier of the NamedType.
(5) それ以外の場合、拡張された名前のローカル名は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.
（1）および（5）では、namedTypeがトップレベルのnamedTypeであり、namedTypeを含むモジュールがターゲットネームズスペースエンコード命令を持っている場合、拡張名の名前空間名は、anyurivalueのanyurivalueで指定された文字文字列です。ターゲットネームスペースエンコーディング命令。それ以外の場合、名前空間名には値がありません。
Aside: Thus, the TARGET-NAMESPACE encoding instruction applies to a top-level NamedType but not to any other NamedType.
さておき：したがって、ターゲットネームズスペースエンコーディング命令は、トップレベルのnamedTypeに適用されますが、他の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.
場合（4）、エンコーディング命令に名前空間が含まれている場合、展開された名前の名前空間名は、名前空間の項目によって指定された文字文字列です。それ以外の場合、名前空間名には値がありません。
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].
選択、シーケンス、またはセットタイプの属性コンポーネントの拡張名は明確でなければなりません。属性コンポーネントではない選択、シーケンス、またはセットタイプのコンポーネントの拡張名は明確でなければなりません。これらのテストは、X.680、条項24.4 [X.680]で指定された変換のコンポーネントの後に適用されます。
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.
さてある：同じ選択、シーケンス、またはセットタイプの2つのコンポーネントは、それらのうちの1つが属性コンポーネントであり、もう1つが属性コンポーネントである場合、同じ拡張名を持つ場合があります。「NOT」ケースには、グループまたは単純なコンテンツエンコーディング命令の対象となるコンポーネントが含まれることに注意してください。
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.
属性エンコーディング命令の対象となるトップレベルの名前の名前の拡張名は、同じモジュールの属性エンコーディング命令を対象とする他のすべてのトップレベルの名前namedTypeの拡張名とは異なる必要があります。
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.
属性エンコーディング命令の対象とならないトップレベルの名前namedTypeの拡張された名前は、同じモジュールの属性エンコード命令の対象とされていない他のすべてのトップレベルの名前namedTypeの拡張名とは異なる必要があります。
Aside: Two top-level components may have the same expanded name if one of them is an attribute component and the other is not.
さておき：1つが属性コンポーネントであり、もう1つがそうでない場合、2つのトップレベルコンポーネントに同じ拡張名がある場合があります。
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.
属性エンコーディング命令により、rxerエンコーダーは、子要素としてではなくXML属性として適用されるコンポーネントの値をエンコードします。
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:
属性エンコーディング命令の対象となるnamedTypeのタイプのベースタイプは次のものではありません。
(1) a CHOICE, SET, or SET OF type, or
(1) タイプの選択、セット、またはセット、または
(2) a SEQUENCE type other than the one defining the QName type from the AdditionalBasicDefinitions module [RXER] (i.e., QName is allowed), or
(2) 追加のBasicDefinitionsモジュール[RXER]（つまり、QNameが許可されている）からQNameタイプを定義するシーケンスタイプ、または
(3) a SEQUENCE OF type where the SequenceOfType is not subject to a LIST encoding instruction, or
(3) SequencenceOfTypeがリストエンコーディング命令の対象とならないタイプのシーケンス、または
(4) an open type.
(4) オープンタイプ。
Example
例
PersonalDetails ::= SEQUENCE {
firstName [ATTRIBUTE] UTF8String,
middleName [ATTRIBUTE] UTF8String,
surname [ATTRIBUTE] UTF8String
}
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.
属性-REFエンコーディング命令により、RXERエンコーダーは、属性の名前がエンコーディング命令によって参照される属性宣言の適格な名前である子要素としてではなく、XML属性として適用されるコンポーネントの値をエンコードします。。さらに、属性-REFエンコード命令により、UTF8STRINGタイプの値が属性宣言のタイプに準拠するように制限されます。
The notation for an ATTRIBUTE-REF encoding instruction is defined as follows:
属性-REFエンコード命令の表記は、次のように定義されます。
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.
まとめると、QNameValueとrefparametersのcontextParameter（存在する場合）は、属性エンコーディング命令の対象となるXMLスキーマ属性宣言またはトップレベルの名前を参照する必要があります。
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.
参照されているXMLスキーマ属性宣言のタイプは、XMLスキーマタイプQName、表記、エンティティ、エンティティ、または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.
さておき：これらのタイプの値には、解釈の属性のコンテキストからの情報が必要です。属性-REFエンコーディング命令はASN.1 UTF8STRINGタイプのプレフィックスに制限されているため、そのようなコンテキストをキャプチャするメカニズムはありません。
The type of a referenced top-level NamedType SHALL NOT be, either directly or by subtyping, the QName type from the AdditionalBasicDefinitions module [RXER].
参照されたトップレベルのnamedTypeのタイプは、追加のBasicDefinitionsモジュール[RXER]のQNAMEタイプの直接またはサブタイピングのいずれかであってはなりません。
The Type in the EncodingPrefixedType for an ATTRIBUTE-REF encoding instruction SHALL be either:
属性-REFエンコード命令のecodingPrefixedTypeのタイプは次のとおりです。
(1) the UTF8String type, 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
(1) UTF8STRINGタイプ、または（2）TaggedTypeのタイプが（1）から（3）、またはまたは
(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.
(3) encodingPrefixedTypeのタイプが（1）から（3）の1つであり、encodingPrefixedTypeのエンコーディングPrefixの1つであるEncodingPrefixedTypeであるプレフィックス模様の組み込み。
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.
属性-REFエンコーディング命令の対象となるnamedTypeの識別子は、RXERエンコーディングの属性の名前に寄与しません。一貫性のために、識別子は、可能であれば、参照属性宣言のローカル名と同じでなければなりません。
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.
ASN.1の基本表記には、トップレベルのnamedTypeの概念がないため、トップレベルのnamedTypeを参照するメカニズムがありません。コンポーネント-REFエンコーディング命令は、組み合わせ型定義内のnamentTypeが参照されるトップレベルのnamedTypeと同等であることを指定する方法を提供します。
The notation for a COMPONENT-REF encoding instruction is defined as follows:
コンポーネント-REFエンコード命令の表記は、次のように定義されます。
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.
GlobalModulereferenceの生成は、ASN.1基本表記[X.680]によって定義されます。GlobalModulereFerenceが内部コンプレンレファレンスに欠けている場合、識別子は同じモジュールのトップレベルの名前namedTypeの識別子でなければなりません。GlobalModulereferenceが内部コンプレンレファレンスに存在する場合、識別子は参照されたモジュールのトップレベルの名前を付けた識別子でなければなりません。
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.
外部構成のモジュールレファレンスは、externalTypereferenceのモジュールレファレンスと同じ方法で使用されます。externalComponentReferenceの識別子は、参照されるモジュールのトップレベルの名前を付けた識別子でなければなりません。
The Type in the EncodingPrefixedType for a COMPONENT-REF encoding instruction SHALL be either:
コンポーネント-Refエンコード命令のecodingPrefixedTypeのタイプは次のとおりです。
(1) a ReferencedType that is a DefinedType that is a typereference (not a DummyReference) or an ExternalTypeReference, or
(1) 段階的（ダミーの参照ではない）またはexternalTypereference、または
(2) a BuiltinType or ReferencedType that is one of the productions in Table 1 in Section 5 of the specification for RXER [RXER], or
(2) rxer [rxer]の仕様のセクション5の表1のプロダクションの1つである組み込みまたは参照型
(3) a BuiltinType that is a PrefixedType that is a TaggedType where the Type in the TaggedType is one of (1) to (4), or
(3) taggedTypeのタイプが（1）から（4）、またはまたは
(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.
(4) encodingPrefixedTypeのタイプが（1）から（4）のいずれかであり、encodingPrefixedTypeのエンコーディングPrefixの1つであるEncodingPrefixedTypeであるプレフィックス模様の組み込み型である組み込み。
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.
rxerエンコーディング命令の使用に関する制限は、namedTypeがコンポーネント-refエンコード命令の対象となる場合、namedType内で他のRXERエンコード命令が許可されないようなものです。
The Type in the top-level NamedType referenced by the COMPONENT-REF encoding instruction MUST be either:
コンポーネント-REFエンコーディング命令によって参照されるトップレベルの名前namedTypeのタイプは、次のいずれかでなければなりません。
(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
(a) 前のケース（1）が使用されている場合、（1）、または（1）、またはdefinedTypeと同じタイプを参照する操作または外部タイプである定義型である参照型
(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
(b) 前のケース（2）が使用されている場合、（2）、または（2）、またはreferencedTypeと同じである組み込みの組み込みまたは参照タイプ、または
(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.
(c) encodingPrefixedTypeの型が（a）から（c）の1つであり、encodingPrefixedTypeのエンコーディングPrefixの1つであるEncodingPrefixedTypeであるプレフィックスdTypeである組み込み型は、rxerエンコーディング命令が含まれます。
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.
原則として、コンポーネント-REFエンコード命令は、拡張された名前が参照されたトップレベルの名前の名前と、（1）または（2）のタイプの名前が参照されたトップレベルのamenedTypeのタイプに置き換えられるという概念的な名前のnamedTypeを作成します。。
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.
実際には、非Rxerエンコーダーとデコーダーが、（1）または（2）のタイプは、（1）または（2）のタイプは、参照されるトップレベルのamenttypeのタイプとのみ異なるため、概念的なaknigntypeではなく元のnamedTypeを使用するだけで十分です。rxerエンコード命令が少なく、rxerエンコード命令は、非Rxerエンコーダーとデコーダーによって無視されます。
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.
（1）または（2）のタイプのタイプのプレフィックスはバイパスされますが、rxerエンコーダーとデコーダーが、これらのプレフィックスがrxerエンコード命令になることはできないため、概念的な名前namedTypeの代わりに参照されたトップレベルの名前を使用するのを使用するだけで十分です（除く（除く）、もちろん、コンポーネント-REFエンコーディング命令の場合）。RXERエンコーディングに影響を与えません。
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:
AbstractSyntaxNotation-Xモジュールの「モジュール」のトップレベルの名前を付けたものは、次のように定義されていることに注意してください。
COMPONENT module ModuleDefinition
コンポーネントモジュールModuleDefinition
The ASN.X translation of the SEQUENCE OF type definition provides a more natural representation:
タイプ定義のシーケンスのasn.x翻訳は、より自然な表現を提供します。
<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.
さておき：AN.Xの<AngementType>要素は、damedTypeではなく、型割り当てに対応します。
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.
コンポーネント-REFエンコーディング命令の対象となるnamedTypeの識別子は、RXERエンコーディングに寄与しません。他のエンコーディングルールとの一貫性のために、識別子はコンポーネントリフィントリューションの識別子と同じでなければなりません。
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.
要素-REFエンコーディング命令により、RXERエンコーダーは、要素の名前がエンコーディング命令によって参照される要素宣言の適格な名前である要素として適用されるコンポーネントの値をエンコードします。さらに、要素REFエンコーディング命令により、マークアップASN.1タイプの値が、要素宣言のタイプに準拠するように制限されます。
The notation for an ELEMENT-REF encoding instruction is defined as follows:
要素REFエンコード命令の表記は、次のように定義されます。
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.
総合すると、QNAMEVALUEとリフパラメーターのコンテキストパラメーター（存在する場合）は、XMLスキーマ要素宣言、リラックスNG要素定義、または属性エンコーディング命令の対象ではないトップレベルの名前を参照する必要があります。
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.
参照されているXMLスキーマ要素宣言には、XMLスキーマエンティティまたはエンティティタイプの値の存在を必要とするタイプが必要です。
Aside: Entity declarations are not supported by CRXER.
さておき：エンティティ宣言は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:
選択タイプ定義のasn.x翻訳は、より自然な表現を提供します。
<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.
要素REFエンコード命令の対象となるnamedTypeの識別子は、RXERエンコーディングの要素の名前に寄与しません。一貫性のために、識別子は、可能であれば、参照される要素宣言のローカル名と同じでなければなりません。
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.
リストエンコーディング命令により、RXERエンコーダーは、コンポーネント値のホワイトスペース分離リストとして一連のタイプの値をエンコードします。
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:
リストエンコーディング命令のencodingPrefixedTypeのタイプは次のとおりです。
(1) a BuiltinType that is a SequenceOfType of the "SEQUENCE OF NamedType" form, or
(1) 「namedTypeのシーケンス」フォームのシーケンスオフタイプである組み込み、または
(2) a ConstrainedType that is a TypeWithConstraint of the "SEQUENCE Constraint OF NamedType" form or "SEQUENCE SizeConstraint OF NamedType" form, or
(2) 「namedTypeのシーケンス制約」フォームまたは「namedTypeのシーケンスサイズ」フォーム、または
(3) a ConstrainedType that is not a TypeWithConstraint where the Type in the ConstrainedType is one of (1) to (5), or
(3) 制約型のタイプが（1）から（5）、または（または（5）、または
(4) a BuiltinType that is a PrefixedType that is a TaggedType where the Type in the TaggedType is one of (1) to (5), or
(4) taggedTypeのタイプが（1）から（5）、またはまたは
(5) a BuiltinType that is a PrefixedType that is an EncodingPrefixedType where the Type in the EncodingPrefixedType is one of (1) to (5).
(5) encodingPrefixedTypeのタイプが（1）から（5）の1つであるEncodingPrefixedTypeであるプレフィックス模様の組み込みです。
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.
この条件の効果は、リストをエンコードする命令を強制して、適用されるシーケンスオフタイプまたはtypewithconstraintとテキスト的に共同住宅されるようにすることです。
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.
（1）と（2）の場合のTypewithConstraintの場合のシーケンスオフタイプは、リストエンコーディング命令の「対象」であると言われています。
A SequenceOfType or TypeWithConstraint SHALL NOT be subject to more than one LIST encoding instruction.
SequenceOfTypeまたはTypewithConstraintには、複数のリストエンコーディング命令の対象となりません。
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:
コンポーネントタイプのベースタイプSequencenceofTypeまたはTypewithConstraintのリストエンコード命令の対象となるものは、次のいずれかでなければなりません。
(1) the BOOLEAN, INTEGER, ENUMERATED, REAL, OBJECT IDENTIFIER, RELATIVE-OID, GeneralizedTime, or UTCTime type, or
(1) ブール値、整数、列挙、リアル、オブジェクト識別子、相対障害、一般化された時間、またはutctimeタイプ、または
(2) the NCName, AnyURI, Name, or QName type from the AdditionalBasicDefinitions module [RXER].
(2) ncname、anyuri、name、またはqname Type from adlidateBasicDefinitionsモジュール[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).
さて：コンポーネントタイプをすべての抽象値をゼロより大きく、抽象的な値がホワイトスペース文字を含むように制約される文字文字列タイプになることも可能になりますが、この条件がこの条件かどうかをテストすることはできません。満足していることは非常に複雑です。簡単にするために、適切であることが知られている特定のすぐに有用な制約のあるUTF8ストリングタイプのみが許可されています（つまり、NCNAME、ANYURI、および名前）。
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.
リストエンコード命令の対象となるSequencenceOfTypeまたはTypewithConstraintの名前のtypeは、属性、属性-ref、コンポーネント-ref、グループ、要素-ref、ref-as-content、simple-content、またはタイプの対象ではありません。バージョンエンコーディング命令。
Example
例
UpdateTimes ::= [LIST] SEQUENCE OF updateTime GeneralizedTime
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).
名前のエンコーディング命令により、rxerエンコーダーは、その識別子がエンコードに表示される場所（例えば、要素または属性名として）に表示される場所に、コンポーネントの識別子の代わりにノミネートされた文字列を使用します。
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
}
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.
REF-AS-ELEMENTエンコーディング命令により、RXERエンコーダーは、要素の名前がエンコーディング命令によって参照される外部DTDサブセット要素タイプの宣言の名前である要素として適用されるコンポーネントの値をエンコードします。さらに、REF-AS-ELEMENTエンコード命令により、マークアップASN.1タイプの値は、その要素タイプ宣言とその関連属性リスト宣言によって許可されるコンテンツと属性に準拠するように制限されます。
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].
総合すると、XML 1.0 [XMLNS10]の名前空間に適合した外部DTDサブセットの要素タイプ宣言を参照する必要があります。
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.
参照された要素タイプの宣言の名前がプレフィックスネーム（QNAME）[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.
さておき：エンティティ宣言はCRXERによってサポートされていません。
Example
例
Suppose that the following external DTD subset has been defined with a system identifier of "http://www.example.com/inventory":
次の外部DTDサブセットが「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:
製品要素タイプの宣言は、ASN.1タイプ定義の要素として参照できます。
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:
このasn.1タイプ定義のasn.x翻訳は次のとおりです。
<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).
ref-as-as-as-as-as-as-ase-as-as-as-as-as-as-as-as-as-as-as-as-as-asepeの識別子は、rxerエンコーディングの要素の名前に寄与しません。一貫性のために、識別子は、可能であれば、参照される要素型宣言の名前と同じでなければなりません（または、名前がプレフィックス名に準拠している場合はローカルパート）。
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.
REF-ASタイプのエンコード命令により、マークアップASN.1タイプの値は、ノミネートされた要素型宣言とその関連属性リスト宣言によって許可されているコンテンツと属性に準拠するように制限されます。
The notation for a REF-AS-TYPE encoding instruction is defined as follows:
ref-asタイプのエンコード命令の表記は、次のように定義されます。
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].
総合すると、XML 1.0 [XMLNS10]の名前空間に適合した外部DTDサブセットの要素型宣言を参照する必要があります。
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.
さておき：エンティティ宣言はCRXERによってサポートされていません。
Example
例
The product element type declaration can be referenced as a type in an ASN.1 definition:
製品要素タイプの宣言は、asn.1定義のタイプとして参照できます。
SEQUENCE OF inventoryItem [REF-AS-TYPE "product" CONTEXT "http://www.example.com/inventory"] Markup
inventoryitemのシーケンス[ref-as-type "product" context "http://www.example.com/inventory"]マークアップ
Here is the ASN.X translation of this definition:
この定義のasn.x翻訳は次のとおりです。
<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:
要素タイプの宣言がタイプと参照される場合、要素タイプの宣言の名前はRXERエンコーディングに寄与しないことに注意してください。たとえば、上記のタイプの値の値のRxERエンコードの子要素は、次のものに似ています。
<inventoryItem name="hammer" partNumber="1543" quantity="29"/>
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.
スキーマアイデンティティエンコーディング命令は、エンコード命令を含むASN.1モジュールを使用して、一意の識別子であるURI [URI]を関連付けます。このエンコーディング命令は、RXERエンコーダーには影響しませんが、ASN.1の仕様のasn.x表現への翻訳に影響を及ぼします。
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.
各スキーマアイデンティティエンコーディング命令の項目によって指定された文字文字列は、明確でなければなりません。特に、ASN.1モジュールの連続バージョンはそれぞれ異なるスキーマID URI値を持っている必要があります。
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.
単純なコンテンツエンコーディング命令により、rxerエンコーダーは、子要素にカプセル化されずにシーケンスまたはセットタイプのコンポーネントの値をエンコードします。
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].
単純なコンテンツエンコーディング命令の対象となるnamedTypeは、rootComponentTypelistのComponentTypelistのComponentTypeに含まれます。せいぜい、シーケンスまたはセットタイプのそのような名前を付けたものの1つは、単純なコンテンツエンコーディング命令の対象となることが許可されています。任意のコンポーネントが単純なコンテンツエンコード命令の対象となる場合、同じシーケンスまたはセットタイプ定義の他のすべてのコンポーネントは属性コンポーネントでなければなりません。これらのテストは、X.680、条項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.
さておき：子要素とシンプルなコンテンツは相互に排他的です。仕様ライターは、拡張可能なシーケンスまたはセットタイプのコンポーネントでの単純なコンテンツエンコーディング命令を使用することは、シーケンスまたはセットタイプのすべての将来の拡張機能が、許可されている限られたタイプのセットを持つ属性コンポーネントに制限されることを意味することに注意する必要があります。属性コンポーネント。単純なコンテンツエンコード命令の代わりに属性エンコード命令を使用すると、この制限は回避されます。
The base type of the type of a NamedType that is subject to a SIMPLE-CONTENT encoding instruction SHALL NOT be:
単純なコンテンツエンコーディング命令の対象となる名前namedTypeのタイプのベースタイプは次のものではありません。
(1) a SET or SET OF type, or
(1) タイプのセットまたはセット、または
(2) a CHOICE type where the ChoiceType is not subject to a UNION encoding instruction, or
(2) ChoiCeTypeが組合エンコーディング命令の対象ではない選択タイプ、または
(3) a SEQUENCE type other than the one defining the QName type from the AdditionalBasicDefinitions module [RXER] (i.e., QName is allowed), or
(3) 追加のBasicDefinitionsモジュール[RXER]（つまり、QNameが許可されている）からQNameタイプを定義するシーケンスタイプ、または
(4) a SEQUENCE OF type where the SequenceOfType is not subject to a LIST encoding instruction, or
(4) SequencenceOfTypeがリストエンコーディング命令の対象とならないタイプのシーケンス、または
(5) an open type.
(5) オープンタイプ。
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.
単純なコンテンツエンコーディング命令の対象となる名前namedTypeのタイプに、空の文字データ変換[rxer]（つまり、空のエンコード）を使用して抽象値がある場合、namedTypeはオプションまたはデフォルトとマークされてはなりません。
Example
例
SEQUENCE {
units [ATTRIBUTE] UTF8String,
amount [SIMPLE-CONTENT] INTEGER
}
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.
ターゲットネームズスペースエンコーディング命令は、XML名前空間名[XMLNS10]、URI [URI]、タイプ、オブジェクトクラス、値、オブジェクト、およびオブジェクトセット参照を、エンコード命令を含むASN.1モジュールで定義されています。さらに、RXERエンコードコントロールセクションの各トップレベルの名前の名前を付けた名前空間名を関連付けます。
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.
Anyurivalueは、空の文字列を指定してはなりません。
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.
定義（ターゲットネームスペース）：ASN.1モジュールにターゲットネームスペースエンコーディング命令が含まれている場合、モジュールのターゲットネームスペースは、ターゲットネームスペースエンコーディング命令の項目によって指定された文字文字列です。それ以外の場合、モジュールのターゲットネームスペースは存在しないと言われています。
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.
2つ以上のasn.1モジュールは、トップレベルの属性コンポーネントの拡張名がこれらすべてのモジュールで異なる場合にのみ、同じ非存在するターゲットネームスペースを持つ場合があります。これらすべてのモジュール、および定義されたタイプ、オブジェクトクラス、値、オブジェクト、およびオブジェクトセット参照は、それらすべてのモジュールでカテゴリで異なります。
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.
プレフィックスは、存在する場合、NCNameをターゲット名を含む名前空間宣言の名前空間プレフィックスとして使用することを提案します。RXERエンコーダーは、指名された名前空間プレフィックスを使用する義務はありません。
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.
トップレベルのコンポーネントがない場合、ターゲットネームズスペースのエンコード命令を持つモジュールを使用して生成されたRXERエンコーディングは、ターゲットネームズスペースエンコード命令なしで同じモジュールによって生成されるRXERエンコーディングと後方互換性があります。
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.
バージョンのタイプエンコーディング命令により、RXERエンコーダーにXSI：タイプ属性が含まれます。この属性により、XMLスキーマ[XSD1] VALDIBARTARは、利用可能な場合は、エンコードの作成に使用されるASN.1仕様のバージョンの適切なXMLスキーマ変換を選択できます。
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.
さてある：ASN.1のXMLスキーマへのASN.1仕様の翻訳は、ASN.1仕様への進行性拡張のため、バージョン間でわずかに異なると予想されます。各バージョンが異なるターゲットネームスペースを使用している場合、これらの翻訳間の互換性が対応できます。ターゲットネームスペースは、XSI：Type属性の値で明らかになり、XML Schema Validatorが適切なバージョンを使用します。このメカニズムは、ASN.1仕様の後のバージョンで変更されたASN.1タイプにも対応します。
The notation for a TYPE-AS-VERSION encoding instruction is defined as follows:
バージョンエンコード命令のタイプの表記は、次のように定義されます。
TypeAsVersionInstruction ::= "TYPE-AS-VERSION"
The Type in a NamedType that is subject to a TYPE-AS-VERSION encoding instruction MUST be a namespace-qualified reference [RXER].
バージョンとしてのタイプエンコーディング命令の対象となる名前のある型のタイプは、名前空間資格のある参照[rxer]でなければなりません。
The addition of a TYPE-AS-VERSION encoding instruction does not affect the backward compatibility of RXER encodings.
バージョンエンコーディング命令のタイプを追加しても、RXERエンコーディングの後方互換性には影響しません。
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.
さておき：asn.1の仕様のXMLスキーマへの変換では、XSI：型属性が機能するように、型のバージョンエンコーディング命令のタイプの対象となる任意のタイプの任意のタイプがXMLスキーマに変換されると予想されます。適切なバージョンを選択するためのスイッチとして。
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.
タイプREFエンコーディング命令により、マークアップASN.1タイプの値が制限され、タイプ、リラックスngの名前のパターン、またはasn.1定義型タイプに適合します。
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.
さておき：asn.1を参照するタイプREFエンコーディング命令のタイプは、タイプの抽象値のrxERエンコードのinfoSet [infoset]表現を維持するための要件を課す効果はありません。抽象値だけを保持するだけで十分です。
The notation for a TYPE-REF encoding instruction is defined as follows:
タイプREFエンコード命令の表記は、次のように定義されます。
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.
まとめると、QNAME値とREFパラメーターのコンテキストパラメーター（存在する場合）は、型、型ngという名前のパターン、またはasn.1定義型の名前のXMLスキーマを参照する必要があります。
A referenced XML Schema type MUST NOT require the presence of values for the XML Schema ENTITY or ENTITIES types.
参照されたXMLスキーマタイプは、XMLスキーマエンティティまたはエンティティタイプの値の存在を必要としないはずです。
Aside: Entity declarations are not supported by CRXER.
さておき：エンティティ宣言は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.
QNameValueは、XMLスキーマ表記タイプ[XSD2]（つまり、名前空間名「http://www.w3.org/2001/xmlschema」およびローカル名「表記」への直接参照ではありません。ただし、表記タイプから派生したXMLスキーマタイプへの参照が許可されています。
Aside: This restriction is to ensure that the lexical space [XSD2] of the referenced type is actually populated with the names of notations [XSD1].
さておき：この制限は、参照されるタイプの語彙空間[XSD2]に実際に表記名[XSD1]が入っていることを保証することです。
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:
このasn.1タイプ定義のasn.x翻訳は、XMLスキーマ10進数を参照するためのより自然な方法を提供することに注意してください。
<namedType xmlns:xs="http://www.w3.org/2001/XMLSchema"
name="MyDecimal">
<type ref="xs:decimal" embedded="true"/>
</namedType>
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).
ユニオンエンコーディング命令により、RXERエンコーダーは、子要素にカプセル化されていない選択タイプの代替の値をエンコードします。選択された代替案は、オプションでメンバー属性で示されています。また、オプションのPerterenceListは、仕様ライターがRXERデコーダーが使用された代替案を決定する際に選択の代替案を検討する順序を変更することもできます（実際の代替がメンバー属性を通じて指定されていない場合）。
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:
組合エンコーディング命令のEncodingPrefixedTypeのタイプは次のとおりです。
(1) a BuiltinType that is a ChoiceType, or
(1) ChuiseTypeである組み込み、OR
(2) a ConstrainedType that is not a TypeWithConstraint where the Type in the ConstrainedType is one of (1) to (4), or
(2) 制約型のタイプが（1）から（4）、またはまたは
(3) a BuiltinType that is a PrefixedType that is a TaggedType where the Type in the TaggedType is one of (1) to (4), or
(3) taggedTypeのタイプが（1）から（4）、またはまたは
(4) a BuiltinType that is a PrefixedType that is an EncodingPrefixedType where the Type in the EncodingPrefixedType is one of (1) to (4).
(4) encodingPrefixedTypeのタイプが（1）から（4）の1つであるEncodingPrefixedTypeであるプレフィックス模様の組み込みです。
The ChoiceType in case (1) is said to be "subject to" the UNION encoding instruction.
（1）が「組合エンコーディングの指示に従う」と言われている場合のChoiCeType。
The base type of the type of each alternative of a ChoiceType that is subject to a UNION encoding instruction SHALL NOT be:
組合エンコーディング指示の対象となるchuiceTypeの各選択肢のベースタイプは次のものではありません。
(1) a CHOICE, SET, or SET OF type, or
(1) タイプの選択、セット、またはセット、または
(2) a SEQUENCE type other than the one defining the QName type from the AdditionalBasicDefinitions module [RXER] (i.e., QName is allowed), or
(2) 追加のBasicDefinitionsモジュール[RXER]（つまり、QNameが許可されている）からQNameタイプを定義するシーケンスタイプ、または
(3) a SEQUENCE OF type where the SequenceOfType is not subject to a LIST encoding instruction, or
(3) SequencenceOfTypeがリストエンコーディング命令の対象とならないタイプのシーケンス、または
(4) an open type.
(4) オープンタイプ。
Each identifier in the PrecedenceList MUST be the identifier of a NamedType in the ChoiceType.
PreterenCeListの各識別子は、ChoiCeTypeのnamedTypeの識別子でなければなりません。
A particular identifier SHALL NOT appear more than once in the same PrecedenceList.
特定の識別子は、同じPreterenceListに1回以上表示されてはなりません。
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.
組合エンコーディング命令の対象となるchuiceTypeのすべてのnamedTypeは、属性、属性-ref、コンポーネント-ref、グループ、要素ref、ref-as-element、simple-content、またはtype-as-の対象ではありません。バージョンエンコーディング命令。
Example
例
[UNION PRECEDENCE basicName] CHOICE {
extendedName UTF8String,
basicName PrintableString
}
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.
値をエンコードする命令により、RXERエンコーダーは、少し文字列、列挙、または整数タイプの値のエンコードに表示される識別子の代わりに、指名名の代わりにノミネートされた名前を使用します。
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:
値をエンコードする命令のencodingPrefixedTypeのタイプは次のとおりです。
(1) a BuiltinType that is a BitStringType with a NamedBitList, or
(1) namedbitListを持つbitStringTypeである組み込みの組み込み、または
(2) a BuiltinType that is an EnumeratedType, or
(2) EnumeratedTypeである組み込み
(3) a BuiltinType that is an IntegerType with a NamedNumberList, or
(3) namednumberListを備えたintegertypeである組み込み、または
(4) a ConstrainedType that is not a TypeWithConstraint where the Type in the ConstrainedType is one of (1) to (6), or
(4) 制約型のタイプが（1）から（6）、または（または（6）、または
(5) a BuiltinType that is a PrefixedType that is a TaggedType where the Type in the TaggedType is one of (1) to (6), or
(5) taggedTypeのタイプが（1）から（6）、またはまたは
(6) a BuiltinType that is a PrefixedType that is an EncodingPrefixedType where the Type in the EncodingPrefixedType is one of (1) to (6).
(6) encodingPrefixedTypeのタイプが（1）から（6）の1つであるEncodingPrefixedTypeであるプレフィックス模様の組み込みです。
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.
（1）、（2）、または（3）の場合のBitStringType、EnumeratedType、またはIntegerTypeは、それぞれ「命令をエンコードする値」に「影響を受ける」と言われています。
A BitStringType, EnumeratedType, or IntegerType SHALL NOT be subject to more than one VALUES encoding instruction.
BitStringType、EnumeratedType、またはIntegerTypeには、複数の値をエンコードする命令を1つ以上の値にかけないものとします。
Each identifier in a ValueMapping MUST be an identifier appearing in the NamedBitList, Enumerations, or NamedNumberList, as the case may be.
ValueMappingの各識別子は、場合によっては、namedbitlist、列挙、またはnameNumberListに表示される識別子でなければなりません。
The identifier in a ValueMapping SHALL NOT be the same as the identifier in any other ValueMapping for the same ValueMappingList.
ValueMappingの識別子は、同じValueMappingListの他のValueMappingの識別子と同じではありません。
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.
定義（交換名）：値エンコーディング命令の対象となるBitStringType、EnumeratedType、またはIntegerTypeの各識別子には、交換名があります。識別子にValueMappingがある場合、交換名はValueMappingでNCNameValueによって指定された文字文字列です。それ以外の場合、AllCapitalizedが使用されている場合、交換名は最初の文字が上映された識別子です。それ以外の場合、Alluppercasedが使用されている場合、交換名はすべての文字が上映された識別子です。それ以外の場合、交換名は識別子です。
The replacement names for the identifiers in a BitStringType subject to a VALUES encoding instruction MUST be distinct.
値エンコーディング命令の対象となるbitStringTypeの識別子の交換名は明確でなければなりません。
The replacement names for the identifiers in an EnumeratedType subject to a VALUES encoding instruction MUST be distinct.
値エンコーディング命令の対象となるEnumeratedTypeの識別子の交換名は明確でなければなりません。
The replacement names for the identifiers in an IntegerType subject to a VALUES encoding instruction MUST be distinct.
値エンコード命令の対象となるIntegertypeの識別子の交換名は、明確でなければなりません。
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.
}
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).
特定のrxerエンコーディング命令は、挿入エンコード命令として分類されます。挿入エンコーディング命令は、挿入なし、中空挿入、特異な挿入、均一な挿入、およびマルチフォーム挿入命令をエンコードする命令（その表記法、中空instruction、singularintionSionsintruction、均一なインサイオントリューション、およびマルチヨンティオンティオントリューションによってそれぞれ記述されています）。
The notation for the insertion encoding instructions is defined as follows:
挿入エンコード命令の表記は、次のように定義されます。
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.
拡張可能なタイプを持つコンポーネントの命令をエンコードするグループを使用すると、未知の拡張が複数の拡張挿入ポイントに関連付けられる可能性がある状況につながる可能性があります。挿入エンコーディング命令は、拡張機能が取得できるフォームを制限することにより、このあいまいさを削除します。つまり、挿入エンコーディング命令は、RXERエンコーディングの順方向の互換性を壊すことなく、asn.1仕様に対してどの拡張機能を作成できるかを示しています。
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.
命令をエンコードするマルチフィルムインサート化は、順方向互換拡張機能によって生成されるrxerエンコーディングが、常に1つ以上の要素とゼロ以上の属性で構成されることを示しています。要素の名前に制限はありません。
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 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".
均一な挿入命令は、タイプへの順方向互換拡張機能によって生成されるRxERエンコーディングが、同じ拡張名とゼロ以上の属性を持つ1つ以上の要素で常に構成されることを示しています。特定のエンコードの要素によって共有される拡張名は、拡張機能の他のエンコードで要素によって共有される拡張名と同じである必要はありません。たとえば、拡張機能の1つのエンコードでは、要素はすべて「foo」と呼ばれる場合がありますが、拡張機能の別のエンコードでは、すべて「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.
命令をエンコードする特異な挿入は、順方向互換拡張機能によって生成されるrxerエンコーディングが、常に単一の要素とゼロ以上の属性で構成されることを示しています。単一の要素の名前は、拡張機能のすべての可能なエンコードで同じである必要はありません。
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.
命令をエンコードする中空の挿入は、順方向互換拡張機能によって生成されるrxerエンコーディングが、常にゼロ要素とゼロ以上の属性で構成されていることを示しています。
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.
順方向互換性のある拡張機能の例は、付録Cに記載されています。
The Type in the EncodingPrefixedType for an insertion encoding instruction SHALL be either:
挿入エンコーディング命令のEncodingPrefixedTypeのタイプは次のとおりです。
(1) a BuiltinType that is a ChoiceType where the ChoiceType is not subject to a UNION encoding instruction, or
(1) ChoiCeTypeが組合エンコーディング命令の対象ではないChoiCeTypeである組み込み、または
(2) a BuiltinType that is a SequenceType or SetType, or
(2) SequenceTypeまたはsetTypeである組み込み、または
(3) a ConstrainedType that is not a TypeWithConstraint where the Type in the ConstrainedType is one of (1) to (5), or
(3)
(4) a BuiltinType that is a PrefixedType that is a TaggedType where the Type in the TaggedType is one of (1) to (5), or
(4) taggedTypeのタイプが（1）から（5）、またはまたは
(5) a BuiltinType that is a PrefixedType that is an EncodingPrefixedType where the Type in the EncodingPrefixedType is one of (1) to (5).
(5) encodingPrefixedTypeのタイプが（1）から（5）の1つであるEncodingPrefixedTypeであるプレフィックス模様の組み込みです。
Case (2) is not permitted when the insertion encoding instruction is the SINGULAR-INSERTIONS, UNIFORM-INSERTIONS, or MULTIFORM-INSERTIONS encoding instruction.
ケース（2）は、挿入エンコーディング命令が特異な挿入、均一な挿入、またはマルチフォームインドをエンコードする命令である場合、許可されません。
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.
ケース（1）またはケース（2）のタイプは、挿入エンコーディング命令の影響を受けると言われています。
The Type in case (1) or case (2) MUST be extensible, either explicitly or by default.
ケース（1）またはケース（2）のタイプは、明示的またはデフォルトで拡張可能でなければなりません。
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を参照）。例は、付録Cに記載されています。
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).
バージョンインディケーターエンコーディング命令は、rxerデコーダがエンコードに互換性を壊す拡張機能が含まれていることを警告するメカニズムを提供します（前のセクションを参照）。
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.
バージョンインディケーターエンコーディング命令の対象となるnamedTypeは、属性エンコーディング命令の対象とする必要があります。
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 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.
バージョンインディケーターエンコード命令の対象となる名前のnameTypeのタイプは、許可された値のセットが拡張可能であると定義される制約付きタイプでなければなりません。各値は、ASN.1仕様の異なるバージョンを表します。通常、アプリケーションは、バージョンインジケータ属性の値をこれらの許可された値の最後に設定します。アプリケーションは、以降のバージョンで追加された拡張機能のいずれも使用していない場合、仕様の以前のバージョンに対応するバージョンインジケーター属性の値を設定する場合があります。
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.
rxerデコーダーがルート値または拡張の追加のいずれかではないタイプの値に遭遇する場合（ただし、許可された値のセットが拡張可能であるため許可されています）、これはデコーダーがASNのバージョンを使用していることを示します。.1エンコーディングの生成に使用されるバージョンと互換性がない仕様。そのような場合、デコーダーは、属性を含む要素を未知のasn.1タイプを持つものとして処理する必要があります。
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.
さておき：バージョンインジケータ属性は、RxERエンコーディングに関する互換性のみを示します。グループエンコーディング命令がそれらに適用されないため、他のエンコーディングは影響を受けません。
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.
この最初の例では、デコーダーは、受信したRXERエンコードのバージョン属性の値が1、2、または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".
この2番目の例では、デコーダーは、受信したRXERエンコードのフォーマット属性の値が「1.0」、「1.1」、または「2.0」ではない場合、互換性のない古いバージョンを使用しています。
SEQUENCE {
format [ATTRIBUTE] [VERSION-INDICATOR]
UTF8String ("1.0", ..., "1.1" | "2.0"),
message MessageType
}
An extensive example is provided in Appendix C.
付録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.
すべての拡張可能なタイプが独自のバージョンインジケーター属性を持つ必要はありません。トップレベルの要素コンポーネントのタイプのみが、ネストされたすべてのコンポーネントのバージョンインジケーターとして機能するバージョンインジケーター属性を含めることが典型的です。
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.
グループエンコーディング命令により、RXERエンコーダーは、要素としてカプセル化されずに適用されるコンポーネントの値をエンコードします。これにより、要素コンテンツ用の非自明なコンテンツモデルの構築が可能になります。
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:
グループエンコーディング命令の対象となる名前namedTypeのタイプのベースタイプは次のとおりです。
(1) a SEQUENCE, SET, or SET OF type, or
(1) タイプのシーケンス、セット、またはセット、または
(2) a CHOICE type where the ChoiceType is not subject to a UNION encoding instruction, or
(2) ChoiCeTypeが組合エンコーディング命令の対象ではない選択タイプ、または
(3) a SEQUENCE OF type where the SequenceOfType is not subject to a LIST encoding instruction.
(3) SequenceOfTypeがリストエンコーディング命令の対象ではないタイプのシーケンス。
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.
（1）の場合のシーケンスタイプは、組み込み型の関連タイプではなく、追加のBasicDefinitionsモジュール[RXER]のタイプではなく、単純なコンテンツエンコーディング命令の対象となるコンポーネントを含めてはなりません。。
Aside: Thus, the CHARACTER STRING, EMBEDDED PDV, EXTERNAL, REAL, and QName types are excluded.
さておき：したがって、文字列、埋め込まれたPDV、外部、リアル、およびQNameタイプは除外されます。
The CHOICE type in case (2) SHALL NOT be a type from the AdditionalBasicDefinitions module.
ケースの選択タイプ（2）は、追加のBasicDefinitionsモジュールからのタイプではありません。
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].
定義（可視コンポーネント）：すべてのタイプの制約を無視すると、直接または間接的に結合するasn.1タイプ（つまり、シーケンス、セット、選択、シーケンス、またはセット）を組み合わせたタイプの可視コンポーネントは、のコンポーネントのセットです。グループエンコーディング命令の対象となる（組み合わせ型定義の）namedTypeの各namedTypeの組み合わせタイプ定義プラス、AndameTypeのタイプの可視コンポーネント。可視成分は、X.680、節24.4 [X.680]で指定された変換の成分の後に決定されます。
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.
さて、タイプの可視属性コンポーネントのセットと要素コンポーネントは、タイプのすべてのコンポーネントのセットと、外部型の値のRxERエンコーディングに表示される属性と子要素を記述するネストされた型のセットです。
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).
namedTypeを同じdamendTypeのタイプの目に見えるコンポーネントにする場合、グループエンコーディング命令を使用してはなりません（タイプ定義が再帰的である場合にのみ可能です）。
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.
さておき：グループエンコーディング命令の対象となるコンポーネントは、グループ定義として互換性のあるXMLスキーマ[XSD1]に変換される場合があります。独自のタイプに表示される名前型型は、XMLスキーマが許可する円形グループに類似しています。
Section 25.1 imposes additional conditions on the use of the GROUP encoding instruction.
セクション25.1では、グループエンコーディング命令の使用に追加の条件を課します。
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.
グループエンコーディング命令の使用には、グループエンコーディング命令の対象となるコンポーネント、および含まれるタイプ、つまりそのコンポーネントのベースタイプを含むタイプ、incluive型のタイプがあります。どちらのタイプも、asn.1拡張性を直接使用するか、別のグループエンコード命令を介して拡張可能な他のタイプを含めることにより、拡張可能なコンテンツモデルを持つことができます。
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.
含めることと含まれるタイプは、異なるasn.1モジュールで定義される場合があります。その場合、含めるタイプの所有者、つまり、inclived型の定義に拡張機能を追加する権限を持つ個人または組織は、の所有者とは異なる場合があります。付属のタイプ。
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.
含まれるタイプの所有者が含まれているタイプの最新のバージョンを使用していない場合、含まれるタイプの所有者は、含まれているタイプの古いバージョンに関して有効なinclingalタイプに拡張機能を追加する可能性がありますが、後に、含まれる最新のバージョンと含まれるタイプ定義がまとめられた場合（おそらくサードパーティによって）無効であることがわかります。含めるタイプの所有者は必ずしも含まれているタイプの存在を認識しなければなりませんが、逆は必ずしも真実ではありません。付属のタイプの所有者は、他の人の種類を無効にすることに気付かずに、付属のタイプに拡張機能を追加できます。
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
(1) 付属のタイプは、伴う型とは別のモジュールで定義され、
(2) the included type has an extensible content model, and
(2) 付属のタイプには、拡張可能なコンテンツモデルがあり、
(3) changes to the included type are not coordinated with the owner of the including type.
(3) 含まれているタイプの変更は、含まれるタイプの所有者と調整されません。
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
(1) 含まれているタイプの所有者は、inclutive Typeの所有者でもあります。
(2) the owner of the including type is collaborating with the owner of the included type, or
(2) 含まれるタイプの所有者は、含まれているタイプの所有者と協力しています。
(3) all changes will be vetted by a common third party before being approved and published.
(3) すべての変更は、承認および公開される前に、共通の第三者によって審査されます。
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.
グループエンコーディング命令の規制されていない使用は、明確な抽象値が区別できないrxerエンコーディング、つまり曖昧なエンコーディングを備えた仕様に簡単につながる可能性があります。このセクションでは、グループエンコード命令の使用に制限を課して、異なる抽象値が異なるRxERエンコーディングを確保することを確認します。さらに、これらの制限により、抽象値をバックトラッキングなしで単一のパスで簡単に解読できるようになります。
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.
asn.1タイプのrxerデコーダーは、要素と属性の拡張名で構成される概念的言語の認識者として抽象化することができます。タイプ定義はその言語の文法を記述します（実際、それはコンテキストのない文法です）。簡単で明確なデコードを確保するためのタイプ定義の制限は、より便利、完全に、そしてこの関連する文法の条件として単に表現されます。実装は、説明する方法でタイプ定義を正確に検証することは期待されていません。ただし、使用される手順は同じ結果を生成する必要があります。
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 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.
セクション25.1.1では、グループエンコーディング命令の対象となるコンポーネントを含む文法としてのリキャストの手順について説明します。セクション25.1.2および25.1.3は、タイプ定義が有効であるために文法が満たさなければならない条件を指定します。セクション25.1.4では、拡張可能なタイプの文法によって認識されていない属性がどのように受け入れられるかについて説明します。
Appendices A and B have extensive examples.
付録AとBには広範な例があります。
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.
文法は、プロダクションのコレクションで構成されています。制作には左側と右側があります（このドキュメントでは、「:: = = "シンボルで区切られています）。左側（コンテキストなしの文法）は、単一の非末端シンボルです。右側は、非末端シンボルと末端記号のシーケンスです。端子記号は、文法が説明する言語の語彙的アイテムです。非ターミナルの1つは、スタートシンボルに指名されています。言語の有効な端子シーケンスは、スタート記号から始まり、非端子を生産の左側にあるプロダクションの1つの右側に繰り返し置き換えることにより、文法から生成できます。側。端末の最終シーケンスは、交換する非端子が残っていない場合に達成されます。
Aside: X.680 describes the ASN.1 basic notation using a context-free grammar.
さておき：X.680は、コンテキストのない文法を使用したASN.1の基本表記について説明します。
Each NamedType has an associated primary and secondary non-terminal.
それぞれのnamedTypeには、関連する一次および二次非末端があります。
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.
さておき：AndameTypeの型タイプのベースタイプがタイプまたはタイプのセットのシーケンスである場合、namedTypeの二次非末端が使用されます。
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.
このドキュメントのほとんどの例（最も一般的なケースではありませんが）には、AndameTypeがAndameTypeの識別子であるための主要な非末端、プライマリスタート非末端がSであるための適切です。Extension AdditionおよびExtension AdditionAlternativeのE1、E2、E3などのインスタンスのインスタンス、および拡張挿入ポイントがI1、I2、I3などになるための非末端の非末端。二次非ターミナルは、プライマリ非ターミナルラベルに「 '」キャラクターを追加することによってラベル付けされます。たとえば、プライマリおよびセカンダリスタートの非ターミナルはそれぞれsとs'です。
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.
それぞれのnamedTypeおよび拡張挿入ポイントには、関連する端子があります。特定の表記に関連付けられていない一般的な拡張端子と呼ばれる端子が存在します。一般的な拡張端子と拡張挿入ポイントの端子は、不明な拡張機能の要素を表すために使用されます。ターミナルの正確な性質は重要ではありません。ただし、前述の端子は相互に異なる必要があります。端子は、要素端子または属性端子のいずれかにさらに分類されます。AnightTypeの端子は、関連するnamedTypeが属性コンポーネントである場合、属性端末です。それ以外の場合、それは要素端子です。一般的な拡張端子と拡張挿入ポイントの端子は、要素端子に分類されます。
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.
未知の拡張機能の属性の端子は、文法で明示的に提供されていません。文法の特定のプロダクションは、挿入点制作に分類されており、未知の属性を受け入れる上での役割については、セクション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.
このドキュメントの例では、属性コンポーネント以外のコンポーネントの端子は、二重引用符に囲まれたコンポーネントの拡張された名前のローカル名として表され、属性コンポーネントの端子はローカル名として表されます。「@」文字が付けられ、二重引用符で囲まれたコンポーネントの拡張名の。一般的な拡張端子は「*」として表され、拡張挿入ポイントの端子は「*1」、「*2」、「*3」などとして表されます。
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.
namedTypeから生成されたプロダクションは、namedTypeのタイプのベースタイプに依存します。最初の非末端のプロダクションは、テストされている組み合わせ型定義に依存します。どちらの場合でも、生産を生成する手順には、主要な非末端、二次非末端（場合によっては）、およびタイプ定義が必要です。
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].
文法は、X.680、条項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: (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.
主要な非末端、およびベースタイプがシーケンスまたはセットタイプであるタイプを考えると、左側としてnを含む文法に生産が追加されます。右側は、順に検討された以下のケースに従って初期の空の状態から構築されます。（1）初期のrootComponentTypelistがベースタイプに存在する場合、次に、そのrootComponentTypelistにネストされたコンポーネントの一次非ターミナルのシーケンス定義の順に右側に追加されます。
(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.
(2) extensionAdtitionsインスタンスがベースタイプに存在し、空ではない場合、extensionAdtitionsインスタンスにネストされた最初の拡張機能の非末端は右側に追加されます。
(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.
(3) extensionAdtitionsインスタンスが空であるか、ベースタイプに存在しない場合、ベースタイプが拡張可能であり（明示的またはデフォルトで）、ベースタイプがindinationsまたは中空エンコード命令の対象ではない場合、非indolベースタイプの拡張挿入点の端子は、右側に追加されます。
(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.
(4) 最終的なrootComponentTypelistがベースタイプに存在する場合、そのrootComponentTypelistにネストされたコンポーネントの主要な非ターミナルは、定義の順に右側に追加されます。
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.
componentTypelistのコンポーネント（RootComponentTypelistまたはextensionAdditionGroupのいずれか）がオプションまたはデフォルトとマークされている場合、コンポーネントの主要な非末端を左側の生産と、空の右側が空の右側を追加します。文法。
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.
コンポーネント（ASN.1を含む型を含むタイプを含む）がグループエンコーディング命令の対象となる場合、コンポーネントのタイプに従って構築された1つ以上のプロダクションが文法に追加されます。これらの各作品には、左側としてコンポーネントの主要な非末端があります。
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.
コンポーネント（ASN.1を含む型を含むタイプを含む）がグループエンコーディング命令の対象ではない場合、左側と端子としてコンポーネントの主要な非末端を持つプロダクションが文法に追加されます右側としてのコンポーネントの。
Example
例
Consider the following ASN.1 type definition:
次のasn.1タイプ定義を考えてみましょう。
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.
（シーケンスまたはセットベースタイプの）各拡張拡張機能について、左側が拡張療法の非末端であり、右側が最初に空である文法に生産が追加されます。拡張機能がComponentTypeである場合、コンポーネントタイプのnamedTypeの主要な非末端が右側に追加されます。それ以外の場合は、extensionAdtionGroupのComponentTypelistにネストされたコンポーネントの一次非ターミナルのシーケンスは、定義の順に右側に追加されます。拡張機能の後に別の拡張機能が続く場合、次の拡張拡張機能の非末端が右側に追加されます。それ以外の場合、ベースタイプがindinationsまたは中空挿合をエンコードする命令の対象でない場合、ベースタイプの拡張挿入点の非末端は右側に追加されます。ExtensionAdditionの後に別のExtensionAdtitionが続けられず、ベースタイプがindinationsエンコード命令の対象ではない場合、生産は挿入ポイント生産です。端子の空のシーケンスを生産から生成できない場合（この決定を行う前に文法が完了するまで待つ必要がある場合があります）、左側が非末端である文法に別の生産が追加されますExtensionAdditionの場合、右側は空です。
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.
さておき：送信者は、拡張機能の一部または一部のみが定義されていないASN.1仕様の以前のバージョンを使用している可能性があるため、拡張機能は常に効果的にオプションです。
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].
さておき、拡張拡張機能用に生成された文法は、すべての以前の拡張機能も使用されている場合にのみ拡張できるという条件を考慮するように構成されています[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:
シーケンスまたはセットベースタイプが拡張可能（明示的またはデフォルトで）であり、indinationsまたは中空の挿入をエンコードする命令の対象でない場合、次のとおりです。
(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
(1) 左側がベースタイプの延長挿入点の非末端であり、右側が拡張挿入ポイントの非末端が続く一般的な拡張端子である文法に生産が追加されます。と
(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.
(2) 左側が延長挿入ポイントの非末端であり、右側が空である文法に生産が追加されます。
Example
例
Consider the following ASN.1 type definition:
次のasn.1タイプ定義を考えてみましょう。
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 ::=
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:
シーケンスタイプがindinationsまたは中空の挿入指導をエンコードする命令の対象となる場合、i1の制作は表示されず、E3の最初の生産は次のとおりです。
E3 ::= six seven
Given a primary non-terminal, N, and a type where the base type is a CHOICE type:
主要な非末端、n、およびベースタイプが選択タイプであるタイプが与えられます。
(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.
(1) ベースタイプのrootalternativeTypelistにネストされた各namedTypeのプロダクションは、左側がnであり、右側が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.
(2) ベースタイプの各拡張アディションアルマティブの文法に生産が追加されます。左側はnで、右側はextensionAditionalternativeの非末端です。
(3) If the base type is extensible (explicitly or by default) and the base type is not subject to an insertion encoding instruction, then:
(3) ベースタイプが拡張可能で（明示的またはデフォルトで）、ベースタイプが挿入エンコーディング命令の対象でない場合、次のとおりです。
(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.
(a) 左側がnであり、右側がベースタイプの拡張挿入点の非末端である文法に生産が追加されます。この生産は、挿入点の生産です。
(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.
(b) 左側がベースタイプの延長挿入点の非末端であり、右側が拡張挿入ポイントの非末端が続く一般的な拡張端子である文法に生産が追加されます。
(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.
(c) 左側がベースタイプの拡張挿入点の非末端であり、右側が空である文法に生産が追加されます。
(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.
(4) ベースタイプが中空の挿入指導の対象となる場合、左側がnで右側が空である文法に生産が追加されます。この生産は、挿入点の生産です。
(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.
(5) ベースタイプが命令をエンコードする特異な象徴の対象となる場合、左側がnで右側が一般的な拡張端子である文法に生産が追加されます。この生産は、挿入点の生産です。
(6) If the base type is subject to a UNIFORM-INSERTIONS encoding instruction, then:
(6) ベースタイプが均一な挿入命令をエンコードする場合の場合、次のとおりです。
(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.
(a) 左側がnで、右側が一般的な拡張端子である文法に生産が追加されます。
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.
さておき：この生産は、ASN.1タイプ定義の正確性を検証するために使用されますが、Rxerデコーダーの実装には使用されません。次の生産は、未知の要素を受け入れるために優先されます。
(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.
(b) 左側がnであり、右側がベースタイプの拡張挿入点の端子であり、延長挿入ポイントの非末端が続く文法に生産が追加されます。この生産は、挿入点の生産です。
(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.
(c) 左側がベースタイプの拡張挿入点の非末端であり、右側が延長挿入ポイントの端子であり、拡張の非末端が続く文法に生産が追加されます。挿入口。
(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.
(d) 左側がベースタイプの拡張挿入点の非末端であり、右側が空である文法に生産が追加されます。
(7) If the base type is subject to a MULTIFORM-INSERTIONS encoding instruction, then:
(7) ベースタイプが命令をエンコードするマルチフィルムインテーションの対象となる場合、次のとおりです。
(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.
(a) 左側がnであり、右側が一般的な拡張端子に続いて、ベースタイプの拡張挿入点の非末端が続く文法に生産が追加されます。この生産は、挿入点の生産です。
(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.
(b) 左側がベースタイプの延長挿入点の非末端であり、右側が拡張挿入ポイントの非末端が続く一般的な拡張端子である文法に生産が追加されます。
(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.
(c) 左側がベースタイプの拡張挿入点の非末端であり、右側が空である文法に生産が追加されます。
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.
extensionAdditionAlternativeがnamedTypeである場合、左側がextensionAditionalternativeの非末端であり、右側が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.
extensionAdtionAlternativeがExtensionAdtionAdtionAlternativesGroupである場合、左側が拡張拡張機能標準の非末端であり、右側が主要な非ターミナルである左側のextensionAditionAlternativeGroupにnamedTypeのそれぞれの文法に生産が追加されます。namedType。
Example
例
Consider the following ASN.1 type definition:
次のasn.1タイプ定義を考えてみましょう。
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.
選択タイプが命令をエンコードすることなく、5番目、6番目、および7番目のプロダクションが削除されます。
If the CHOICE type were subject to a HOLLOW-INSERTIONS encoding instruction, then the fifth, sixth, and seventh productions would be replaced by:
選択タイプが命令をエンコードする中空挿入の対象となる場合、5番目、6番目、および7番目のプロダクションは次のものに置き換えられます。
S ::=
If the CHOICE type were subject to a SINGULAR-INSERTIONS encoding instruction, then the fifth, sixth, and seventh productions would be replaced by:
選択タイプが命令をエンコードする特異な挿入の対象となる場合、5番目、6番目、および7番目のプロダクションは次のものに置き換えられます。
S ::= "*"
If the CHOICE type were subject to a UNIFORM-INSERTIONS encoding instruction, then the fifth and sixth productions would be replaced by:
選択タイプが均一な挿入指導の対象となる場合、5番目と6番目のプロダクションは次のものに置き換えられます。
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:
選択タイプが命令をエンコードするマルチフィルムインサート作用の対象となる場合、5番目の生産は次のように置き換えられます。
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):
一次非末端、n、およびベースタイプのシーケンスまたはセットを持つタイプが与えられ、サイズゼロ（つまり、空のシーケンスまたはセット）の値を許可する：
(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
(1) プロダクションがnである文法に生産が追加され、右側はベースタイプのシーケンスまたはセットのコンポーネントの名前を付けたものの主要な非末端であり、それに続いてnが続きます。と
(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.
(2) プロダクションがNがnで、右側が空である文法に生産が追加されます。
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: (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
一次非末端、n、二次非末端n '、およびベースタイプのシーケンスまたはセットを持つタイプを与えられ、サイズゼロの値を許可しない：（1）生産が追加されます生産の左側がnであり、右側がベースタイプのシーケンスまたはセットのコンポーネントの名前の付いた型の主要な非末端、続いてn '、およびn'が続く文法は、
(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
(2) プロダクションは、生産の左側がn 'であり、右側がベースタイプのシーケンスまたはセットのコンポーネントの名前を付け、その後にnが続く主要な非末端である文法に生産が追加されます。'、 と
(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.
(3) プロダクションの左側がn 'で、右側が空である文法に生産が追加されます。
Example
例
Consider the following ASN.1 type definition:
次のasn.1タイプ定義を考えてみましょう。
SEQUENCE SIZE(1..MAX) OF number INTEGER
数字整数のシーケンスサイズ（1..max）
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.
すべての内部サブタイピング（InnerTypecontraints）は、サイズゼロの値がタイプのシーケンスまたはセットによって許可されるかどうかを決定する目的で無視されます。
This completes the description of the transformation of ASN.1 combining type definitions into a grammar.
これにより、asn.1のタイプ定義を文法に組み合わせた変換の説明が完了します。
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.
このセクションでは、文法が満たさなければならない条件について説明します。これにより、受信したRxERエンコードの各要素と属性がASN.1コンポーネントの定義と一意に関連付けられます。
Definition (used by the grammar): A non-terminal, N, is used by the grammar if:
定義（文法で使用）：非末端nは、次の場合に文法によって使用されます。
(1) N is the start symbol or
(1) nはスタート記号です
(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.
(2) nは、左側の非ターミナルが文法で使用される生産の右側に表示されます。
Definition (multiple derivation paths): A non-terminal, N, has multiple derivation paths if:
定義（複数の派生パス）：非末端nには、次の場合の複数の派生パスがあります。
(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
(1) nは、左側の非末端に複数の派生パスがある、または
(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
(2) nは複数のプロダクションの右側に表示され、左側の非末端が文法によって使用されます。
(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.
(3) nはスタート記号であり、左側の非末端が文法で使用される生産の右側に表示されます。
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:
グループエンコーディング命令の対象となるコンポーネントを含むベースタイプを持つすべてのasn.1タイプの場合、このドキュメントで説明されている方法で導出された文法は、次のことではありません。
(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
(1) 文法で使用され、同じ拡張名を持つ要素コンポーネントに関連付けられている2つ以上の主要な非ターミナル、または
(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
(2) 文法で使用され、同じ拡張名を持つ属性コンポーネントに関連付けられている2つ以上の主要な非ターミナル、または
(3) a primary non-terminal that has multiple derivation paths and is associated with an attribute component.
(3) 複数の派生パスを持ち、属性コンポーネントに関連付けられている主要な非末端。
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.
さておき：ケース（1）は、抽象値のXMLエンコードに関して評価される表記表を参照するコンポーネントに応じています。ケース（1）は、広範なテストを行う必要なく（これは必然的に他のすべてのエンコードルールのエンコーディング命令を考慮する必要がある）、同じ拡張名を持つすべての兄弟要素が同等のタイプ定義に関連付けられていることを保証します。このような等価性により、要素名で参照されるコンポーネントは、どのタイプの定義とエンコーディング命令が適用されるかについて、あいまいさのない異なるasn.1エンコードルールを使用して再エンコードできます。
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.
ケース（2）および（3）は、属性名が常に最大で発生する可能性のある1つのコンポーネントと常に一意に関連付けられ、常に抽象値の同じ部分にネストされることを確認します。
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.
TAの文法は、変換のコンポーネントを実行した後に構築されます。この変換の結果が次に示されています。この例は、そのnamedTypeの主要な非末端を表すために、namedTypeの識別子のみを使用するという通常の規則から離れます。代わりに、最も外側のタイプに対するラベルを使用して、ユニークなコンポーネントの属性をよりよく説明します。非ターミナルに使用されるラベルは、右側に表示されます。
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. --
- タイプTCはもはや関心がありません。 -
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
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:
TAのタイプ定義は、2つ以上の主要な非ターミナルが同じ拡張名を持つ要素コンポーネントに関連付けられている2つのインスタンスがあるため、無効です。
(1) TA.b.c and TA.e (both generate the terminal "c"), and
(1) Ta.B.CおよびTa.E（両方とも端子「C」を生成）、および
(2) TD.g and TA.g (both generate the terminal "g").
(2) TD.GおよびTA.G（両方とも端子「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.
場合（2）、TD.GおよびTA.Gは同じインスタンスのANDAMETTYPE表記から派生しますが、変換のコンポーネントに続く異なるコンポーネントになります。変換のコンポーネントの後に自動タグ付けが適用されます。つまり、TD.GとTA.Gに対応するコンポーネントのタイプは異なるタグになり、したがってタイプは同等ではありません。
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").
TAのタイプ定義も無効です。これは、2つ以上のプライマリ非ターミナルが同じ拡張名を持つ属性コンポーネントに関連付けられているため、Ta.B.BとTA.C（両方とも端子「@C」を生成する）に関連付けられているためです。
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.
複数の派生パスを持つ非末端は、Ta.D、Ta.D.A、Ta.D.A.A、Ta.D.A.B、TB.A、TB.B、およびTB.F.TA.D.A.AおよびTB.Bは、属性コンポーネントに関連付けられている主要な非末端であるため、TAのタイプ定義も無効です。
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.
最初に示された生産pの最初のセットを、すべての要素端子tのセットとします。ここで、Tは、Pの右側から生成できる一連の端子の最初の要素端子です。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 "$".
次の以下の非末端nのフォローセット（n）は、文法から生成できる非末端および端子のシーケンスでNに続く最初の要素端子であるすべての要素端子tのセットとします。。NとTの間には任意の数の属性端子があります。文法と端末のシーケンスを生成できる場合、Nの要素端子が続いていない場合は、（n）には特別な端端子も含まれます。「$」で示されます。
Aside: If N does not appear on the right-hand side of any production, then Follow(N) will be empty.
さておき：nが生産の右側に表示されない場合、フォロー（n）は空になります。
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.
生産pの場合、端子の空のシーケンスがPから生成できる場合にのみ、述語を空（p）にします。
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.
生産Pの場合、基本文法のみを使用してPの右側から生成できる端子のすべてのシーケンスに、少なくとも1つの属性端子が含まれる場合にのみ、述語が事前に選択された（p）を真実にします。それ以外の場合、事前に選択された（p）は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).
select（p）を示された生産pのselectセットは、事前に選択された（p）が真である場合は空です。それ以外の場合は、最初（p）が含まれます。nをPの左側の非末端とします。空の（p）がtrueの場合、（p）はフォロー（n）も含まれます。
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.
さておき、実際には、属性が要素の開始タグ内で順序付けられておらず、文法が示唆するように子要素が散在していないため、属性を文法に含めることはやや疑わしいように見えるかもしれません。これが、属性端子が最初のセットとフォローセットを作成する際に無視される理由です。ただし、属性端子は、生産を事前に選択でき、生産が空の端子シーケンスを生成できないようにすることができるため、選択セットを作成する上で重要です。実際には、これは属性を使用してrxerデコーダーに対応して、オプションのコンポーネントの有無を決定し、子要素を検討する前であっても、選択の代替案を選択します。
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.
Noted Reach（n）を示す非末端Nのリーチセットを、Nから生成できる一連の端子にtが表示されるすべての要素端子tのセットとします。
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:
文法は、次の場合にのみ決定論的です（RXERデコーダーの目的のため）。
(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
(1) 2つのプロダクションPとQは存在しません。左側に同じ非末端があり、Select（P）とSelect（Q）の交点が空ではなく、
(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.
(2) リーチ（e）とフォロー（e）の交差点が空でない場合、拡張拡張拡張および拡張拡張拡張対立のための非末端Eは存在しません。
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.
さておき：（1）、交差点が空でない場合、デコーダーには、入力を抽象値にデコードしようとする2つ以上の可能な方法があります。場合（2）、交差点が空でない場合、ASN.1仕様の以前のバージョンを使用するデコーダーは、未知の（そのデコーダー）拡張機能の要素を拡張後に既知のコンポーネントと混同します。
Aside: In the absence of any attribute components, case (1) is the test for an LL(1) grammar.
さておき：属性コンポーネントがない場合、ケース（1）はLL（1）文法のテストです。
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.
グループエンコーディング命令の対象となるコンポーネントを含むベースタイプを持つすべてのasn.1タイプの場合、このドキュメントで説明されている方法で導出される文法は決定論的でなければなりません。
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.
さておき：非末端に複数の派生パスがある場合、将来の拡張機能は、セクション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.
決定論的な文法の場合、正しく形成されたRxERエンコードの要素の要素コンテンツを一致させる一連の要素端子を構築する可能性のある方法は1つだけです。その構造で未知の属性を受け入れることができる少なくとも1つの挿入点生産が使用される場合、要素の未知の属性が受け入れられます。
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"
The third production is an insertion point production, and it is able to accept unknown attributes.
3番目の生産は挿入ポイント生産であり、未知の属性を受け入れることができます。
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).
このタイプの値をデコードする場合、要素コンテンツに<one>子要素が含まれている場合、挿入点の生成が入力を認識するために使用されないため、認識されていない属性は違法です（「1つの」選択肢は、拡張挿入点）。要素コンテンツに<3>要素が含まれている場合、挿入ポイント生成を使用して入力を認識するために認識されていない属性が受け入れられます（<3>要素を生成する「2つの」代替は、拡張可能なタイプを持っています）。
If the SEQUENCE type were prefixed by a NO-INSERTIONS encoding instruction, then the third, fourth, and fifth productions would be replaced by:
シーケンスタイプに、命令をエンコードする無効化が付いている場合、3番目、4番目、および5番目のプロダクションは次のものに置き換えられます。
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:
未知の属性を受け入れることができる複数の挿入ポイント生産が、一致する要素端子の一致シーケンスを構築する際に使用される場合、デコーダーは、認識されていない属性をそれらの挿入点プロダクションに対応する拡張挿入ポイントのいずれかに自由に関連付けることができます。そうすることの正当化は、次の2つの観察結果から来ています。
(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.
(1) 抽象値のエンコーディングに、拡張機能のタイプが受信機に知られていない拡張機能が含まれている場合、受信したエンコードの標準的なバリアントを含む、異なるエンコードルールのセットを使用して値を再エンコードすることは一般に不可能です。これは、どのエンコーディングルールが使用されていても真実です。デコーダーがエラーを上げずに拡張機能の生のエンコードを受け入れて保存し、同じ非標準エンコードルールを使用して抽象値を再エンコードするときに拡張機能の生のエンコードを再挿入できることが望ましいです。ただし、アプリケーションが不明な拡張機能でできることはほとんどありません。
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.
RXERを使用したアプリケーションは、どの拡張挿入ポイントに起因するかにかかわらず、認識されていない属性を正常に受け入れ、保存、および再エンコードできます。
(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.
(2) 単一の拡張挿入ポイントがある場合でも、未知の拡張機能は、無限の数の有効なタイプ定義のいずれかの値のエンコードである可能性があります。たとえば、属性または要素コンポーネントは、コンポーネントがグループエンコーディング命令の対象となる選択肢内の任意の任意の深さにネストできます。
Aside: A similar series of nested CHOICEs could describe an unknown extension in a Basic Encoding Rules (BER) encoding [X.690].
さておき：同様の一連のネストされた選択肢は、[X.690]をエンコードする基本エンコーディングルール（BER）の未知の拡張機能を説明できます。
ASN.1 compiler implementors should take special care to be thorough in checking that the GROUP encoding instruction has been correctly used; otherwise, ASN.1 specifications with ambiguous RXER encodings could be deployed.
ASN.1コンパイラの実装者は、グループエンコーディング命令が正しく使用されていることを確認するために、特別な注意を払う必要があります。それ以外の場合、ASN.1曖昧なRXERエンコーディングを使用した仕様を展開できます。
Ambiguous encodings mean that the abstract value recovered by a decoder may differ from the original abstract value that was encoded. If that is the case, then a digital signature generated with respect to the original abstract value (using a canonical encoding other than CRXER) will not be successfully verified by a receiver using the decoded abstract value. Also, an abstract value may have security-sensitive fields, and in particular, fields used to grant or deny access. If the decoded abstract value differs from the encoded abstract value, then a receiver using the decoded abstract value will be applying different security policy than that embodied in the original abstract value.
あいまいなエンコーディングは、デコーダーによって回復された抽象値が、エンコードされた元の抽象値と異なる場合があることを意味します。その場合、元の抽象値に関して生成されたデジタル署名（CRXER以外の標準エンコードを使用）は、デコードされた抽象値を使用して受信機によって正常に検証されません。また、抽象的な価値には、セキュリティに敏感なフィールド、特にアクセスの付与または拒否に使用されるフィールドがあります。デコードされた抽象値がエンコードされた抽象値と異なる場合、デコードされた抽象値を使用したレシーバーは、元の抽象値に具体化されたものとは異なるセキュリティポリシーを適用します。
[BCP14] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[BCP14] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[URI] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[URI] Berners-Lee、T.、Fielding、R。and L. Masinter、「ユニフォームリソース識別子（URI）：汎用構文」、STD 66、RFC 3986、2005年1月。
[RXER] Legg, S. and D. Prager, "Robust XML Encoding Rules (RXER) for Abstract Syntax Notation One (ASN.1)", RFC 4910, July 2007.
[Rxer] Legg、S。およびD. Prager、「抽象的構文表記1（ASN.1）のための堅牢なXMLエンコードルール（RXER）」、RFC 4910、2007年7月。
[ASN.X] Legg, S., "Abstract Syntax Notation X (ASN.X)", RFC 4912, July 2007.
[ASN.X] Legg、S。、「Abstract Syntax Notation X（ASN.X）」、RFC 4912、2007年7月。
[X.680] ITU-T Recommendation X.680 (07/02) | ISO/IEC 8824-1, Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation.
[X.680] ITU-T推奨X.680（07/02）|ISO/IEC 8824-1、情報技術 - 抽象的構文表記1（ASN.1）：基本表記の仕様。
[X.680-1] ITU-T Recommendation X.680 (2002) Amendment 1 (10/03) | ISO/IEC 8824-1:2002/Amd 1:2004, Support for EXTENDED-XER.
[X.680-1] ITU-Tの推奨X.680（2002）修正1（10/03）|ISO/IEC 8824-1：2002/AMD 1：2004、Extend-Xerのサポート。
[X.683] ITU-T Recommendation X.683 (07/02) | ISO/IEC 8824-4, Information technology - Abstract Syntax Notation One (ASN.1): Parameterization of ASN.1 specifications.
[X.683] ITU-T推奨X.683（07/02）|ISO/IEC 8824-4、情報技術 - 抽象的な構文表記1（ASN.1）：ASN.1仕様のパラメーター化。
[XML10] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E. and F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fourth Edition)", W3C Recommendation, http://www.w3.org/TR/2006/REC-xml-20060816, August 2006.
[XML10] Bray、T.、Paoli、J.、Sperberg-Mcqueen、C.、Maler、E。and F. Yergeau、「拡張可能なマークアップ言語（XML）1.0（第4版）」、W3C推奨、http：//www.w3.org/tr/2006/REC-XML-20060816、2006年8月。
[XMLNS10] Bray, T., Hollander, D., Layman, A., and R. Tobin, "Namespaces in XML 1.0 (Second Edition)", W3C Recommendation, http://www.w3.org/TR/2006/REC-xml-names-20060816, August 2006.
[XMLNS10] Bray、T.、Hollander、D.、Layman、A。、およびR. Tobin、「XML 1.0の名前空間（第2版）」、W3C推奨、http://www.w3.org/tr/2006/rec-xml-names-20060816、2006年8月。
[XSD1] Thompson, H., Beech, D., Maloney, M. and N. Mendelsohn, "XML Schema Part 1: Structures Second Edition", W3C Recommendation, http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/, October 2004.
[XSD1] Thompson、H.、Beech、D.、Maloney、M.、N。Mendelsohn、「XML Schema Part 1：Structures Second Edition」、W3C推奨、http://www.w3.org/tr/2004/rec-xmlschema-1-20041028/、2004年10月。
[XSD2] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes Second Edition", W3C Recommendation, http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/, October 2004.
[XSD2] Biron、P。and A. Malhotra、「XML Schema Part 2：Datatypes Second Edition」、W3C推奨、http：//www.w3.org/tr/2004/REC-XMLSCHEMA-2-20041028/、10月、10月2004年。
[RNG] Clark, J. and M. Makoto, "RELAX NG Tutorial", OASIS Committee Specification, http://www.oasis-open.org/ committees/relax-ng/tutorial-20011203.html, December 2001.
[RNG] Clark、J。およびM. Makoto、「リラックスNGチュートリアル」、OASIS委員会の仕様、http：//www.oasis-open.org/委員会/rack-ng/tutorial-20011203.html、2001年12月。
[INFOSET] Cowan, J. and R. Tobin, "XML Information Set (Second Edition)", W3C Recommendation, http://www.w3.org/ TR/2004/REC-xml-infoset-20040204, February 2004.
[Infoset] Cowan、J。and R. Tobin、「XML Information Set（第2版）」、W3C推奨、http：//www.w3.org/ TR/2004/REC-XML-infoset-20040204、2004年2月。
[X.690] ITU-T Recommendation X.690 (07/02) | ISO/IEC 8825-1, Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER).
[X.690] ITU-T推奨X.690（07/02）|ISO/IEC 8825-1、情報技術-ASN.1エンコーディングルール：基本エンコードルール（BER）、標準エンコーディングルール（CER）、および識別されたエンコードルール（DER）の指定。
This appendix is non-normative.
この付録は非規範的です。
This appendix contains examples of both correct and incorrect use of the GROUP encoding instruction, determined with respect to the grammars derived from the example type definitions. The productions of the grammars are labeled for convenience. Sets and predicates for non-terminals with only one production will be omitted from the examples since they never indicate non-determinism.
この付録には、サンプルタイプ定義から派生した文法に関して決定されたグループエンコーディング命令の正確な使用と誤った使用の例が含まれています。文法の生産には便利なラベルが付けられています。非ターミン主義を示さないため、例から1つの生産のみを持つ非ターミナルのセットと述語は省略されます。
The requirements of Section 25.1.2 ("Unique Component Attribution") are satisfied by all the examples in this appendix and the appendices that follow it.
セクション25.1.2（「一意のコンポーネント属性」）の要件は、この付録のすべての例とそれに続く付録によって満たされます。
Consider this type definition:
このタイプ定義を考えてみましょう。
SEQUENCE {
one [GROUP] SEQUENCE {
two UTF8String OPTIONAL
} OPTIONAL,
three INTEGER
}
The associated grammar is:
関連する文法は次のとおりです。
P1: S ::= one three
P2: one ::= two
P3: one ::=
P4: two ::= "two"
P5: two ::=
P6: three ::= "three"
Select Sets have to be evaluated to test the validity of the type definition. The grammar leads to the following sets and predicates:
タイプ定義の妥当性をテストするには、選択セットを評価する必要があります。文法は、次のセットと述語につながります。
First(P2) = { "two" }
First(P3) = { }
Preselected(P2) = Preselected(P3) = false
Empty(P2) = Empty(P3) = true
Follow(one) = { "three" }
Select(P2) = First(P2) + Follow(one) = { "two", "three" }
Select(P3) = First(P3) + Follow(one) = { "three" }
First(P4) = { "two" }
First(P5) = { }
Preselected(P4) = Preselected(P5) = Empty(P4) = false
Empty(P5) = true
Follow(two) = { "three" }
Select(P4) = First(P4) = { "two" }
Select(P5) = First(P5) + Follow(two) = { "three" }
The intersection of Select(P2) and Select(P3) is not empty; hence, the grammar is not deterministic, and the type definition is not valid. If the RXER encoding of a value of the type does not have a child element <two>, then it is not possible to determine whether the "one" component is present or absent in the value.
select（p2）とselect（p3）の交点は空ではありません。したがって、文法は決定論的ではなく、タイプ定義は有効ではありません。タイプの値のrxerエンコードに子要素<2>がない場合、「1つの」コンポーネントが値に存在するのか、存在しないかを判断することはできません。
Now consider this type definition with attributes in the "one" component:
次に、このタイプ定義を「1つの」コンポーネントに属性を使用して考えてみましょう。
SEQUENCE {
one [GROUP] SEQUENCE {
two UTF8String OPTIONAL,
four [ATTRIBUTE] BOOLEAN,
five [ATTRIBUTE] BOOLEAN OPTIONAL
} OPTIONAL,
three INTEGER
}
The associated grammar is:
関連する文法は次のとおりです。
P1: S ::= one three
P2: one ::= two four five
P3: one ::=
P4: two ::= "two"
P5: two ::=
P6: four ::= "@four"
P7: five ::= "@five"
P8: five ::=
P9: three ::= "three"
This grammar leads to the following sets and predicates:
この文法は、次のセットと述語につながります。
First(P2) = { "two" }
First(P3) = { }
Preselected(P3) = Empty(P2) = false
Preselected(P2) = Empty(P3) = true
Follow(one) = { "three" }
Select(P2) = { }
Select(P3) = First(P3) + Follow(one) = { "three" }
First(P4) = { "two" }
First(P5) = { }
Preselected(P4) = Preselected(P5) = Empty(P4) = false
Empty(P5) = true
Follow(two) = { "three" }
Select(P4) = First(P4) = { "two" }
Select(P5) = First(P5) + Follow(two) = { "three" }
First(P7) = { }
First(P8) = { }
Preselected(P8) = Empty(P7) = false
Preselected(P7) = Empty(P8) = true
Follow(five) = { "three" }
Select(P7) = { }
Select(P8) = First(P8) + Follow(five) = { "three" }
The intersection of Select(P2) and Select(P3) is empty, as is the intersection of Select(P4) and Select(P5) and the intersection of Select(P7) and Select(P8); hence, the grammar is deterministic, and the type definition is valid. In a correct RXER encoding, the "one" component will be present if and only if the "four" attribute is present.
select（p3）のselect（p2）とselect（p3）の交点は空で、select（p4）とselect（p5）とselect（p7）とselect（p8）の交差点と同様です。したがって、文法は決定論的であり、タイプ定義は有効です。正しいRXERエンコードでは、「4つの」属性が存在する場合にのみ、「1つの」コンポーネントが存在します。
Consider this type definition:
このタイプ定義を考えてみましょう。
CHOICE {
one [GROUP] SEQUENCE {
two [ATTRIBUTE] BOOLEAN OPTIONAL
},
three INTEGER,
four [GROUP] SEQUENCE {
five BOOLEAN OPTIONAL
}
}
The associated grammar is:
関連する文法は次のとおりです。
P1: S ::= one
P2: S ::= three
P3: S ::= four
P4: one ::= two
P5: two ::= "@two"
P6: two ::=
P7: three ::= "three"
P8: four ::= five
P9: five ::= "five"
P10: five ::=
This grammar leads to the following sets and predicates:
この文法は、次のセットと述語につながります。
First(P1) = { }
First(P2) = { "three" }
First(P3) = { "five" }
Preselected(P1) = Preselected(P2) = Preselected(P3) = false
Empty(P2) = false
Empty(P1) = Empty(P3) = true
Follow(S) = { "$" }
Select(P1) = First(P1) + Follow(S) = { "$" }
Select(P2) = First(P2) = { "three" }
Select(P3) = First(P3) + Follow(S) = { "five", "$" }
First(P5) = { }
First(P6) = { }
Preselected(P6) = Empty(P5) = false
Preselected(P5) = Empty(P6) = true
Follow(two) = { "$" }
Select(P5) = { }
Select(P6) = First(P6) + Follow(two) = { "$" }
First(P9) = { "five" }
First(P10) = { }
Preselected(P9) = Preselected(P10) = Empty(P9) = false
Empty(P10) = true
Follow(five) = { "$" }
Select(P9) = First(P9) = { "five" }
Select(P10) = First(P10) + Follow(five) = { "$" }
The intersection of Select(P1) and Select(P3) is not empty; hence, the grammar is not deterministic, and the type definition is not valid. If the RXER encoding of a value of the type is empty, then it is not possible to determine whether the "one" alternative or the "four" alternative has been chosen.
select（p1）とselect（p3）の交点は空ではありません。したがって、文法は決定論的ではなく、タイプ定義は有効ではありません。タイプの値のrxerエンコードが空である場合、「1つの」代替案または「4」の代替手段が選択されているかどうかを判断することはできません。
Now consider this slightly different type definition:
次に、このわずかに異なるタイプ定義を検討してください。
CHOICE {
one [GROUP] SEQUENCE {
two [ATTRIBUTE] BOOLEAN
},
three INTEGER,
four [GROUP] SEQUENCE {
five BOOLEAN OPTIONAL
}
}
The associated grammar is:
関連する文法は次のとおりです。
P1: S ::= one
P2: S ::= three
P3: S ::= four
P4: one ::= two
P5: two ::= "@two"
P6: three ::= "three"
P7: four ::= five
P8: five ::= "five"
P9: five ::=
This grammar leads to the following sets and predicates:
この文法は、次のセットと述語につながります。
First(P1) = { }
First(P2) = { "three" }
First(P3) = { "five" }
Preselected(P2) = Preselected(P3) = false
Empty(P1) = Empty(P2) = false
Preselected(P1) = Empty(P3) = true
Follow(S) = { "$" }
Select(P1) = { }
Select(P2) = First(P2) = { "three" }
Select(P3) = First(P3) + Follow(S) = { "five", "$" }
First(P8) = { "five" }
First(P9) = { }
Preselected(P8) = Preselected(P9) = Empty(P8) = false
Empty(P9) = true
Follow(five) = { "$" }
Select(P8) = First(P8) = { "five" }
Select(P9) = First(P9) + Follow(five) = { "$" }
The intersection of Select(P1) and Select(P2) is empty, the intersection of Select(P1) and Select(P3) is empty, the intersection of Select(P2) and Select(P3) is empty, and the intersection of Select(P8) and Select(P9) is empty; hence, the grammar is deterministic, and the type definition is valid. The "one" and "four" alternatives can be distinguished because the "one" alternative has a mandatory attribute.
select（p1）とselect（p2）の交差点は空で、select（p1）とselect（p3）の交差点は空で、select（p2）とselect（p3）の交差点は空で、selectの交差点は空です（p8）およびselect（p9）は空です。したがって、文法は決定論的であり、タイプ定義は有効です。「1つの」代替品には必須の属性があるため、「1つ」と「4」の代替品を区別できます。
Consider this type definition:
このタイプ定義を考えてみましょう。
SEQUENCE {
one [GROUP] CHOICE {
two [ATTRIBUTE] BOOLEAN,
three [GROUP] SEQUENCE OF number INTEGER
} OPTIONAL
}
The associated grammar is:
関連する文法は次のとおりです。
P1: S ::= one
P2: one ::= two
P3: one ::= three
P4: one ::=
P5: two ::= "@two"
P6: three ::= number three
P7: three ::=
P8: number ::= "number"
This grammar leads to the following sets and predicates:
この文法は、次のセットと述語につながります。
First(P2) = { }
First(P3) = { "number" }
First(P4) = { }
Preselected(P3) = Preselected(P4) = Empty(P2) = false
Preselected(P2) = Empty(P3) = Empty(P4) = true
Follow(one) = { "$" }
Select(P2) = { }
Select(P3) = First(P3) + Follow(one) = { "number", "$" }
Select(P4) = First(P4) + Follow(one) = { "$" }
First(P6) = { "number" }
First(P7) = { }
Preselected(P6) = Preselected(P7) = Empty(P6) = false
Empty(P7) = true
Follow(three) = { "$" }
Select(P6) = First(P6) = { "number" }
Select(P7) = First(P7) + Follow(three) = { "$" }
The intersection of Select(P3) and Select(P4) is not empty; hence, the grammar is not deterministic, and the type definition is not valid. If the RXER encoding of a value of the type is empty, then it is not possible to determine whether the "one" component is absent or the empty "three" alternative has been chosen.
select（p3）とselect（p4）の交点は空ではありません。したがって、文法は決定論的ではなく、タイプ定義は有効ではありません。タイプの値のrxerエンコードが空である場合、「1つの」コンポーネントが存在しないのか、空の「3」の代替が選択されているのかを判断することはできません。
Consider this type definition:
このタイプ定義を考えてみましょう。
SEQUENCE {
one [GROUP] CHOICE {
two [ATTRIBUTE] BOOLEAN,
three [ATTRIBUTE] BOOLEAN
} OPTIONAL
}
The associated grammar is:
関連する文法は次のとおりです。
P1: S ::= one
P2: one ::= two
P3: one ::= three
P4: one ::=
P5: two ::= "@two"
P6: three ::= "@three"
This grammar leads to the following sets and predicates:
この文法は、次のセットと述語につながります。
First(P2) = { }
First(P3) = { }
First(P4) = { }
Preselected(P4) = Empty(P2) = Empty(P3) = false
Preselected(P2) = Preselected(P3) = Empty(P4) = true
Follow(one) = { "$" }
Select(P2) = { }
Select(P3) = { }
Select(P4) = First(P4) + Follow(one) = { "$" }
The intersection of Select(P2) and Select(P3) is empty, the intersection of Select(P2) and Select(P4) is empty, and the intersection of Select(P3) and Select(P4) is empty; hence, the grammar is deterministic, and the type definition is valid.
select（p2）とselect（p3）の交差点は空で、select（p2）とselect（p4）の交点は空で、select（p3）とselect（p4）の交差点は空です。したがって、文法は決定論的であり、タイプ定義は有効です。
Consider this type definition:
このタイプ定義を考えてみましょう。
SEQUENCE {
one [GROUP] SEQUENCE OF number INTEGER OPTIONAL
}
The associated grammar is:
関連する文法は次のとおりです。
P1: S ::= one
P2: one ::= number one
P3: one ::=
P4: one ::=
P5: number ::= "number"
P3 is generated during the processing of the SEQUENCE OF type. P4 is generated because the "one" component is optional.
P3は、タイプのシーケンスの処理中に生成されます。「1つの」コンポーネントがオプションであるため、P4が生成されます。
This grammar leads to the following sets and predicates:
この文法は、次のセットと述語につながります。
First(P2) = { "number" }
First(P3) = { }
First(P4) = { }
Preselected(P2) = Preselected(P3) = Preselected(P4) = false
Empty(P2) = false
Empty(P3) = Empty(P4) = true
Follow(one) = { "$" }
Select(P2) = First(P2) = { "number" }
Select(P3) = First(P3) + Follow(one) = { "$" }
Select(P4) = First(P4) + Follow(one) = { "$" }
The intersection of Select(P3) and Select(P4) is not empty; hence, the grammar is not deterministic, and the type definition is not valid. If the RXER encoding of a value of the type does not have any <number> child elements, then it is not possible to determine whether the "one" component is present or absent in the value.
select（p3）とselect（p4）の交点は空ではありません。したがって、文法は決定論的ではなく、タイプ定義は有効ではありません。タイプの値のrxerエンコードに<number>子要素がない場合、「1つの」コンポーネントが値に存在するのか、存在しないかを判断することはできません。
Consider this similar type definition with a SIZE constraint:
サイズの制約を備えたこの同様のタイプ定義を考えてみましょう。
SEQUENCE {
one [GROUP] SEQUENCE SIZE(1..MAX) OF number INTEGER OPTIONAL
}
The associated grammar is:
関連する文法は次のとおりです。
P1: S ::= one
P2: one ::= number one'
P3: one' ::= number one'
P4: one' ::=
P5: one ::=
P6: number ::= "number"
This grammar leads to the following sets and predicates:
この文法は、次のセットと述語につながります。
First(P2) = { "number" }
First(P5) = { }
Preselected(P2) = Preselected(P5) = Empty(P2) = false
Empty(P5) = true
Follow(one) = { "$" }
Select(P2) = First(P2) = { "number" }
Select(P5) = First(P5) + Follow(one) = { "$" }
First(P3) = { "number" }
First(P4) = { }
Preselected(P3) = Preselected(P4) = Empty(P3) = false
Empty(P4) = true
Follow(one') = { "$" }
Select(P3) = First(P3) = { "number" }
Select(P4) = First(P4) + Follow(one') = { "$" }
The intersection of Select(P2) and Select(P5) is empty, as is the intersection of Select(P3) and Select(P4); hence, the grammar is deterministic, and the type definition is valid. If there are no <number> child elements, then the "one" component is necessarily absent and there is no ambiguity.
select（p5）とselect（p5）の交差点は空であり、select（p3）とselect（p4）の交点も同様です。したがって、文法は決定論的であり、タイプ定義は有効です。<number>の要素がない場合、「1つの」コンポーネントは必ずしも存在せず、あいまいさはありません。
Consider this type definition:
このタイプ定義を考えてみましょう。
SEQUENCE {
beginning [GROUP] List,
middle UTF8String OPTIONAL,
end [GROUP] List
}
List ::= SEQUENCE OF string UTF8String
The associated grammar is:
関連する文法は次のとおりです。
P1: S ::= beginning middle end
P2: beginning ::= string beginning
P3: beginning ::=
P4: middle ::= "middle"
P5: middle ::=
P6: end ::= string end
P7: end ::=
P8: string ::= "string"
This grammar leads to the following sets and predicates:
この文法は、次のセットと述語につながります。
First(P2) = { "string" }
First(P3) = { }
Preselected(P2) = Preselected(P3) = Empty(P2) = false
Empty(P3) = true
Follow(beginning) = { "middle", "string", "$" }
Select(P2) = First(P2) = { "string" }
Select(P3) = First(P3) + Follow(beginning)
= { "middle", "string", "$" }
First(P4) = { "middle" }
First(P5) = { }
Preselected(P4) = Preselected(P5) = Empty(P4) = false
Empty(P5) = true
Follow(middle) = { "string", "$" }
Select(P4) = First(P4) = { "middle" }
Select(P5) = First(P5) + Follow(middle) = { "string", "$" }
First(P6) = { "string" }
First(P7) = { }
Preselected(P6) = Preselected(P7) = Empty(P6) = false
Empty(P7) = true
Follow(end) = { "$" }
Select(P6) = First(P6) = { "string" }
Select(P7) = First(P7) + Follow(end) = { "$" }
The intersection of Select(P2) and Select(P3) is not empty; hence, the grammar is not deterministic, and the type definition is not valid.
select（p2）とselect（p3）の交点は空ではありません。したがって、文法は決定論的ではなく、タイプ定義は有効ではありません。
Now consider the following type definition:
次に、次のタイプ定義を検討してください。
SEQUENCE {
beginning [GROUP] List,
middleAndEnd [GROUP] SEQUENCE {
middle UTF8String,
end [GROUP] List
} OPTIONAL
}
The associated grammar is:
関連する文法は次のとおりです。
P1: S ::= beginning middleAndEnd
P2: beginning ::= string beginning
P3: beginning ::=
P4: middleAndEnd ::= middle end
P5: middleAndEnd ::=
P6: middle ::= "middle"
P7: end ::= string end
P8: end ::=
P9: string ::= "string"
This grammar leads to the following sets and predicates:
この文法は、次のセットと述語につながります。
First(P2) = { "string" }
First(P3) = { }
Preselected(P2) = Preselected(P3) = Empty(P2) = false
Empty(P3) = true
Follow(beginning) = { "middle", "$" }
Select(P2) = First(P2) = { "string" }
Select(P3) = First(P3) + Follow(beginning) = { "middle", "$" }
First(P4) = { "middle" }
First(P5) = { }
Preselected(P4) = Preselected(P5) = Empty(P4) = false
Empty(P5) = true
Follow(middleAndEnd) = { "$" }
Select(P4) = First(P4) = { "middle" }
Select(P5) = First(P5) + Follow(middleAndEnd) = { "$" }
First(P7) = { "string" }
First(P8) = { }
Preselected(P7) = Preselected(P8) = Empty(P7) = false
Empty(P8) = true
Follow(end) = { "$" }
Select(P7) = First(P7) = { "string" }
Select(P8) = First(P8) + Follow(end) = { "$" }
The intersection of Select(P2) and Select(P3) is empty, as is the intersection of Select(P4) and Select(P5) and the intersection of Select(P7) and Select(P8); hence, the grammar is deterministic, and the type definition is valid.
select（p3）のselect（p2）とselect（p3）の交点は空で、select（p4）とselect（p5）とselect（p7）とselect（p8）の交差点と同様です。したがって、文法は決定論的であり、タイプ定義は有効です。
Consider the following type definition:
次のタイプ定義を検討してください。
SEQUENCE SIZE(1..MAX) OF
one [GROUP] SEQUENCE {
two INTEGER OPTIONAL
}
The associated grammar is:
関連する文法は次のとおりです。
P1: S ::= one S'
P2: S' ::= one S'
P3: S' ::=
P4: one ::= two
P5: two ::= "two"
P6: two ::=
This grammar leads to the following sets and predicates:
この文法は、次のセットと述語につながります。
First(P2) = { "two" }
First(P3) = { }
Preselected(P2) = Preselected(P3) = false
Empty(P2) = Empty(P3) = true
Follow(S') = { "$" }
Select(P2) = First(P2) + Follow(S') = { "two", "$" }
Select(P3) = First(P3) + Follow(S') = { "$" }
First(P5) = { "two" }
First(P6) = { }
Preselected(P5) = Preselected(P6) = Empty(P5) = false
Empty(P6) = true
Follow(two) = { "two", "$" }
Select(P5) = First(P5) = { "two" }
Select(P6) = First(P6) + Follow(two) = { "two", "$" }
The intersection of Select(P2) and Select(P3) is not empty and the intersection of Select(P5) and Select(P6) is not empty; hence, the grammar is not deterministic, and the type definition is not valid. The encoding of a value of the type contains an indeterminate number of empty instances of the component type.
select（p2）とselect（p3）の交点は空ではなく、select（p5）とselect（p6）の交差点は空ではありません。したがって、文法は決定論的ではなく、タイプ定義は有効ではありません。タイプの値のエンコードには、コンポーネントタイプの空の空のインスタンスの不確定な数が含まれています。
Consider the following type definition:
次のタイプ定義を検討してください。
SEQUENCE OF list [GROUP] SEQUENCE SIZE(1..MAX) OF number INTEGER
リスト整数のリストのシーケンス[グループ]シーケンスサイズ（1..max）
The associated grammar is:
関連する文法は次のとおりです。
P1: S ::= list S
P2: S ::=
P3: list ::= number list'
P4: list' ::= number list'
P5: list' ::=
P6: number ::= "number"
This grammar leads to the following sets and predicates:
この文法は、次のセットと述語につながります。
First(P1) = { "number" }
First(P2) = { }
Preselected(P1) = Preselected(P2) = Empty(P1) = false
Empty(P2) = true
Follow(S) = { "$" }
Select(P1) = First(P1) = { "number" }
Select(P2) = First(P2) + Follow(S) = { "$" }
First(P4) = { "number" }
First(P5) = { }
Preselected(P4) = Preselected(P5) = Empty(P4) = false
Empty(P5) = true
Follow(list') = { "number", "$" }
Select(P4) = First(P4) = { "number" }
Select(P5) = First(P5) + Follow(list') = { "number", "$" }
The intersection of Select(P4) and Select(P5) is not empty; hence, the grammar is not deterministic, and the type definition is not valid. The type describes a list of lists, but it is not possible for a decoder to determine where the outer lists begin and end.
select（p4）とselect（p5）の交点は空ではありません。したがって、文法は決定論的ではなく、タイプ定義は有効ではありません。このタイプはリストのリストを説明しますが、デコーダーが外側のリストの開始と終了場所を決定することはできません。
Consider the following type definition:
次のタイプ定義を検討してください。
SEQUENCE OF item [GROUP] SEQUENCE {
before [GROUP] OneAndTwo,
core UTF8String,
after [GROUP] OneAndTwo OPTIONAL
}
OneAndTwo ::= SEQUENCE {
non-core UTF8String
}
The associated grammar is:
関連する文法は次のとおりです。
P1: S ::= item S
P2: S ::=
P3: item ::= before core after
P4: before ::= non-core
P5: non-core ::= "non-core"
P6: core ::= "core"
P7: after ::= non-core
P8: after ::=
This grammar leads to the following sets and predicates:
この文法は、次のセットと述語につながります。
First(P1) = { "non-core" }
First(P2) = { }
Preselected(P1) = Preselected(P2) = Empty(P1) = false
Empty(P2) = true
Follow(S) = { "$" }
Select(P1) = First(P1) = { "non-core" }
Select(P2) = First(P2) + Follow(S) = { "$" }
First(P7) = { "non-core" }
First(P8) = { }
Preselected(P7) = Preselected(P8) = Empty(P7) = false
Empty(P8) = true
Follow(after) = { "non-core", "$" }
Select(P7) = First(P7) = { "non-core" }
Select(P8) = First(P8) + Follow(after) = { "non-core", "$" }
The intersection of Select(P7) and Select(P8) is not empty; hence, the grammar is not deterministic, and the type definition is not valid. There is ambiguity between the end of one item and the start of the next. Without looking ahead in an encoding, it is not possible to determine whether a <non-core> element belongs with the preceding or following <core> element.
select（p7）とselect（p8）の交点は空ではありません。したがって、文法は決定論的ではなく、タイプ定義は有効ではありません。1つのアイテムの終わりと次のアイテムの開始との間には曖昧さがあります。エンコーディングを先に見ていないと、<non-core>要素が前の<core>要素に属しているかどうかを判断することはできません。
Consider the following type definition:
次のタイプ定義を検討してください。
CHOICE {
one [GROUP] List,
two [GROUP] SEQUENCE {
three [ATTRIBUTE] UTF8String,
four [GROUP] List
}
}
List ::= SEQUENCE OF string UTF8String
The associated grammar is:
関連する文法は次のとおりです。
P1: S ::= one
P2: S ::= two
P3: one ::= string one
P4: one ::=
P5: two ::= three four
P6: three ::= "@three"
P7: four ::= string four
P8: four ::=
P9: string ::= "string"
This grammar leads to the following sets and predicates:
この文法は、次のセットと述語につながります。
First(P1) = { "string" }
First(P2) = { "string" }
Preselected(P1) = Empty(P2) = false
Preselected(P2) = Empty(P1) = true
Follow(S) = { "$" }
Select(P1) = First(P1) + Follow(S) = { "string", "$" }
Select(P2) = { }
First(P3) = { "string" }
First(P4) = { }
Preselected(P3) = Preselected(P4) = Empty(P3) = false
Empty(P4) = true
Follow(one) = { "$" }
Select(P3) = First(P3) = { "string" }
Select(P4) = First(P4) + Follow(one) = { "$" }
First(P7) = { "string" }
First(P8) = { }
Preselected(P7) = Preselected(P8) = Empty(P7) = false
Empty(P8) = true
Follow(four) = { "$" }
Select(P7) = First(P7) = { "string" }
Select(P8) = First(P8) + Follow(four) = { "$" }
The intersection of Select(P1) and Select(P2) is empty, as is the intersection of Select(P3) and Select(P4) and the intersection of Select(P7) and Select(P8); hence, the grammar is deterministic, and the type definition is valid. Although both alternatives of the CHOICE can begin with a <string> element, an RXER decoder would use the presence of a "three" attribute to decide whether to select or disregard the "two" alternative.
select（p1）とselect（p2）の交点は空であり、select（p3）とselect（p4）の交点とselect（p7）とselect（p8）の交差点もそうです。したがって、文法は決定論的であり、タイプ定義は有効です。選択の両方の選択肢は<string>要素で始まることができますが、Rxerデコーダーは「3」の属性の存在を使用して、「2つの」代替案を選択または無視するかどうかを決定します。
However, an attribute in an extension cannot be used to select between alternatives. Consider the following type definition:
ただし、拡張機能内の属性を使用して、代替案を選択することはできません。次のタイプ定義を検討してください。
[SINGULAR-INSERTIONS] CHOICE {
one [GROUP] List,
...,
two [GROUP] SEQUENCE {
three [ATTRIBUTE] UTF8String,
four [GROUP] List
} -- ExtensionAdditionAlternative (E1).
-- The extension insertion point is here (I1).
}
List ::= SEQUENCE OF string UTF8String
The associated grammar is:
関連する文法は次のとおりです。
P1: S ::= one
P10: S ::= E1
P11: S ::= "*"
P12: E1 ::= two
P3: one ::= string one
P4: one ::=
P5: two ::= three four
P6: three ::= "@three"
P7: four ::= string four
P8: four ::=
P9: string ::= "string"
This grammar leads to the following sets and predicates for P1, P10 and P11:
この文法は、P1、P10、P11の次のセットと述語につながります。
First(P1) = { "string" }
First(P10) = { "string" }
First(P11) = { "*" }
Preselected(P1) = Preselected(P10) = Preselected(P11) = false
Empty(P10) = Empty(P11) = false
Empty(P1) = true
Follow(S) = { "$" }
Select(P1) = First(P1) + Follow(S) = { "string", "$" }
Select(P10) = First(P10) = { "string" }
Select(P11) = First(P11) = { "*" }
Preselected(P10) evaluates to false because Preselected(P10) is evaluated on the base grammar, wherein P10 is rewritten as:
事前に選択された（P10）は、事前に選択された（P10）が基本文法で評価されるため、falseに評価されます。P10は次のように書き換えられます。
P10: S ::=
The intersection of Select(P1) and Select(P10) is not empty; hence, the grammar is not deterministic, and the type definition is not valid. An RXER decoder using the original, unextended version of the definition would not know that the "three" attribute selects between the "one" alternative and the extension.
select（p1）とselect（p10）の交点は空ではありません。したがって、文法は決定論的ではなく、タイプ定義は有効ではありません。定義の元の拡張バージョンを使用したRxerデコーダーは、「3つの」属性が「1つの」代替と拡張機能の間で選択されることを知りません。
This appendix is non-normative.
この付録は非規範的です。
This appendix contains examples showing the use of insertion encoding instructions to remove extension ambiguity arising from use of the GROUP encoding instruction.
この付録には、グループエンコーディング命令の使用から生じる拡張のあいまいさを削除するための挿入エンコーディング命令の使用を示す例が含まれています。
Consider the following type definition:
次のタイプ定義を検討してください。
SEQUENCE {
one [GROUP] SEQUENCE {
two UTF8String,
... -- Extension insertion point (I1).
},
three INTEGER OPTIONAL,
... -- Extension insertion point (I2).
}
The associated grammar is:
関連する文法は次のとおりです。
P1: S ::= one three I2
P2: one ::= two I1
P3: two ::= "two"
P4: I1 ::= "*" I1
P5: I1 ::=
P6: three ::= "three"
P7: three ::=
P8: I2 ::= "*" I2
P9: I2 ::=
This grammar leads to the following sets and predicates:
この文法は、次のセットと述語につながります。
First(P4) = { "*" }
First(P5) = { }
Preselected(P4) = Preselected(P5) = Empty(P4) = false
Empty(P5) = true
Follow(I1) = { "three", "*", "$" }
Select(P4) = First(P4) = { "*" }
Select(P5) = First(P5) + Follow(I1) = { "three", "*", "$" }
First(P6) = { "three" }
First(P7) = { }
Preselected(P6) = Preselected(P7) = Empty(P6) = false
Empty(P7) = true
Follow(three) = { "*", "$" }
Select(P6) = First(P6) = { "three" }
Select(P7) = First(P7) + Follow(three) = { "*", "$" }
First(P8) = { "*" }
First(P9) = { }
Preselected(P8) = Preselected(P9) = Empty(P8) = false
Empty(P9) = true
Follow(I2) = { "$" }
Select(P8) = First(P8) = { "*" }
Select(P9) = First(P9) + Follow(I2) = { "$" }
The intersection of Select(P4) and Select(P5) is not empty; hence, the grammar is not deterministic, and the type definition is not valid. If an RXER decoder encounters an unrecognized element immediately after a <two> element, then it will not know whether to associate it with extension insertion point I1 or I2.
select（p4）とselect（p5）の交点は空ではありません。したがって、文法は決定論的ではなく、タイプ定義は有効ではありません。rxerデコーダーが<2> <2>要素の直後に認識されていない要素に遭遇する場合、拡張挿入点i1またはi2に関連付けるかどうかはわかりません。
The non-determinism can be resolved with either a NO-INSERTIONS or HOLLOW-INSERTIONS encoding instruction. Consider this revised type definition:
非決定論は、命令をエンコードするin insortionsまたは中空の挿入のいずれかで解決することができます。この改訂されたタイプ定義を考えてみましょう。
SEQUENCE {
one [GROUP] [HOLLOW-INSERTIONS] SEQUENCE {
two UTF8String,
... -- Extension insertion point (I1).
},
three INTEGER OPTIONAL,
... -- Extension insertion point (I2).
}
The associated grammar is:
関連する文法は次のとおりです。
P1: S ::= one three I2
P10: one ::= two
P3: two ::= "two"
P6: three ::= "three"
P7: three ::=
P8: I2 ::= "*" I2
P9: I2 ::=
With the addition of the HOLLOW-INSERTIONS encoding instruction, the P4 and P5 productions are no longer generated, and the conflict between Select(P4) and Select(P5) no longer exists. The Select Sets for P6, P7, P8, and P9 are unchanged. A decoder will now assume that an unrecognized element is to be associated with extension insertion point I2. It is still free to associate an unrecognized attribute with either extension insertion point. If a NO-INSERTIONS encoding instruction had been used, then an unrecognized attribute could only be associated with extension insertion point I2.
命令をエンコードする中空挿合の追加により、P4およびP5プロダクションはもはや生成されず、Select（P4）とSelect（P5）の間の競合は存在しなくなります。P6、P7、P8、およびP9の選択セットは変更されていません。デコーダーは、認識されていない要素が延長挿入点I2に関連付けられることを想定します。認識されていない属性をいずれかの拡張挿入点に関連付けることは、まだ自由です。No-Insortionsエンコード命令が使用されていた場合、認識されていない属性は、拡張挿入点I2にのみ関連付けられます。
The non-determinism could also be resolved by adding a NO-INSERTIONS or HOLLOW-INSERTIONS encoding instruction to the outer SEQUENCE:
非控訴主義は、外側のシーケンスに命令をエンコードする無意味または中空挿入を追加することによって解決することもできます。
[HOLLOW-INSERTIONS] SEQUENCE {
one [GROUP] SEQUENCE {
two UTF8String,
... -- Extension insertion point (I1).
},
three INTEGER OPTIONAL,
... -- Extension insertion point (I2).
}
The associated grammar is:
関連する文法は次のとおりです。
P11: S ::= one three
P2: one ::= two I1
P3: two ::= "two"
P4: I1 ::= "*" I1
P5: I1 ::=
P6: three ::= "three"
P7: three ::=
This grammar leads to the following sets and predicates:
この文法は、次のセットと述語につながります。
First(P4) = { "*" }
First(P5) = { }
Preselected(P4) = Preselected(P5) = Empty(P4) = false
Empty(P5) = true
Follow(I1) = { "three", "$" }
Select(P4) = First(P4) = { "*" }
Select(P5) = First(P5) + Follow(I1) = { "three", "$" }
First(P6) = { "three" }
First(P7) = { }
Preselected(P6) = Preselected(P7) = Empty(P6) = false
Empty(P7) = true
Follow(three) = { "$" }
Select(P6) = First(P6) = { "three" }
Select(P7) = First(P7) + Follow(three) = { "$" }
The intersection of Select(P4) and Select(P5) is empty, as is the intersection of Select(P6) and Select(P7); hence, the grammar is deterministic, and the type definition is valid. A decoder will now assume that an unrecognized element is to be associated with extension insertion point I1. It is still free to associate an unrecognized attribute with either extension insertion point. If a NO-INSERTIONS encoding instruction had been used, then an unrecognized attribute could only be associated with extension insertion point I1.
select（p5）とselect（p5）の交差点は空であり、select（p6）とselect（p7）の交点も同様です。したがって、文法は決定論的であり、タイプ定義は有効です。デコーダーは、認識されていない要素が延長挿入点I1に関連付けられることを想定します。認識されていない属性をいずれかの拡張挿入点に関連付けることは、まだ自由です。No-Insortionsエンコード命令が使用されていた場合、認識されていない属性は、拡張挿入点I1にのみ関連付けられます。
Consider the following type definition:
次のタイプ定義を検討してください。
SEQUENCE {
one [GROUP] CHOICE {
two UTF8String,
... -- Extension insertion point (I1).
} OPTIONAL
}
The associated grammar is:
関連する文法は次のとおりです。
P1: S ::= one
P2: one ::= two
P3: one ::= I1
P4: one ::=
P5: two ::= "two"
P6: I1 ::= "*" I1
P7: I1 ::=
This grammar leads to the following sets and predicates:
この文法は、次のセットと述語につながります。
First(P2) = { "two" }
First(P3) = { "*" }
First(P4) = { }
Preselected(P2) = Preselected(P3) = Preselected(P4) = false
Empty(P2) = false
Empty(P3) = Empty(P4) = true
Follow(one) = { "$" }
Select(P2) = First(P2) = { "two" }
Select(P3) = First(P3) + Follow(one) = { "*", "$" }
Select(P4) = First(P4) + Follow(one) = { "$" }
First(P6) = { "*" }
First(P7) = { }
Preselected(P6) = Preselected(P7) = Empty(P6) = false
Empty(P7) = true
Follow(I1) = { "$" }
Select(P6) = First(P6) = { "*" }
Select(P7) = First(P7) + Follow(I1) = { "$" }
The intersection of Select(P3) and Select(P4) is not empty; hence, the grammar is not deterministic, and the type definition is not valid. If the <two> element is not present, then a decoder cannot determine whether the "one" alternative is absent, or present with an unknown extension that generates no elements.
select（p3）とselect（p4）の交点は空ではありません。したがって、文法は決定論的ではなく、タイプ定義は有効ではありません。<2>要素が存在しない場合、デコーダーは「1つの」代替が存在しないか、要素を生成しない未知の拡張子が存在するかどうかを判断できません。
The non-determinism can be resolved with either a SINGULAR-INSERTIONS, UNIFORM-INSERTIONS, or MULTIFORM-INSERTIONS encoding instruction. The MULTIFORM-INSERTIONS encoding instruction is the least restrictive. Consider this revised type definition:
非決定的主義は、特異な挿入、均一な挿入、または命令をエンコードするマルチフィルム挿入のいずれかで解決できます。命令をエンコードするマルチフォームインサートは、最も制限が少ないです。この改訂されたタイプ定義を考えてみましょう。
SEQUENCE {
one [GROUP] [MULTIFORM-INSERTIONS] CHOICE {
two UTF8String,
... -- Extension insertion point (I1).
} OPTIONAL
}
The associated grammar is:
関連する文法は次のとおりです。
P1: S ::= one
P2: one ::= two
P8: one ::= "*" I1
P4: one ::=
P5: two ::= "two"
P6: I1 ::= "*" I1
P7: I1 ::=
This grammar leads to the following sets and predicates:
この文法は、次のセットと述語につながります。
First(P2) = { "two" }
First(P8) = { "*" }
First(P4) = { }
Preselected(P2) = Preselected(P8) = Preselected(P4) = false
Empty(P2) = Empty(P8) = false
Empty(P4) = true
Follow(one) = { "$" }
Select(P2) = First(P2) = { "two" }
Select(P8) = First(P8) = { "*" }
Select(P4) = First(P4) + Follow(one) = { "$" }
First(P6) = { "*" }
First(P7) = { }
Preselected(P6) = Preselected(P7) = Empty(P6) = false
Empty(P7) = true
Follow(I1) = { "$" }
Select(P6) = First(P6) = { "*" }
Select(P7) = First(P7) + Follow(I1) = { "$" }
The intersection of Select(P2) and Select(P8) is empty, as is the intersection of Select(P2) and Select(P4), the intersection of Select(P8) and Select(P4), and the intersection of Select(P6) and Select(P7); hence, the grammar is deterministic, and the type definition is valid. A decoder will now assume the "one" alternative is present if it sees at least one unrecognized element, and absent otherwise.
select（p8）のselect（p8）の交差点は空であり、select（p2）とselect（p4）、select（p8）とselect（p4）の交差点、およびselect（p6の交差点）と同様に、）and select（p7）;したがって、文法は決定論的であり、タイプ定義は有効です。デコーダーは、少なくとも1つの認識されていない要素を見た場合、それ以外の場合は「1つの」選択肢が存在すると仮定します。
Consider the following type definition:
次のタイプ定義を検討してください。
SEQUENCE {
one [GROUP] CHOICE {
two UTF8String,
... -- Extension insertion point (I1).
},
three [GROUP] CHOICE {
four UTF8String,
... -- Extension insertion point (I2).
}
}
The associated grammar is:
関連する文法は次のとおりです。
P1: S ::= one three
P2: one ::= two
P3: one ::= I1
P4: two ::= "two"
P5: I1 ::= "*" I1
P6: I1 ::=
P7: three ::= four
P8: three ::= I2
P9: four ::= "four"
P10: I2 ::= "*" I2
P11: I2 ::=
This grammar leads to the following sets and predicates:
この文法は、次のセットと述語につながります。
First(P2) = { "two" }
First(P3) = { "*" }
Preselected(P2) = Preselected(P3) = Empty(P2) = false
Empty(P3) = true
Follow(one) = { "four", "*", "$" }
Select(P2) = First(P2) = { "two" }
Select(P3) = First(P3) + Follow(one) = { "*", "four", "$" }
First(P5) = { "*" }
First(P6) = { }
Preselected(P5) = Preselected(P6) = Empty(P5) = false
Empty(P6) = true
Follow(I1) = { "four", "*", "$" }
Select(P5) = First(P5) = { "*" }
Select(P6) = First(P6) + Follow(I1) = { "four", "*", "$" }
First(P7) = { "four" }
First(P8) = { "*" }
Preselected(P7) = Preselected(P8) = Empty(P7) = false
Empty(P8) = true
Follow(three) = { "$" }
Select(P7) = First(P7) = { "four" }
Select(P8) = First(P8) + Follow(three) = { "*", "$" }
First(P10) = { "*" }
First(P11) = { }
Preselected(P10) = Preselected(P11) = Empty(P10) = false
Empty(P11) = true
Follow(I2) = { "$" }
Select(P10) = First(P10) = { "*" }
Select(P11) = First(P11) + Follow(I2) = { "$" }
The intersection of Select(P5) and Select(P6) is not empty; hence, the grammar is not deterministic, and the type definition is not valid. If the first child element is an unrecognized element, then a decoder cannot determine whether to associate it with extension insertion point I1, or to associate it with extension insertion point I2 by assuming that the "one" component has an unknown extension that generates no elements.
select（p5）とselect（p6）の交点は空ではありません。したがって、文法は決定論的ではなく、タイプ定義は有効ではありません。最初の子要素が認識されていない要素である場合、デコーダーは、「1つの」コンポーネントには要素が生成されない未知の拡張機能があると仮定することにより、延長挿入ポイントi1に関連付けるか、延長挿入ポイントi2に関連付けるかどうかを決定できません。。
The non-determinism can be resolved with either a SINGULAR-INSERTIONS or UNIFORM-INSERTIONS encoding instruction. Consider this revised type definition using the SINGULAR-INSERTIONS encoding instruction:
非決定的主義は、特異な挿入または均一な象徴をエンコードする指示のいずれかで解決できます。命令をエンコードする特異な挿入を使用して、この改訂されたタイプ定義を検討してください。
SEQUENCE {
one [GROUP] [SINGULAR-INSERTIONS] CHOICE {
two UTF8String,
... -- Extension insertion point (I1).
},
three [GROUP] CHOICE {
four UTF8String,
... -- Extension insertion point (I2).
}
}
The associated grammar is:
関連する文法は次のとおりです。
P1: S ::= one three
P2: one ::= two
P12: one ::= "*"
P4: two ::= "two"
P7: three ::= four
P8: three ::= I2
P9: four ::= "four"
P10: I2 ::= "*" I2
P11: I2 ::=
With the addition of the SINGULAR-INSERTIONS encoding instruction, the P5 and P6 productions are no longer generated. The grammar leads to the following sets and predicates for the P2 and P12 productions:
命令をエンコードする特異な挿合物が追加されているため、P5およびP6プロダクションは生成されなくなりました。文法は、P2およびP12プロダクションの次のセットと述語につながります。
First(P2) = { "two" }
First(P12) = { "*" }
Preselected(P2) = Preselected(P12) = false
Empty(P2) = Empty(P12) = false
Follow(one) = { "four", "*", "$" }
Select(P2) = First(P2) = { "two" }
Select(P12) = First(P12) = { "*" }
The sets for P5 and P6 are no longer generated, and the remaining sets are unchanged.
P5とP6のセットは生成されなくなり、残りのセットは変更されていません。
The intersection of Select(P2) and Select(P12) is empty, as is the intersection of Select(P7) and Select(P8) and the intersection of Select(P10) and Select(P11); hence, the grammar is deterministic, and the type definition is valid. If the first child element is an unrecognized element, then a decoder will now assume that it is associated with extension insertion point I1. Whatever follows, possibly including another unrecognized element, will belong to the "three" component.
select（p12）の交差点は空であり、select（p7）とselect（p8）とselect（p10）とselect（p11）の交差点と同様に。したがって、文法は決定論的であり、タイプ定義は有効です。最初の子要素が認識されていない要素である場合、デコーダーは拡張挿入点I1に関連付けられていると仮定します。おそらく別の認識されていない要素を含めると、「3つの」コンポーネントに属するものが続くものがあります。
Now consider the type definition using the UNIFORM-INSERTIONS encoding instruction instead:
次に、代わりに命令をエンコードする均一な挿入を使用してタイプ定義を検討してください。
SEQUENCE {
one [GROUP] [UNIFORM-INSERTIONS] CHOICE {
two UTF8String,
... -- Extension insertion point (I1).
},
three [GROUP] CHOICE {
four UTF8String,
... -- Extension insertion point (I2).
}
}
The associated grammar is:
関連する文法は次のとおりです。
P1: S ::= one three
P2: one ::= two
P13: one ::= "*"
P14: one ::= "*1" I1
P4: two ::= "two"
P15: I1 ::= "*1" I1
P6: I1 ::=
P7: three ::= four
P8: three ::= I2
P9: four ::= "four"
P10: I2 ::= "*" I2
P11: I2 ::=
This grammar leads to the following sets and predicates for the P2, P13, P14, P15, and P6 productions:
この文法は、P2、P13、P14、P15、およびP6プロダクションの次のセットと述語につながります。
First(P2) = { "two" }
First(P13) = { "*" }
First(P14) = { "*1" }
Preselected(P2) = Preselected(P13) = Preselected(P14) = false
Empty(P2) = Empty(P13) = Empty(P14) = false
Follow(one) = { "four", "*", "$" }
Select(P2) = First(P2) = { "two" }
Select(P13) = First(P13) = { "*" }
Select(P14) = First(P14) = { "*1" }
First(P15) = { "*1" }
First(P6) = { }
Preselected(P15) = Preselected(P6) = Empty(P15) = false
Empty(P6) = true
Follow(I1) = { "four", "*", "$" }
Select(P15) = First(P15) = { "*1" }
Select(P6) = First(P6) + Follow(I1) = { "four", "*", "$" }
The remaining sets are unchanged.
残りのセットは変更されていません。
The intersection of Select(P2) and Select(P13) is empty, as is the intersection of Select(P2) and Select(P14), the intersection of Select(P13) and Select(P14) and the intersection of Select(P15) and Select(P6); hence, the grammar is deterministic, and the type definition is valid. If the first child element is an unrecognized element, then a decoder will now assume that it and every subsequent unrecognized element with the same name are associated with I1. Whatever follows, possibly including another unrecognized element with a different name, will belong to the "three" component.
select（p13）のselect（p13）の交差点は空であり、select（p2）とselect（p14）、select（p13）とselect（p14）の交差点（p14）、およびselect（p15）の交差点もそうです（p15）およびselect（p6）;したがって、文法は決定論的であり、タイプ定義は有効です。最初の子要素が認識されていない要素である場合、デコーダーは、それと同じ名前のその後のすべての認識されていない要素がi1に関連付けられていると仮定します。次のものは何でも、おそらく別の名前を持つ別の認識されていない要素を含めることは、「3つの」コンポーネントに属します。
A consequence of using the UNIFORM-INSERTIONS encoding instruction is that any future extension to the "three" component will be required to generate elements with names that are different from the names of the elements generated by the "one" component. With the SINGULAR-INSERTIONS encoding instruction, extensions to the "three" component are permitted to generate elements with names that are the same as the names of the elements generated by the "one" component.
均一な挿入命令を使用した結果、「1つの」コンポーネントによって生成された要素の名前とは異なる名前の要素を生成するには、「3つの」コンポーネントの将来の拡張が必要になることです。命令をエンコードする特異な挿入により、「3つの」コンポーネントへの拡張は、「1つの」コンポーネントによって生成された要素の名前と同じ名前の要素を生成することができます。
Consider the following type definition:
次のタイプ定義を検討してください。
SEQUENCE OF one [GROUP] CHOICE {
two UTF8String,
... -- Extension insertion point (I1).
}
The associated grammar is:
関連する文法は次のとおりです。
P1: S ::= one S
P2: S ::=
P3: one ::= two
P4: one ::= I1
P5: two ::= "two"
P6: I1 ::= "*" I1
P7: I1 ::=
This grammar leads to the following sets and predicates:
この文法は、次のセットと述語につながります。
First(P1) = { "two", "*" }
First(P2) = { }
Preselected(P1) = Preselected(P2) = false
Empty(P1) = Empty(P2) = true
Follow(S) = { "$" }
Select(P1) = First(P1) + Follow(S) = { "two", "*", "$" }
Select(P2) = First(P2) + Follow(S) = { "$" }
First(P3) = { "two" }
First(P4) = { "*" }
Preselected(P3) = Preselected(P4) = Empty(P3) = false
Empty(P4) = true
Follow(one) = { "two", "*", "$" }
Select(P3) = First(P3) = { "two" }
Select(P4) = First(P4) + Follow(one) = { "*", "two", "$" }
First(P6) = { "*" }
First(P7) = { }
Preselected(P6) = Preselected(P7) = Empty(P6) = false
Empty(P7) = true
Follow(I1) = { "two", "*", "$" }
Select(P6) = First(P6) = { "*" }
Select(P7) = First(P7) + Follow(I1) = { "two", "*", "$" }
The intersection of Select(P1) and Select(P2) is not empty, as is the intersection of Select(P3) and Select(P4) and the intersection of Select(P6) and Select(P7); hence, the grammar is not deterministic, and the type definition is not valid. If a decoder encounters two or more unrecognized elements in a row, then it cannot determine whether this represents one instance or more than one instance of the "one" component. Even without unrecognized elements, there is still a problem that an encoding could contain an indeterminate number of "one" components using an extension that generates no elements.
select（p2）とselect（p2）の交差点は空ではなく、select（p3）とselect（p4）とselect（p6）とselect（p7）の交差点の交差と同様です。したがって、文法は決定論的ではなく、タイプ定義は有効ではありません。デコーダーが2つ以上の認識されていない要素を連続して遭遇する場合、これが「1つの」コンポーネントの1つのインスタンスまたは複数のインスタンスを表すかどうかを判断することはできません。認識されていない要素がなくても、エンコードには、要素を生成しない拡張機能を使用して、「1つの」コンポーネントの不確定な数を含める可能性があるという問題がまだあります。
The non-determinism cannot be resolved with a UNIFORM-INSERTIONS encoding instruction. Consider this revised type definition using the UNIFORM-INSERTIONS encoding instruction:
非決定論は、指示をエンコードする均一な挿入で解決することはできません。均一な挿入命令を使用して、この改訂されたタイプ定義を検討してください。
SEQUENCE OF one [GROUP] [UNIFORM-INSERTIONS] CHOICE {
two UTF8String,
... -- Extension insertion point (I1).
}
The associated grammar is:
関連する文法は次のとおりです。
P1: S ::= one S
P2: S ::=
P3: one ::= two
P8: one ::= "*"
P9: one ::= "*1" I1
P5: two ::= "two"
P10: I1 ::= "*1" I1
P7: I1 ::=
This grammar leads to the following sets and predicates:
この文法は、次のセットと述語につながります。
First(P1) = { "two", "*", "*1" }
First(P2) = { }
Preselected(P1) = Preselected(P2) = Empty(P1) = false
Empty(P2) = true
Follow(S) = { "$" }
Select(P1) = First(P1) = { "two", "*", "*1" }
Select(P2) = First(P2) + Follow(S) = { "$" }
First(P3) = { "two" }
First(P8) = { "*" }
First(P9) = { "*1" }
Preselected(P3) = Preselected(P8) = Preselected(P9) = false
Empty(P3) = Empty(P8) = Empty(P9) = false
Follow(one) = { "two", "*", "*1", "$" }
Select(P3) = First(P3) = { "two" }
Select(P8) = First(P8) = { "*" }
Select(P9) = First(P9) = { "*1" }
First(P10) = { "*1" }
First(P7) = { }
Preselected(P10) = Preselected(P7) = Empty(P10) = false
Empty(P7) = true
Follow(I1) = { "two", "*", "*1", "$" }
Select(P10) = First(P10) = { "*1" }
Select(P7) = First(P7) + Follow(I1) = { "two", "*", "*1", "$" }
The intersection of Select(P1) and Select(P2) is now empty, but the intersection of Select(P10) and Select(P7) is not; hence, the grammar is not deterministic, and the type definition is not valid. The problem of an indeterminate number of "one" components from an extension that generates no elements has been solved. However, if a decoder encounters a series of elements with the same name, it cannot determine whether this represents one instance or more than one instance of the "one" component.
select（p1）とselect（p2）の交差点は空になりますが、select（p10）とselect（p7）の交差点はそうではありません。したがって、文法は決定論的ではなく、タイプ定義は有効ではありません。要素が生成されない拡張機能からの「1つの」コンポーネントの不定の数の問題は解決されていません。ただし、デコーダーが同じ名前の一連の要素に遭遇する場合、これが「1つの」コンポーネントの1つのインスタンスを表すか、複数のインスタンスを表すかを決定することはできません。
The non-determinism can be fully resolved with a SINGULAR-INSERTIONS encoding instruction. Consider this revised type definition:
非決定論は、指示をエンコードする特異な挿入で完全に解決できます。この改訂されたタイプ定義を考えてみましょう。
SEQUENCE OF one [GROUP] [SINGULAR-INSERTIONS] CHOICE {
two UTF8String,
... -- Extension insertion point (I1).
}
The associated grammar is:
関連する文法は次のとおりです。
P1: S ::= one S
P2: S ::=
P3: one ::= two
P8: one ::= "*"
P5: two ::= "two"
This grammar leads to the following sets and predicates:
この文法は、次のセットと述語につながります。
First(P1) = { "two", "*" }
First(P2) = { }
Preselected(P1) = Preselected(P2) = Empty(P1) = false
Empty(P2) = true
Follow(S) = { "$" }
Select(P1) = First(P1) = { "two", "*" }
Select(P2) = First(P2) + Follow(S) = { "$" }
First(P3) = { "two" }
First(P8) = { "*" }
Preselected(P3) = Preselected(P8) = false
Empty(P3) = Empty(P8) = false
Follow(one) = { "two", "*", "$" }
Select(P3) = First(P3) = { "two" }
Select(P8) = First(P8) = { "*" }
The intersection of Select(P1) and Select(P2) is empty, as is the intersection of Select(P3) and Select(P8); hence, the grammar is deterministic, and the type definition is valid. A decoder now knows that every extension to the "one" component will generate a single element, so the correct number of "one" components will be decoded.
select（p1）とselect（p2）の交差点は空であり、select（p3）とselect（p8）の交点も同様です。したがって、文法は決定論的であり、タイプ定義は有効です。デコーダーは、「1つの」コンポーネントへのすべての拡張機能が単一の要素を生成することを知っているため、正しい数の「1つの」コンポーネントがデコードされます。
This appendix is non-normative.
この付録は非規範的です。
The first example shows extensions that satisfy the HOLLOW-INSERTIONS encoding instruction.
最初の例は、命令をエンコードする中空の挿入を満たす拡張機能を示しています。
[HOLLOW-INSERTIONS] CHOICE {
one BOOLEAN,
...,
two [ATTRIBUTE] INTEGER,
three [GROUP] SEQUENCE {
four [ATTRIBUTE] UTF8String,
five [ATTRIBUTE] INTEGER OPTIONAL,
...
},
six [GROUP] CHOICE {
seven [ATTRIBUTE] BOOLEAN,
eight [ATTRIBUTE] INTEGER
}
}
The "two" and "six" components generate only attributes.
「2」および「6」コンポーネントは、属性のみを生成します。
The "three" component in its current form does not generate elements. Any extension to the "three" component will need to do likewise to avoid breaking forward compatibility.
現在の形式の「3つの」コンポーネントは、要素を生成しません。「3つの」コンポーネントへの拡張機能も同様に行う必要があります。
The second example shows extensions that satisfy the SINGULAR-INSERTIONS encoding instruction.
2番目の例は、命令をエンコードする特異な属性を満たす拡張機能を示しています。
[SINGULAR-INSERTIONS] CHOICE {
one BOOLEAN,
...,
two INTEGER,
three [GROUP] SEQUENCE {
four [ATTRIBUTE] UTF8String,
five INTEGER
},
six [GROUP] CHOICE {
seven BOOLEAN,
eight INTEGER
}
}
The "two" component will always generate a single <two> element.
「2つの」コンポーネントは、常に単一の<2>要素を生成します。
The "three" component will always generate a single <five> element. It will also generate a "four" attribute, but any number of attributes is allowed by the SINGULAR-INSERTIONS encoding instruction.
「3」コンポーネントは、常に単一の<5>要素を生成します。また、「4」の属性も生成されますが、任意の数の属性は、instencoding命令をエンコードすることで許可されています。
The "six" component will either generate a single <seven> element or a single <eight> element. Either case will satisfy the requirement that there will be a single element in any given encoding of the extension.
「6」コンポーネントは、単一の<7>要素または単一の<8>要素を生成します。どちらのケースも、拡張の特定のエンコードに単一の要素があるという要件を満たします。
The third example shows extensions that satisfy the UNIFORM-INSERTIONS encoding instruction.
3番目の例は、均一な属性エンコード命令を満たす拡張機能を示しています。
[UNIFORM-INSERTIONS] CHOICE {
one BOOLEAN,
...,
two INTEGER,
three [GROUP] SEQUENCE SIZE(1..MAX) OF four INTEGER,
five [GROUP] SEQUENCE {
six [ATTRIBUTE] UTF8String OPTIONAL,
seven INTEGER
},
eight [GROUP] CHOICE {
nine BOOLEAN,
ten [GROUP] SEQUENCE SIZE(1..MAX) OF eleven INTEGER
}
}
The "two" component will always generate a single <two> element.
「2つの」コンポーネントは、常に単一の<2>要素を生成します。
The "three" component will always generate one or more <four> elements.
「3つの」コンポーネントは、常に1つ以上の<4>要素を生成します。
The "five" component will always generate a single <seven> element. It may also generate a "six" attribute, but any number of attributes is allowed by the UNIFORM-INSERTIONS encoding instruction.
「5」コンポーネントは、常に単一の<7>要素を生成します。また、「6」属性を生成する場合がありますが、均一な属性エンコード命令によって任意の数の属性が許可されます。
The "eight" component will either generate a single <nine> element or one or more <eleven> elements. Either case will satisfy the requirement that there must be one or more elements with the same name in any given encoding of the extension.
「8」コンポーネントは、単一の<ナイン>要素または1つ以上の<eleven>要素を生成します。どちらのケースも、拡張機能の特定のエンコードに同じ名前の1つ以上の要素が必要であるという要件を満たします。
Making extensions that are not forward compatible is permitted provided that the incompatibility is signalled with a version indicator attribute.
互換性がバージョンインジケーター属性で通知されている場合、順方向に互換性のない拡張機能を作成することは許可されます。
Suppose that version 1.0 of a specification contains the following type definition:
仕様のバージョン1.0に次のタイプ定義が含まれているとします。
MyMessageType ::= SEQUENCE {
version [ATTRIBUTE] [VERSION-INDICATOR]
UTF8String ("1.0", ...) DEFAULT "1.0",
one [GROUP] [SINGULAR-INSERTIONS] CHOICE {
two BOOLEAN,
...
},
...
}
An attribute is to be added to the CHOICE for version 1.1. This change is not forward compatible since it does not satisfy the SINGULAR-INSERTIONS encoding instruction. Therefore, the version indicator attribute must be updated at the same time (or added if it wasn't already present). This results in the following new type definition for version 1.1:
属性は、バージョン1.1の選択に追加されます。この変更は、命令をエンコードする特異な属性を満たしていないため、前方に互換性がありません。したがって、バージョンインジケーター属性は同時に更新する必要があります（または、まだ存在していない場合は追加されます）。これにより、バージョン1.1の次の新しいタイプ定義が得られます。
MyMessageType ::= SEQUENCE {
version [ATTRIBUTE] [VERSION-INDICATOR]
UTF8String ("1.0", ..., "1.1") DEFAULT "1.0",
one [GROUP] [SINGULAR-INSERTIONS] CHOICE {
two BOOLEAN,
...,
three [ATTRIBUTE] INTEGER -- Added in Version 1.1
},
...
}
If a version 1.1 conformant application hasn't used the version 1.1 extension in a value of MyMessageType, then it is allowed to set the value of the version attribute to "1.0".
バージョン1.1コンフォーマントアプリケーションがMyMessageTypeの値でバージョン1.1拡張機能を使用していない場合、バージョン属性の値を「1.0」に設定できます。
A pair of elements is added to the CHOICE for version 1.2. Again the change does not satisfy the SINGULAR-INSERTIONS encoding instruction. The type definition for version 1.2 is:
バージョン1.2の選択には、一対の要素が追加されます。繰り返しますが、この変更は、指示をエンコードする特異な象徴を満たしていません。バージョン1.2のタイプ定義は次のとおりです。
MyMessageType ::= SEQUENCE {
version [ATTRIBUTE] [VERSION-INDICATOR]
UTF8String ("1.0", ..., "1.1" | "1.2")
DEFAULT "1.0",
one [GROUP] [SINGULAR-INSERTIONS] CHOICE {
two BOOLEAN,
...,
three [ATTRIBUTE] INTEGER, -- Added in Version 1.1
four [GROUP] SEQUENCE {
five UTF8String,
six GeneralizedTime
} -- Added in version 1.2
},
...
}
If a version 1.2 conformant application hasn't used the version 1.2 extension in a value of MyMessageType, then it is allowed to set the value of the version attribute to "1.1". If it hasn't used either of the extensions, then it is allowed to set the value of the version attribute to "1.0".
バージョン1.2のコンフォーマントアプリケーションがMyMessagetypeの値でバージョン1.2拡張子を使用していない場合、バージョン属性の値を「1.1」に設定できます。どちらの拡張機能も使用していない場合は、バージョン属性の値を「1.0」に設定することができます。
Author's Address
著者の連絡先
Dr. Steven Legg eB2Bcom Suite 3, Woodhouse Corporate Centre 935 Station Street Box Hill North, Victoria 3129 AUSTRALIA
スティーブンレッグEB2BCOMスイート3、ウッドハウスコーポレートセンター935ステーションボックスヒルノース、ビクトリア3129オーストラリア
Phone: +61 3 9896 7830
Fax: +61 3 9896 7801
EMail: steven.legg@eb2bcom.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。