Network Working Group S. Legg
Request for Comments: 4911 eB2Bcom
Category: Experimental July 2007
Encoding Instructions for the
Robust XML Encoding Rules (RXER)
Status of This Memo
このメモのステータス
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（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.
この文書では、ASN.1値がために、堅牢なXMLエンコーディング規則（RXER）と正規ロバストXMLエンコーディング規則（CRXER）によってコードされている方法を変更する抽象構文記法1（ASN.1）仕様で使用することができる符号化命令を定義します拡張マークアップ言語（XML）属性ではなく、子要素としてとしてASN.1値の成分を符号化する例。これらの符号化手順の一部は、ASN.1仕様は抽象構文記法X（ASN.X）仕様に変換される方法に影響します。 ASN.1仕様が他のXMLスキーマ言語の定義を参照することを可能にする符号化命令も定義されています。
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].
この文書では、ASN.1値はロバストXMLエンコーディング規則によってコードされている方法を変更する抽象構文記法1（ASN.1）[X.680]明細書で使用され得る符号化命令[X.680-1（RXERを定義します）[RXER]と正規ロバストXMLエンコーディング規則（CRXER）RXER]、例えば、拡張マークアップ言語（XML）[XML10]の属性としてではなく、子要素としてASN.1値の成分を符号化します。これらの符号化手順の一部はまた、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.
この文書はまた、他のXMLスキーマ言語で書かれた仕様でエンコードASN.1仕様は、タイプ、要素の定義を組み込むことが可能命令、および属性を定義します。 XMLスキーマ[XSD1]種類、要素および属性への参照は、NG [RNG]指定パターンと要素、およびXML文書型定義（DTD）[XML10]の要素タイプがサポートされているがRELAX。
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.
キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "SHALL"、 "SHOULD" "ないもの"、 "推奨" "NOTべきだ" と、この文書で説明するように解釈されるべきであり、 "MAY" BCP 14、RFC 2119 [BCP14]。キーワード「OPTIONAL」は、もっぱらその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]（例えば、タイプ、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及び[X.680-1「RXER命令」のEncodingReferenceDefaultと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基本的な表記法のEncodingInstructionとEncodingInstructionAssignmentListプレースホルダ生産を詳述します。
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符号化基準の文脈において、EncodingInstruction生産は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.
定義（最上位NamedType）：NamedTypeがあれば最上位NamedType（等価的に、最上位レベルのコンポーネント）であり、それはTopLevelComponentにNamedType場合のみ。 TopLevelComponentのNamedTypeのタイプ内にネスト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内で定義された非自明なタイプはRXERを理解していないASN.1ツールに表示されないことに注意してください。
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符号化制御部に表示されているが、トップレベルのNamedTypeを解析するときに、モジュール[X.680-1]のデフォルトの符号化基準が適用されます。
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:
NamedType生産は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における値の支配型が[RXER] AdditionalBasicDefinitionsモジュールからNCNameで型です。
The governing type for the Value in an AnyURIValue is the AnyURI type from the AdditionalBasicDefinitions module.
AnyURIValueにおける値の支配型がAdditionalBasicDefinitionsモジュールからanyURIのタイプです。
The governing type for the Value in a QNameValue is the QName type from the AdditionalBasicDefinitions module.
QNameValueでの価値のための統治タイプはAdditionalBasicDefinitionsモジュールからのQNameタイプです。
The governing type for the Value in a NameValue is the Name type from the AdditionalBasicDefinitions module.
NameValueでの価値のための統治タイプはAdditionalBasicDefinitionsモジュールから名前型です。
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の値は[X.683] DummyReferenceてはならないとネストされたテキストで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,
RXER符号化命令の特定の成分の符号化命令として分類されます。成分符号化命令、属性、属性REF、COMPONENT-REF、GROUP、ELEMENT-REF、NAME、REF-AS-ELEMENT、SIMPLE-CONTENT、TYPE-AS-VERSION、およびその表記しているバージョンインジケータ符号化命令（ありますAttributeInstruction、AttributeRefInstruction、ComponentRefInstruction、GroupInstruction、によってそれぞれ説明
ElementRefInstruction, NameInstruction, RefAsElementInstruction, SimpleContentInstruction, TypeAsVersionInstruction, and VersionIndicatorInstruction).
ElementRefInstruction、NameInstruction、RefAsElementInstruction、SimpleContentInstruction、TypeAsVersionInstruction、およびVersionIndicatorInstruction）。
The Type in the EncodingPrefixedType for a component encoding instruction SHALL be either:
成分符号化命令のEncodingPrefixedTypeにおけるタイプのいずれかでなければなりません。
(1) the Type in a NamedType, or
（1）NamedTypeを入力し、又は
(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）のいずれかのタイプでBuiltinTypeでPrefixedTypeでEncodingPrefixedTypeでタイプ、または
(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）のいずれかのタイプでBuiltinTypeでPrefixedTypeでTaggedTypeでタイプ、または
(4) the Type in a ConstrainedType (excluding a TypeWithConstraint) in a Type that is one of (1) to (4).
（4）上記（1）〜（4）のいずれかのタイプで（TypeWithConstraint除く）ConstrainedTypeにおけるタイプ。
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.
余談：この条件の効果は、それらが適用されるNamedType内のテキストであること成分符号化命令を強制することです。唯一のケースは、（2）タイプEncodingPrefixedTypeに属しているように、第1の反復で真であることができます。しかし、（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.
（4）場合は、符号化命令がATTRIBUTE-REF、COMPONENT-REF、ELEMENT-REF、またはREF-AS-ELEMENT符号化命令である場合に許可されていません。
The NamedType in case (1) is said to be "subject to" the component encoding instruction.
（1）場合NamedTypeは成分符号化命令「対象」であると言われます。
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はATTRIBUTE-REF、COMPONENT-REF、GROUP、ELEMENT-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.
NamedTypeは、同じ種類の2つの以上の成分符号化指示の対象とされるべきではない、例えば、NamedTypeは、2つの名前の符号化手順を受けることを許可されていません。
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.
ATTRIBUTE、ATTRIBUTE-REF、COMPONENT-REF、GROUP、ELEMENT-REF、REF-AS-ELEMENT、SIMPLE-CONTENT、およびTYPE-AS-VERSION符号化命令は相互に排他的です。 NAME属性-REF、COMPONENT-REF、ELEMENT-REF、及びREF-AS-要素符号化命令は、相互に排他的です。 NamedTypeは相互に排他的である二つ以上の符号化指示の対象とされるべきではありません。
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] ATTRIBUTE-REF、COMPONENT-REF、ELEMENT-REF又はREF-AS-要素符号化指示の対象となる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.
定義（属性成分）：属性コンポーネントは、属性コード命令の対象となる最上位NamedTypeを参照部品REF符号化命令に属性または属性REF符号化命令、又は被験体であるNamedTypeあります。
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.
定義（元素成分）：元素成分がトップレベルNamedTypeを参照部品REF符号化命令を受け、ATTRIBUTE-REF、GROUP、または単純コンテンツエンコード命令ATTRIBUTEを受けないNamedTypeではなく、その属性の符号化命令を受けます。
Aside: A NamedType subject to a GROUP or SIMPLE-CONTENT encoding instruction is neither an attribute component nor an element component.
脇：グループにNamedType対象または単純コンテンツエンコード命令は、属性コンポーネントNOR素子部品でもありません。
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符号化命令の特定は、基準符号化命令として分類されます。基準符号化命令は、ATTRIBUTE-REF、COMPONENT-REF、ELEMENT-REF、REF-AS-ELEMENT、REF-AS-TYPEと表記AttributeRefInstruction、ComponentRefInstructionによってそれぞれ記載されているTYPE-REF符号化命令（ElementRefInstruction、RefAsElementInstructionあります、RefAsTypeInstruction、およびTypeRefInstruction）。 （COMPONENT-REFを除く）これらの符号化命令はASN.1仕様がタイプ、要素の定義を組み込むことができるように、そして、マークアップASNの値に現れるマークアップに暗黙の制約を介して他のXMLスキーマ言語で書かれた仕様の属性AdditionalBasicDefinitionsモジュール[RXER（ELEMENT-REFは、REF-AS-ELEMENT、REF-AS-TYPE、及びTYPE-REF）又は（ATTRIBUTE-REF用）UTF8Stringを型から0.1型。 XMLスキーマ[XSD1]種類、要素および属性への参照は、NG [RNG]指定パターンと要素、およびXML文書型定義（DTD）[XML10]の要素タイプがサポートされているがRELAX。 ASN.1タイプとトップレベルのコンポーネントへの参照も許可されています。 COMPONENT-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
ELEMENT-REF用EncodingPrefixedTypeを入力し、REF-AS-ELEMENT、REF-AS-TYPE、またはTYPE-REF符号化命令のいずれかでなければならない：typereference（ないDummyReferenceあるDefinedTypeである（1）ReferencedType ）または[RXER] AdditionalBasicDefinitionsモジュールからのマークアップASN.1タイプを参照し、またはExternalTypeReference
(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中タイプの一つであるTaggedTypeがPrefixedTypeであるBuiltinType（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）のいずれかEncodingPrefixedType基準符号化命令が含まれていないEncodingPrefixedTypeでEncodingPrefixあるPrefixedTypeあるBuiltinType。
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.
脇：ATTRIBUTE-REFおよびコンポーネントREF符号化命令のケース（3）と同様のケースが相互に排他的な参照符号指示を行うだけでなく、単独で発生する効果を有します。
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符号化命令に対して、場合DefinedTypeは、（1）符号化命令「対象」であると言われます。
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.
ATTRIBUTE-REFエンコーディング命令のEncodingPrefixedTypeを入力上の制限がCOMPONENT-REFエンコーディング命令のEncodingPrefixedTypeを入力上の制限は、セクション10で指定されている第9節で指定されています。
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インスタンスが定義への参照に関する追加情報を提供します。基準が曖昧である場合ContextParameterが使用され、すなわち、複数のスキーマ文書または外部DTDサブセットの定義を指します。ターゲット名前空間[XSD1]なしで定義された独立して開発されたXMLスキーマから同じ名前を持つ型をインポートするときにこのような状況は、例えば、発生するであろう。外部DTDサブセット内の要素の型への参照と併せて使用される場合、ContextParameterでAnyURIValue外部DTDサブセットのシステム識別子（ユニフォームリソース識別子又はURI [URI]）です。そうでない場合、AnyURIValueは、意図スキーマ文書を示すURIは、いずれかのXMLスキーマ仕様、RELAX NG仕様、またはASN.1またはASN.X仕様です。
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,
NamedTypeがNAME符号化命令の対象である場合（1）、次いで、拡張名のローカル名は、NAME符号化命令の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）他NamedTypeコンポーネント-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-要素符号化命令の対象である場合、拡張名のローカル名は、LocalPartは[XMLNS10】符号化命令のNameValueによって指定された修飾された名前のあります
(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によって指定された文字列である場合TARGET名前空間符号化命令。それ以外の場合は、名前空間名には値がありません。
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）において、次に展開名の名前空間名は、名前空間のAnyURIValueによって指定された文字列です。それ以外の場合は、名前空間名には値がありません。
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].
CHOICE、SEQUENCE、またはSET型の属性コンポーネントの拡張名は別個でなければなりません。部品属性されていないCHOICE、SEQUENCE、またはセットタイプのコンポーネントの拡張名は別個でなければなりません。これらの試験は、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.
脇：そのうちの一つが、属性コンポーネントである場合、同じCHOICE、SEQUENCE、またはSET型の2つのコンポーネントは、同じ拡張名を有していてもよく、他ではありません。 「ない」場合は、基または単純コンテンツエンコード命令の対象である構成要素を含むことに留意されたいです。
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対象の拡張名に属性符号化命令が同じモジュールに命令をコード属性に他のすべてのトップレベル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.
ATTRIBUTE符号化命令を受けない最上位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.
脇：そのうちの一つが、属性コンポーネントである場合、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.
命令を符号化する属性は、それがXML属性として代わりの子要素として適用される成分の値を符号化するためにRXERエンコーダを引き起こします。
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:
ATTRIBUTE符号化指示の対象となるNamedTypeの種類の基本型があってはなりません。
(1) a CHOICE, SET, or SET OF type, or
（1）CHOICE、SET、またはタイプのセット、又は
(2) a SEQUENCE type other than the one defining the QName type from the AdditionalBasicDefinitions module [RXER] (i.e., QName is allowed), or
（2）[RXER（すなわち、QNameのが許可されている）AdditionalBasicDefinitionsモジュールからのQNameタイプを定義以外のSEQUENCEタイプ、または
(3) a SEQUENCE OF type where the SequenceOfType is not subject to a LIST encoding instruction, or
（3）SequenceOfTypeリスト符号化命令を受けないタイプのシーケンス、又は
(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.
ATTRIBUTE-REF符号化命令は、XML属性として代わりの属性の名前は、符号化命令によって参照される属性宣言の修飾名であり、子要素として、それが適用される成分の値を符号化するためにRXERエンコーダを引き起こします。また、属性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スキーマ属性の宣言または属性コード命令の対象となる最上位NamedTypeを参照しなければなりません。
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型、表記ENTITY、ENTITIES、又は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.
脇：これらの型の値は、解釈のための属性の文脈からの情報を必要としています。 ATTRIBUTE-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のタイプは、[RXER]、直接またはサブタイピングによって、AdditionalBasicDefinitionsモジュールからのQNameの形であってはなりません。
The Type in the EncodingPrefixedType for an ATTRIBUTE-REF encoding instruction SHALL be either:
ATTRIBUTE-REF符号化命令のEncodingPrefixedTypeにおけるタイプのいずれかでなければなりません。
(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を型、またはTaggedTypeにおけるタイプ（1）〜（3）のいずれかであるTaggedType PrefixedType（2）BuiltinTypeを、または
(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）のいずれかEncodingPrefixedType基準符号化命令が含まれていないEncodingPrefixedTypeでEncodingPrefixあるPrefixedTypeあるBuiltinType。
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.
ATTRIBUTE-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を参照する機構を有していません。 COMPONENT-REF符号化命令は、結合型定義内NamedTypeが参照最上位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はInternalComponentReferenceから存在しない場合、識別子は、同じモジュール内の最上位NamedTypeの識別子でなければなりません。 GlobalModuleReferenceはInternalComponentReferenceに存在する場合、識別子は、参照モジュール内の最上位NamedTypeの識別子でなければなりません。
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.
ExternalComponentReferenceでmodulereferenceはExternalTypeReferenceでmodulereferenceと同様に使用されています。 ExternalComponentReference内の識別子は、参照モジュール内の最上位NamedTypeの識別子でなければなりません。
The Type in the EncodingPrefixedType for a COMPONENT-REF encoding instruction SHALL be either:
いずれかでなければならないCOMPONENT-REFエンコーディング命令のEncodingPrefixedTypeを入力：
(1) a ReferencedType that is a DefinedType that is a typereference (not a DummyReference) or an ExternalTypeReference, or
（1）typereference（ないDummyReference）またはExternalTypeReferenceあるDefinedTypeあるReferencedType、または
(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の仕様のセクション5において、表1におけるプロダクションの一つであるタイプまたは参照タイプ[RXER]内蔵、又は
(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中タイプの一つであるTaggedTypeがPrefixedTypeであるBuiltinType（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基準符号化命令が含まれていないEncodingPrefixedTypeでEncodingPrefixあるPrefixedTypeあるBuiltinType。
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符号化命令の対象である場合、他のRXERエンコード命令がNamedType内で許可されていないようなものです。
The Type in the top-level NamedType referenced by the COMPONENT-REF encoding instruction MUST be either:
COMPONENT-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）が使用される場合、場合DefinedTypeと同じタイプ（1）を参照typereference又はExternalTypeReferenceあるDefinedTypeあるReferencedType、または
(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）が使用される場合、BuiltinType又はReferencedType（2）場合BuiltinType又は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）の一つであり、EncodingPrefixedTypeでEncodingPrefixがRXERエンコード命令を含む。EncodingPrefixedTypeあるPrefixedTypeあるBuiltinType
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符号化命令は、拡張名が概念的NamedTypeを作成参照最上位NamedTypeとケースで入力（1）又は（2）参照トップレベル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.
実際には、ケース内にタイプするので、元のNamedTypeなく概念的NamedTypeを使用する非RXERエンコーダおよびデコーダのために十分である（1）又は（2）のみを有するで参照最上位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エンコード命令をすることができないので除い（名目NamedTypeの代わりに参照されるトップレベルNamedTypeを使用するRXERエンコーダおよびデコーダのために十分ですもちろん、部品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モジュールで「モジュール」トップレベルNamedTypeはそうのように定義されることに注意してください。
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>
<namedTypeのxmlns：asnx = "URN：IETF：paramsは：XML：NS：asnx" NAME = "モジュール"> <sequenceOf> <要素REF = "asnx：モジュール" /> </ sequenceOf> </ namedType>
Aside: The <namedType> element in ASN.X corresponds to a TypeAssignment, not a NamedType.
脇：ASN.Xにおける<namedType>要素はTypeAssignment、ないNamedTypeに相当します。
The identifier of a NamedType subject to a COMPONENT-REF encoding instruction does not contribute to an RXER encoding. For the sake of consistency with other encoding rules, the identifier SHOULD be the same as the identifier in the ComponentRefInstruction.
COMPONENT-REF符号化命令にNamedType対象の識別子がRXER符号化には寄与しません。他の符号化規則との整合のために、識別子はComponentRefInstruction内の識別子と同じでなければなりません。
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.
ELEMENT-REF符号化命令は、それが要素の名前は、符号化命令によって参照される要素宣言の修飾名であり、素子として適用される成分の値を符号化するためにRXERエンコーダを引き起こします。また、ELEMENT-REF符号化命令は、マークアップASN.1タイプの値は、要素宣言のタイプに適合するように制限されるようにします。
The notation for an ELEMENT-REF encoding instruction is defined as follows:
次のようにELEMENT-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とRefParametersでContextParameter（存在する場合）XMLスキーマ要素宣言、RELAX NG要素定義、またはATTRIBUTEコード命令を受けない最上位NamedTypeを参照しなければなりません。
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>
<namedTypeのxmlns：asnx = "壷：IETF：のparams：XML：NS：asnx" のxmlns：XS = "http://www.w3.org/2001/XMLSchema" のxmlns：RNG = "http://relaxng.org /ns/structure/1.0" 名前= "ANYSCHEMA"> <選択> <要素REF = "asnx：モジュール" 埋め込まれた= "true" を/> <要素REF = "XS：スキーマ" 埋め込まれた= "true" を/> <要素REF =：埋め込まれた "RNG文法" = "真" /> </選択> </ 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.
ELEMENT-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.
LISTエンコード命令は、成分値の空白で区切られたリストとしてタイプのシーケンスの値を符号化するためにRXERエンコーダを引き起こします。
The notation for a LIST encoding instruction is defined as follows:
次のようにLIST符号化命令の表記法が定義されます。
ListInstruction ::= "LIST"
The Type in an EncodingPrefixedType for a LIST encoding instruction SHALL be either:
いずれかでなければならないLISTエンコーディング命令のEncodingPrefixedTypeを入力：
(1) a BuiltinType that is a SequenceOfType of the "SEQUENCE OF NamedType" form, or
（1）形態 "NamedType OF SEQUENCE" のSequenceOfTypeあるBuiltinType、又は
(2) a ConstrainedType that is a TypeWithConstraint of the "SEQUENCE Constraint OF NamedType" form or "SEQUENCE SizeConstraint OF NamedType" form, or
（2）「NamedType一連の制約」のTypeWithConstraintあるConstrainedTypeを形成または「配列SizeConstraint NamedType OF」形、又は
(3) a ConstrainedType that is not a TypeWithConstraint where the Type in the ConstrainedType is one of (1) to (5), or
（3）ConstrainedType中タイプの一つである制約を有するタイプではない制約タイプ（1）〜（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中タイプの一つであるTaggedTypeがPrefixedTypeであるBuiltinType（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）のいずれかであるEncodingPrefixedType PrefixedTypeあるBuiltinType。
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.
この条件の効果はテキストで、それが適用されるSequenceOfType又はTypeWithConstraintと同じ場所に配置されるLISTエンコード命令を強制することです。
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）にSequenceOfType及び（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:
LIST符号化指示の対象となるSequenceOfType又はTypeWithConstraintのコンポーネントタイプのベース型は、以下のいずれかである必要があります
(1) the BOOLEAN, INTEGER, ENUMERATED, REAL, OBJECT IDENTIFIER, RELATIVE-OID, GeneralizedTime, or UTCTime type, or
（1）BOOLEAN、INTEGER列挙、REAL、オブジェクト識別子、相対OID、GeneralizedTimeの、またはUTC時刻型、又は
(2) the NCName, AnyURI, Name, or QName type from the AdditionalBasicDefinitions module [RXER].
（2）AdditionalBasicDefinitionsモジュールからNCNameで、anyURIの、名前、またはQNameのタイプを[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).
脇：コンポーネントのタイプも、そのすべての抽象値がゼロより大きい長さを有し、その抽象値のどれもが、この状態かどうかをテストし、任意の空白文字を含まないように制約されている任意の文字列型であることを許可することが可能であろうが非常に関与することができ満足しています。簡略化のために、適切であることが知られている唯一の特定の即時有用制約UTF8Stringをタイプは、許可されている（すなわち、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.
LIST符号化指示の対象となるSequenceOfType又はTypeWithConstraintでNamedType属性の対象であってはなりませんATTRIBUTE-REF、COMPONENT-REF、GROUP、ELEMENT-REF、REF-AS-ELEMENT、SIMPLE-CONTENT、又はタイプ - AS-VERSIONエンコーディング命令。
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).
NAMEエンコード命令は、その識別子がそうでなければ（例えば、要素として、又は属性名）符号化に現れるどこ代わりにコンポーネントの識別子の指名文字列を使用するRXERエンコーダを引き起こします。
The notation for a NAME encoding instruction is defined as follows:
次のようにNAME符号化命令の表記法が定義されます。
NameInstruction ::= "NAME" "AS"? NCNameValue
Example
例
CHOICE { foo-att [ATTRIBUTE] [NAME AS "Foo"] INTEGER, foo-elem [NAME "Foo"] INTEGER }
CHOICE {FOO-ATT [ATTRIBUTE] INTEGER、FOO-ELEM [NAME "foo" という] INTEGER [ "foo" というAS NAME]}
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-要素符号化命令は、それが要素の名前は、符号化命令によって参照される外部DTDサブセットの要素型宣言の名前である要素として適用される成分の値を符号化するためにRXERエンコーダを引き起こします。また、REF-AS-要素符号化命令は、マークアップASN.1タイプの値がその要素型宣言とそれに関連する属性リスト宣言で許可されたコンテンツと属性に適合するように制限されるようにします。
The notation for a REF-AS-ELEMENT encoding instruction is defined as follows:
次のようにREF-AS-要素符号化命令の表記法が定義されます。
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].
まとめると、のNameValueおよびRefParametersでContextParameter（存在する場合）は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.
名前空間が存在する場合、参照要素型宣言の名前は、名前空間がPrefixedNameのプレフィックスに関連付けられる名前空間名を指定した場合にPrefixedName（QNameの）XMLNS10]に準拠している場合のみ。
The referenced element type declaration MUST NOT require the presence of attributes of type ENTITY or ENTITIES.
参照される要素型宣言は、ENTITY型や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 >
<？xmlのバージョン= '1.0'？> <！ELEMENT製品EMPTY> <！ATTLIST製品名CDATA #IMPLIED partNumberもCDATA #REQUIRED量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 }
CHOICE {産物[REF-AS-ELEMENT "製品" CONTEXT "http://www.example.com/inventory"]マークアップ}
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>
<タイプ> <選択> <要素をelementType = "製品" コンテキスト= "http://www.example.com/inventory" /> </選択> </入力>
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-要素符号化命令にNamedType対象の識別子がRXER符号化における要素の名前に寄与しません。一貫性のために、識別子は、可能な場合、参照される要素型宣言（または名前PrefixedNameに準拠している場合LocalPartは）の名前と同じでなければなりません。
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タイプの値は指名要素型宣言と外部DTDサブセット内のその関連属性リスト宣言で許可されたコンテンツと属性に適合するように制限されるようにします。
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].
まとめると、のNameValueおよびRefParametersのContextParameter（存在する場合）はXML 1.0 [XMLNS10]における名前空間に準拠した外部DTDサブセット内の要素型宣言を参照しなければなりません。
The referenced element type declaration MUST NOT require the presence of attributes of type ENTITY or ENTITIES.
参照される要素型宣言は、ENTITY型や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
【 "http://www.example.com/inventory" REF-AS-TYPE "製品" CONTEXT] inventoryItem一連のマークアップ
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>
<sequenceOf> <要素名= "inventoryItem"> <タイプをelementType = "製品" コンテキスト= "http://www.example.com/inventory" /> </要素> </ 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"/>
<inventoryItem名= "ハンマー" partNumberも= "1543" 量= "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.
SCHEMA-IDENTITY符号化命令は、符号化命令を含むASN.1モジュールと、一意の識別子、URI [URI]を関連付けます。このエンコード命令はRXERエンコーダには影響しませんが、ASN.X表現にASN.1仕様の翻訳に影響を与えません。
The notation for a SCHEMA-IDENTITY encoding instruction is defined as follows:
次のようにスキーマIDENTITY符号化命令の表記法が定義されます。
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.
各スキーマIDENTITY符号化命令のAnyURIValueによって指定された文字列は別個でなければなりません。具体的には、ASN.1モジュールの連続したバージョンは、それぞれ異なるスキーマ識別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.
単純コンテンツエンコード命令は、子要素にカプセル化することなく、SEQUENCEまたはSETタイプの成分の値を符号化する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].
SIMPLE-CONTENT符号化命令にNamedType対象はRootComponentTypeListでComponentTypeListにCOMPONENTTYPEでなければなりません。配列またはSET型のせいぜい一つのそのようなNamedTypeは、単純コンテンツエンコード命令を受けることを許可されています。任意成分は、単純コンテンツエンコード命令の対象である場合には、同じ配列またはSET型定義内の他のすべてのコンポーネントは、コンポーネントの属性である必要があります。これらの試験は、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.
脇：子要素とシンプルな内容は相互に排他的です。仕様作成者は、拡張可能な配列またはSETタイプのコンポーネントに単純コンテンツエンコード命令の使用は、配列またはSETタイプに対するすべての将来の拡張のために許可されているタイプの限定されたセットと属性のコンポーネントであることに限定されることを意味する注意してくださいコンポーネントの属性。代わりに単純コンテンツエンコード命令の属性エンコード命令を使用してこの制限を回避します。
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はUNION符号化命令を受けないCHOICE型、又は
(3) a SEQUENCE type other than the one defining the QName type from the AdditionalBasicDefinitions module [RXER] (i.e., QName is allowed), or
（3）[RXER（すなわち、QNameのが許可されている）AdditionalBasicDefinitionsモジュールからのQNameタイプを定義以外のSEQUENCEタイプ、または
(4) a SEQUENCE OF type where the SequenceOfType is not subject to a LIST encoding instruction, or
（4）SequenceOfTypeリスト符号化命令を受けないタイプのシーケンス、又は
(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.
SIMPLE-CONTENT符号化命令にNamedType対象の種類が空の文字データ変換[RXER（すなわち、空の符号化）と抽象値を持つ場合、NamedTypeはOPTIONALまたはDEFAULTマークされないもの。
Example
例
SEQUENCE { units [ATTRIBUTE] UTF8String, amount [SIMPLE-CONTENT] INTEGER }
SEQUENCE {ユニット[ATTRIBUTE] UTF8Stringを、量[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.
TARGET名前空間符号化命令は、符号化命令を含むASN.1モジュールで定義された型、オブジェクトクラス、値、オブジェクト、およびオブジェクトセットの参照で、XML名前空間名[XMLNS10]、URI [URI]を関連付けます。また、RXER符号化制御部内の各トップレベルNamedTypeと名前空間名を関連付けます。
The notation for a TARGET-NAMESPACE encoding instruction is defined as follows:
次のようにTARGET名前空間符号化命令の表記法が定義されます。
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モジュールはTARGET-NAMESPACEエンコーディング命令が含まれている場合、モジュールのターゲット名前空間は、TARGET-NAMESPACEエンコーディング命令のAnyURIValueで指定した文字列です。そうでない場合、モジュールのターゲット名前空間が存在しないと言われています。
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.
符号化命令が適用された成分の値の符号化にtype属性：TYPE-ASバージョンの符号化命令はXSIを含むようにRXERエンコーダを引き起こします。この属性は、選択するためのXMLスキーマ[XSD1]バリデータ、利用可能な場合、エンコーディングを作成するために使用される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.
脇：互換性のあるXMLスキーマにASN.1仕様の翻訳が原因ASN.1仕様プログレッシブ拡張のバージョン間でわずかに異なることが予想されます。各バージョンは、異なるターゲット名前空間を使用している場合、これらの変換の間の任意の非互換性を収容することができます。ターゲット名前空間は、XSIの値は明らかであろう：type属性およびXML Schemaのバリデータは、適切なバージョンを使用するようになります。この機構はまた、ASN.1仕様のバージョンで名前が変更されたASN.1タイプを収容します。
The notation for a TYPE-AS-VERSION encoding instruction is defined as follows:
次のようにTYPE-ASバージョンの符号化命令の表記法が定義されます。
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].
TYPE-ASバージョンの符号化命令を受けるNamedTypeを入力は、名前空間で修飾参照[RXER]でなければなりません。
The addition of a TYPE-AS-VERSION encoding instruction does not affect the backward compatibility of RXER encodings.
TYPE-AS-VERSIONエンコーディング命令の追加は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.
脇：タイプ作用属性：XSIのようにXMLスキーマanyType型に変換することが予想されるTYPE-ASバージョンの符号化指示の対象となるXMLスキーマ、NamedTypeにおける任意のタイプにASN.1仕様の訳スイッチとして適切なバージョンを選択します。
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.
TYPE-REF符号化命令はNGという名前のパターン又はASN.1定義型をRELAX、タイプという名前の特定のXMLスキーマに準拠するように制限されるマークアップ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.
脇：TYPE-REF符号化命令にASN.1タイプを参照すると、型の抽象値のRXERエンコードのインフォセット[INFOSET]表現を維持するための要件を課すという効果を有していません。まだ単なる抽象的価値を維持するのに十分です。
The notation for a TYPE-REF encoding instruction is defined as follows:
次のようにTYPE-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パラメータのコンテキストパラメータ（存在する場合）は、タイプという名前のXMLスキーマ、RELAX NG名前パターン、またはASN.1定義された型を参照しなければなりません。
A referenced XML Schema type MUST NOT require the presence of values for the XML Schema ENTITY or ENTITIES types.
参照されるXMLスキーマ型は、XMLスキーマENTITYまたはENTITIES種類の値の存在を要求してはなりません。
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は[XSD2（すなわち、名前空間名「http://www.w3.org/2001/XMLSchema」とローカル名「NOTATION」）XMLスキーマ表記タイプを直接参照してはなりません。ただし、表記タイプに由来する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スキーマの小数点型を参照するために、より自然な方法を提供することに注意してください：
<namedType xmlns:xs="http://www.w3.org/2001/XMLSchema" name="MyDecimal"> <type ref="xs:decimal" embedded="true"/> </namedType>
<namedTypeのxmlns：XS = "http://www.w3.org/2001/XMLSchema" 名前= "MyDecimal"> <タイプREF = "XS：小数点以下" 組込み= "真" /> </ 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).
UNIONエンコード命令は、子要素にカプセル化することなく、CHOICE型の代替の値を符号化するRXERエンコーダを引き起こします。選択された代替は、必要に応じてメンバー属性で示されています。任意PrecedenceListはまた、仕様ライタは、それが（実際の代替メンバー属性を使用して指定されていない場合）に使用された別の決定としてRXERデコーダはCHOICEの代替案を検討する順序を変更することを可能にします。
The notation for a UNION encoding instruction is defined as follows:
次のようにUNION符号化命令の表記法が定義されます。
UnionInstruction ::= "UNION" AlternativesPrecedence ?
AlternativesPrecedence ::= "PRECEDENCE" PrecedenceList
PrecedenceList ::= identifier PrecedenceList ?
The Type in the EncodingPrefixedType for a UNION encoding instruction SHALL be either:
いずれかでなければならないUNIONエンコーディング命令のEncodingPrefixedTypeを入力：
(1) a BuiltinType that is a ChoiceType, or
（1）ChoiceTypeあるBuiltinType、又は
(2) a ConstrainedType that is not a TypeWithConstraint where the Type in the ConstrainedType is one of (1) to (4), or
（2）ConstrainedType中タイプの一つである制約を有するタイプではない制約タイプ（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中タイプの一つであるTaggedTypeがPrefixedTypeであるBuiltinType（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）のいずれかであるEncodingPrefixedType PrefixedTypeあるBuiltinType。
The ChoiceType in case (1) is said to be "subject to" the UNION encoding instruction.
ケース（1）においてChoiceTypeはUNION符号化命令「対象」であると言われます。
The base type of the type of each alternative of a ChoiceType that is subject to a UNION encoding instruction SHALL NOT be:
UNION符号化指示の対象となるChoiceTypeの各代替の種類の基本型があってはなりません。
(1) a CHOICE, SET, or SET OF type, or
（1）CHOICE、SET、またはタイプのセット、又は
(2) a SEQUENCE type other than the one defining the QName type from the AdditionalBasicDefinitions module [RXER] (i.e., QName is allowed), or
（2）[RXER（すなわち、QNameのが許可されている）AdditionalBasicDefinitionsモジュールからのQNameタイプを定義以外のSEQUENCEタイプ、または
(3) a SEQUENCE OF type where the SequenceOfType is not subject to a LIST encoding instruction, or
（3）SequenceOfTypeリスト符号化命令を受けないタイプのシーケンス、又は
(4) an open type.
（4）オープンタイプ。
Each identifier in the PrecedenceList MUST be the identifier of a NamedType in the ChoiceType.
PrecedenceList内の各識別子はChoiceTypeでNamedTypeの識別子でなければなりません。
A particular identifier SHALL NOT appear more than once in the same PrecedenceList.
特定の識別子は同じPrecedenceListで複数回表示されないものとします。
Every NamedType in a ChoiceType that is subject to a UNION encoding instruction MUST NOT be subject to an ATTRIBUTE, ATTRIBUTE-REF, COMPONENT-REF, GROUP, ELEMENT-REF, REF-AS-ELEMENT, SIMPLE-CONTENT, or TYPE-AS-VERSION encoding instruction.
UNIONのエンコード命令の対象となるChoiceType内のすべてのNamedTypeはATTRIBUTEの対象にはならない（MUST NOT）、ATTRIBUTE-REF、COMPONENT-REF、GROUP、ELEMENT-REF、REF-AS-ELEMENT、SIMPLE-CONTENT、またはTYPE-AS- VERSIONエンコーディング命令。
Example
例
[UNION PRECEDENCE basicName] CHOICE { extendedName UTF8String, basicName PrintableString }
[UNION優先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.
VALUES符号化命令ではなく、そうでなければ、ビット列列挙、または整数型の値の符号化に現れる識別子の指名名を使用する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:
いずれかでなければならないVALUESエンコーディング命令のEncodingPrefixedTypeを入力：
(1) a BuiltinType that is a BitStringType with a NamedBitList, or
（1）NamedBitListとBitStringTypeあるBuiltinType、又は
(2) a BuiltinType that is an EnumeratedType, or
（2）EnumeratedTypeあるBuiltinType、又は
(3) a BuiltinType that is an IntegerType with a NamedNumberList, or
（3）NamedNumberListとIntegerTypeあるBuiltinType、又は
(4) a ConstrainedType that is not a TypeWithConstraint where the Type in the ConstrainedType is one of (1) to (6), or
（4）ConstrainedType中タイプの一つである制約を有するタイプではない制約タイプ（1）〜（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）のいずれかであるTaggedType PrefixedTypeあるBuiltinType、または
(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）のいずれかであるEncodingPrefixedType PrefixedTypeあるBuiltinType。
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.
それぞれBitStringType、EnumeratedType、又はIntegerType（1）の場合に、（2）又は（3）は、命令をコードVALUES "対象" であると言われます。
A BitStringType, EnumeratedType, or IntegerType SHALL NOT be subject to more than one VALUES encoding instruction.
BitStringType、EnumeratedType、またはIntegerTypeは、複数のVALUES符号化命令を受けてはなりません。
Each identifier in a ValueMapping MUST be an identifier appearing in the NamedBitList, Enumerations, or NamedNumberList, as the case may be.
場合によってはValueMapping内の各識別子は、NamedBitList、列挙型、またはNamedNumberListに現れる識別子でなければなりません。
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.
定義（代替名）：VALUES符号化命令に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.
VALUES符号化命令にBitStringType対象における識別子の代替名は別個でなければなりません。
The replacement names for the identifiers in an EnumeratedType subject to a VALUES encoding instruction MUST be distinct.
VALUES符号化命令にEnumeratedType対象における識別子の代替名は別個でなければなりません。
The replacement names for the identifiers in an IntegerType subject to a VALUES encoding instruction MUST be distinct.
VALUES符号化命令に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エンコーディング命令の一部は挿入エンコードの命令として分類されます。挿入エンコード命令は、NO-挿入、中空挿入、単数-挿入、均一挿入、および（表記NoInsertionsInstruction、HollowInsertionsInstruction、SingularInsertionsInstruction、UniformInsertionsInstruction、及びMultiformInsertionsInstructionによってそれぞれ記載されている）多形、挿入符号化命令です。
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.
最も一般的な場合では、CHOICE、SET、または配列型への拡張が原因拡張によるグループ属性エンコード命令の潜在的な使用のために、ゼロ以上の属性及びゼロ以上の要素を生成します。
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」という呼ばれるかもしれません。
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.
NO-挿入符号化命令には前方互換性拡張が型に行われないことができることを示しています。
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はUNION符号化命令を受けないChoiceTypeであるBuiltinType、又は
(2) a BuiltinType that is a SequenceType or SetType, or
（2）SequenceType又ははsetType、またはあるBuiltinType
(3) a ConstrainedType that is not a TypeWithConstraint where the Type in the ConstrainedType is one of (1) to (5), or
（3）ConstrainedType中タイプの一つである制約を有するタイプではない制約タイプ（1）〜（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中タイプの一つであるTaggedTypeがPrefixedTypeであるBuiltinType（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）のいずれかであるEncodingPrefixedType PrefixedTypeあるBuiltinType。
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.
脇：SETまたはSEQUENCEタイプの拡張は、シリアルおよび有効オプションであるので、単数-挿入、均一挿入、及び多形-挿入エンコード命令は、（SET又は配列について）無制限の拡張に対して何ら利点を提供しません。例えば、特異挿入の任意一連だけ無制限の拡張のような、ゼロまたはそれ以上の要素およびゼロ以上の属性を生成します。
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).
VERSIONインジケータ符号化命令は、符号化は、互換性（前のセクションを参照）を前方に破壊拡張が含まれていることを警告するRXERデコーダのための機構を提供します。
The notation for a VERSION-INDICATOR encoding instruction is defined as follows:
次のようにVERSIONインジケータ符号化命令の表記法が定義されます。
VersionIndicatorInstruction ::= "VERSION-INDICATOR"
A NamedType that is subject to a VERSION-INDICATOR encoding instruction MUST also be subject to an ATTRIBUTE encoding instruction.
VERSIONインジケータ符号化指示の対象となるNamedTypeもATTRIBUTE符号化命令に従わなければなりません。
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.
VERSIONインジケータ符号化指示の対象となるNamedTypeのタイプは、直接的または間接的に許可される値のセットは拡張可能であると定義される拘束型である必要があります。各値は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エンコーディングに関して互換性がないことを示しています。 GROUPエンコーディング命令はそれらに適用されないので、他のエンコーディングは影響を受けません。
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 }
SEQUENCE {バージョン[ATTRIBUTE] [VERSION-INDICATOR] INTEGER（1、...、2..3）、メッセージの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".
受信RXER符号化におけるformat属性の値がない「1.0」、「1.1」、または「2.0」である場合には、この第2の例では、デコーダは、互換性のない古いバージョンを使用しています。
SEQUENCE { format [ATTRIBUTE] [VERSION-INDICATOR] UTF8String ("1.0", ..., "1.1" | "2.0"), message MessageType }
SEQUENCE {フォーマット[ATTRIBUTE] [VERSION-INDICATOR] UTF8Stringを（ "1.0"、...、 "1.1" | "2.0"）、メッセージの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）配列、SET、またはタイプのセット、又は
(2) a CHOICE type where the ChoiceType is not subject to a UNION encoding instruction, or
（2）ChoiceTypeはUNION符号化命令を受けないCHOICE型、又は
(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）内蔵型のために関連するタイプであってはならない、AdditionalBasicDefinitionsモジュール[RXER]からタイプであってはならない、と単純コンテンツエンコード命令の対象となる成分を含んではなりません。
Aside: Thus, the CHARACTER STRING, EMBEDDED PDV, EXTERNAL, REAL, and QName types are excluded.
脇：したがって、文字列は、組み込みPDV、EXTERNAL、REAL、およびQNameのタイプは除外されています。
The CHOICE type in case (2) SHALL NOT be a type from the AdditionalBasicDefinitions module.
ケース（2）内のCHOICE型はAdditionalBasicDefinitionsモジュールからのタイプであってはなりません。
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タイプ（すなわち、SEQUENCE、SET、CHOICE、一連の、または一組）であるタイプの可視コンポーネントは、構成要素のセットでありますグループ符号化命令、NamedTypeのタイプの可視コンポーネントを受ける（結合型定義の）各NamedTypeための結合型定義に加え、。可視成分は、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は（タイプ定義が再帰的である場合にのみ可能である）は同じNamedTypeのタイプの可視成分であることが原因となる場合GROUPエンコード命令を使用してはいけません。
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]としてグループ定義に翻訳されるかもしれません。独自のタイプに見えるNamedTypeは、XMLスキーマが禁止円形基に類似しています。
Section 25.1 imposes additional conditions on the use of the GROUP encoding instruction.
セクション25.1は、GROUPエンコーディング命令の使用に関する追加条件を課します。
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.
グループ符号化命令の使用において、タイプがあり、グループ符号化命令に構成被写体が含ま含むタイプ、およびタイプ、含まれるタイプ、すなわち、そのコンポーネントの基本型です。どちらのタイプは、直接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モジュールで定義されるかもしれ含まタイプ。
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.
含むタイプの所有者が含まタイプの定義の最新バージョンを使用していない場合は、を含むタイプの所有者は、付属のタイプの旧バージョンに対する有効であるなどの種類に拡張子を追加するかもしれませんが、後で含め、付属の型定義の最新バージョンは、（おそらく第三者によって）一緒にされたときに無効であることが判明しました。含むタイプは必ずしも含まタイプの存在を知っていなければならないの所有者が、その逆は必ずしも真ではありません。含まタイプの所有者は、それが形を含めています他の誰かを無効にすることを実現することなく含まタイプに拡張子を追加することができます。
To avoid these problems, a GROUP encoding instruction MUST NOT be used if:
これらの問題を回避するには、GROUPのエンコード命令があれば使用してはいけません。
(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）付属タイプの所有者は、以下を含むタイプの所有者でもある、又は
(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エンコーディングを持っていることを保証するために、GROUPエンコーディング命令の使用に制限を課しています。加えて、これらの制限は、抽象値を簡単バックトラッキングすることなく、単一パスで復号することができることを確認してください。
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
セクション25.1.1は、文法、グループ符号化指示の対象成分を含有する型定義を作り直すための手順を記載しています。セクション25.1.2および25.1.3は、条件を指定します
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.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.
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.
脇：NamedTypeための非末端二は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.
各ExtensionAdditionとExtensionAdditionAlternativeは、関連する非末端を有しています。各拡張可能型の拡張挿入点に関連付けられた非末端があります。プライマリスタート非末端（これは開始記号である）と、二次開始非終端もあります。非端末の正確な性質は重要ではない、しかし、すべての非端末が互いに異なるものでなければなりません。
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.
（しない最も一般的な場合にも）NamedTypeの一次非末端NamedTypeがするための識別子のために、一次ためSであることが非終端開始それがために、このドキュメントの例の大部分に適していますExtensionAdditionとExtensionAdditionAlternativeのインスタンスの非端子は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.
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、および塩基型がSEQUENCEまたはSET型で型を与え、生産は左側として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）ExtensionAdditionsインスタンスはベース型に存在し、空でない場合、次にExtensionAdditionsインスタンスにネスト第ExtensionAdditionための非末端は右側に追加されています。
(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）ExtensionAdditionsインスタンスは、ベース型で存在空かず、基本型は、（明示的またはデフォルトで）拡張可能であり、基本型は、次いで、NO-挿入または中空挿入エンコード命令を受けない場合ベース型の拡張挿入ポイントの非末端右側に追加されています。
(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.
ExtensionAdditionsインスタンスが空であるか、ベース型には存在しない、および塩基型が（明示的またはデフォルトで）拡張可能であり、ベースタイプがNO-挿入エンコード命令を受けない場合に生産が挿入ポイントの生産です。
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.
（RootComponentTypeList又はExtensionAdditionGroupのいずれかで）ComponentTypeListコンポーネントがOPTIONALまたはDEFAULTマークされている場合、左側のような成分と空右側の一次非末端との生産が追加されています文法。
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結合型の）成分がGROUP符号化命令の対象である場合には、コンポーネントのタイプに従って構築一つ以上の生産を文法に追加されます。これら作品のそれぞれは、左側コンポーネントの一次非末端を有しています。
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の）成分がGROUP符号化命令を受けない場合には、生産が左側及び端末などのコンポーネントの一次非末端と文法に追加されます右側コンポーネントの。
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. }
SEQUENCE { - 初期RootComponentTypeListのスタート。 1 [ATTRIBUTE] UTF8Stringを、任意の2つのBOOLEAN、3つのINTEGER - 初期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.
（SEQUENCEまたはSETベース型の）各ExtensionAdditionため、生産は左側がExtensionAdditionための非末端であり、右側が最初は空である文法に追加されます。 ExtensionAdditionがCOMPONENTTYPEある場合、COMPONENTTYPEでNamedTypeための非末端第一級は右側に追加されています。そうでない場合は（ExtensionAdditionGroup）、ExtensionAdditionGroupにComponentTypeListにネストされたコンポーネントのための主要な非末端の配列は、それらの定義のために右側に追加されています。 ExtensionAdditionが別ExtensionAdditionが続いている場合、次ExtensionAdditionため、非末端は右側に追加されています。そうでない場合は、基本型は、基本型の拡張挿入点に対して、非末端、NO-挿入または中空挿入エンコード命令を受けない場合は右側に追加されています。 ExtensionAdditionが他ExtensionAddition続いていないとベースタイプがNO-挿入エンコード命令を受けない場合には、生産が挿入ポイントの生産です。端末の空のシーケンスは、（文法は、この判断を行う前に、そうでなければ完了するまで待つ必要があるかもしれない）製造から生成することができない場合、別の生産は左側が非端末である文法に追加されます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].
脇：ExtensionAdditions用に生成文法は以前のすべての拡張機能も[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:
SEQUENCEまたはSETベースタイプは拡張可能であり（明示的またはデフォルトで）、次いで、NO-挿入または中空挿入エンコード命令を受けない場合：
(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 }
SEQUENCE { - 初期RootComponentTypeListのスタート。 1つのBOOLEAN、任意の2つのINTEGER、 - 初期RootComponentTypeListの終わり。 ...、 - ExtensionAdditionsのスタート。 4つのINTEGER、 - まずExtensionAddition（E1）。 5 BOOLEAN OPTIONAL、 - セカンドExtensionAddition（E2）。 [[ - ExtensionAdditionGroup。 6つのUTF8Stringを、7つのINTEGER OPTIONAL]]、 - 第三ExtensionAddition（E3）。 - ExtensionAdditionsの終わり。 - 拡張挿入点は、ここで（I1）です。 ...、 - 最終RootComponentTypeListのスタート。 3つの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:
SEQUENCEタイプがNO-挿入または中空挿入エンコード命令を受けた場合、I1のために制作は表示されません、およびE3のための最初の製造は次のようになります。
E3 ::= six seven
Given a primary non-terminal, N, and a type where the base type is a CHOICE type:
プライマリ非末端、N、および塩基型がCHOICE型であるタイプ与えられます。
(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）生産は、左側がNであり、右側がNamedTypeための非末端第一級である。基本型のRootAlternativeTypeListにネスト各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であり、右側がExtensionAdditionAlternativeための非端末である基本型の各ExtensionAdditionAlternativeための文法に追加されます。
(3) If the base type is extensible (explicitly or by default) and the base type is not subject to an insertion encoding instruction, then:
（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.
(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.
Aside: This production is used to verify the correctness
of an ASN.1 type definition, but would not be used in the
implementation of an RXER decoder. The next production
takes precedence over it for accepting an unknown element.
(b) A production is added to the grammar where the left-hand side is N and the right-hand side is the terminal for the extension insertion point of the base type followed by the non-terminal for the extension insertion point. This production is an insertion point production.
（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.
(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であれば、生産が左側にExtensionAdditionAlternativeと右側用の非末端で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.
ExtensionAdditionAlternativeがExtensionAdditionAlternativesGroupである場合、生産が左側にExtensionAdditionAlternativeと右側用の非末端でExtensionAdditionAlternativesGroupにネストされた各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). }
CHOICE { - RootAlternativeTypeListのスタート。 1つのBOOLEAN、2つの整数、 - RootAlternativeTypeListの終わり。 ...、 - ExtensionAdditionAlternativesのスタート。 3つのINTEGER、 - まずExtensionAdditionAlternative（E1）。 [[ - ExtensionAdditionAlternativesGroup。 4つのUTF8Stringを、5つのINTEGER]] - セカンドExtensionAdditionAlternative（E2）。 - 拡張挿入点は、ここで（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.
CHOICEタイプがNO-挿入エンコード命令を受けた場合には、第五は、第六、第七および制作は除去されます。
If the CHOICE type were subject to a HOLLOW-INSERTIONS encoding instruction, then the fifth, sixth, and seventh productions would be replaced by:
CHOICEタイプが中空挿入エンコード命令を受けた場合、第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:
CHOICEタイプが特異-挿入エンコード命令を受けた場合、第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:
CHOICEタイプが均一挿入エンコード命令を受けた場合、第5及び第六のプロダクションによって置換されます。
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:
CHOICEタイプは多形、挿入符号化命令を受けた場合には、第五の生産をすることによって置換されます。
S ::= "*" I1
Constraints on a SEQUENCE, SET, or CHOICE type are ignored. They do not affect the grammar being generated.
SEQUENCE、SET、またはCHOICEタイプの制約は無視されます。彼らは、生成された文法には影響を与えません。
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、及びOF SEQUENCEまたは塩基型のセットを有しており、それはサイズがゼロ（すなわち、空のシーケンスまたはセット）の値を許容タイプ与えられます。
(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であり、右側が続く、一連のまたは塩基型のセットの成分のNamedTypeための非末端第一級である文法に追加されます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であり、右側が空の文法に追加されます。
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続いて、一次のシーケンスの成分のNamedTypeための非末端または塩基型の設定され、そして
(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」であり、右側は、一次のシーケンスの成分のNamedTypeための非末端または塩基型の設定されている文法に追加され、 「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
数INTEGERのシーケンスSIZE（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) 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）文法によって使用され、属性の成分が同じ拡張名を持つに関連付けられ、二種以上の一次非端子
(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:
次の例のタイプは、一意のコンポーネント属性に対するGROUP符号化命令の様々な使用及び誤用を示しています。
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:
二つ以上の一次非端末は要素部品は、同じ拡張名を持つ関連付けられている2つのインスタンスが存在するので、TAの型定義は無効です。
(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はNamedType表記の同じインスタンスに由来するが、変換の構成要素次の別個の構成要素となります。自動タグ付けは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.b.bとTA.c（両末端「@c」を生成する）、2つ以上の一次非端子が同じ拡張名を持つ属性コンポーネントに関連する1つのインスタンスがあるのでTAの型定義も無効です。
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の第1のセットは、（P）まず付してみよう、すべての要素端末Tが存在することができ、Pの右側から生成することができる端末のシーケンスの最初の要素の端子であるTの組であります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）で表される、すべての要素端末Tは文法から生成することができる非端子及び端子の配列におけるN次の第一素子端子であるTの組であります。非端子及び端子の配列は、Nが任意の要素端子が続かない文法から生成することができる場合、NとTとの属性の任意の数の端末が存在することができ、その後、特別なエンド端末が含まれている（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）が真であるとする、空（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.
定義（基本文法）：基本文法は、すべてExtensionAdditionとExtensionAdditionAlternativeための非端子が全てプロダクションの右側から除去された文法の書き換えです。
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）は、唯一の基本文法を使用してPの右側から生成することができる端末のすべての配列は、少なくとも1台の属性端末が含ま場合にのみ真であるとします。それ以外の場合は、事前に選択された（P）は偽です。
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).
生産Pの選択セットは、選択（P）は、事前に選択された（P）が真である場合は空で示されます。それ以外の場合は、まず、（P）が含まれています。その後もフォロー（N）が含まれています（P）を選択し、空（P）が真である場合にはN Pの左側に非ターミナルとします。
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.
非終端Nのリーチ集合を、リーチ（N）は、TはNから生成することができる端子の配列に現れる全ての素子端子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.
脇：容易に彼らの不作為はまず、フォロー、選択、またはリーチを変更していないため、すべてのオプションの属性コンポーネントおよびSEQUENCEまたはSETタイプの必須属性要素のうちの1つを除くすべての文法を構築する上で無視することができますことを示すことができますセット、または事前に選択されたと空の述語の評価。
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）が選択（P）及び選択（Q）の交差が空ではない左側、上に同じ非末端を有する2つのプロダクションPと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）の交差が空でないExtensionAddition又はExtensionAdditionAlternativeための非端末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符号化における要素の要素内容と一致する要素端子の配列を構築するための唯一の可能な方法があります。未知の属性を受け入れることができる少なくとも一つの挿入ポイントの生産がその建設に使用されている場合、要素の任意の未知の属性が受け入れられています。
Example
例
Consider this type definition:
このタイプの定義を考えてみましょう：
CHOICE { one UTF8String, two [GROUP] SEQUENCE { three INTEGER, ... } }
CHOICE {1つのUTF8Stringを、2 [GROUP] SEQUENCE {3つの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).
要素の内容は、<1>子要素が含まれている場合、このタイプの値をデコードすると、挿入ポイントの生産が入力を認識するために使用されないように、その後、未認識の属性は違法になります（「1」の代替は認めていません拡張挿入ポイント）。元素の含有量が<3>要素が含まれている場合、挿入ポイント生産が入力を認識するために使用されるので、その後、認識されていない属性は、（<3>要素を生成し、「二」の代替は、拡張型を持つ）受け入れられるであろう。
If the SEQUENCE type were prefixed by a NO-INSERTIONS encoding instruction, then the third, fourth, and fifth productions would be replaced by:
SEQUENCEタイプがNO-挿入符号化命令で始まるした場合、第三、第四、及び第五のプロダクションによって置換されます。
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.
交換用の生産が挿入ポイントの生産ではありませんので、この変更により、未認識の属性は、また、「2」の代替のために違法になります。
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.
(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）単一拡張挿入点があっても、未知の拡張は依然として有効な型定義の無数のいずれかの値の符号化とすることができます。例えば、属性または要素コンポーネントは、そのコンポーネントGROUP符号化指示の対象となっている選択肢の範囲内の任意の深さまでネストすることができます。
Aside: A similar series of nested CHOICEs could describe an
unknown extension in a Basic Encoding Rules (BER) encoding
[X.690].
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コンパイラの実装は、GROUPエンコーディング命令が正しく使用されていることを確認するに徹底する特別な注意を払う必要があります。それ以外の場合は、あいまいなRXERエンコーディングとのASN.1仕様が展開することができます。
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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]バーナーズ - リー、T.、フィールディング、R.、および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]レッグ、S.と、RFC 4910、2007年7月 "抽象構文記法1（ASN.1）のための堅牢なXMLエンコーディング規則（RXER）" D.バッドミットプラーガー、。
[ASN.X] Legg, S., "Abstract Syntax Notation X (ASN.X)", RFC 4912, July 2007.
【ASN.X】レッグ、S.、 "抽象構文記法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（7月2日）| 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、EXTENDED-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（7月2日）| 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]ブレイ、T.、パオリ、J.、Sperberg-マックィーン、C.、MALER、Eおよび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]ブレイ、T.、オランダ、D.、素人、A.、およびR.トビン、 "XML 1.0に名前空間（第二版）"、W3C勧告、http://www.w3.org/TR/2006 / REC-XML-名-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]トンプソン、H.、ブナ、D.、マロニー、M.およびN.メンデルゾーン、 "XMLスキーマパート1：構造第二版"、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]ビロン、P.およびA.マルホトラ、 "XMLスキーマパート2：データ型第二版"、W3C勧告、http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/、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]クラーク、J.とM.誠、委員会は/リラックス-NG /チュートリアル-20011203.html、2001年12月に、OASIS委員会仕様、http://www.oasis-open.org/ "NGチュートリアルをRELAX"。
[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]コーワン、J.とR.トビン、 "XML情報セット（第二版）"、W3C勧告、http://www.w3.org/ TR / 2004 / REC-XML-インフォセット-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（7月2日）| ISO / IEC 8825から1、情報技術 - ASN.1エンコーディング規則：基本符号化規則（BER）の仕様、Canonicalの符号化規則（CER）、および顕著な符号化規則（DER）。
Appendix A. GROUP Encoding Instruction Examples
付録A. GROUPエンコーディング命令の例
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.
この付録では、例えば、型定義に由来する文法に対して決定されたグループの符号化命令の正しいと不適切な使用、の両方の例を含んでいます。文法のプロダクションは、利便性のために標識されています。彼らは非決定論を示したことがないので、唯一の生産と非端末のセットと述語が例から省略されます。
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（「ユニークなコンポーネントの帰属」）の要件は、すべてこの付録の例と、それに続く付録によって満たされます。
A.1. Example 1
A.1。例1
Consider this type definition:
このタイプの定義を考えてみましょう：
SEQUENCE { one [GROUP] SEQUENCE { two UTF8String OPTIONAL } OPTIONAL, three INTEGER }
SEQUENCE {1 [GROUP] SEQUENCE {2 UTF8StringをOPTIONAL} OPTIONAL三の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" }
最初の（P2）= { "2"}最初の（P3）= {}事前に選択された事前に選択された（P3）が偽空（P2）を= =（P2）=空（P3）は、真のフォロー（1）=を= { "三"}を選択（P2）まず（P2）+フォロー（一つ）= = { "2"、 "3"}（P3）を選択するには、最初の（P3）+フォロー（1）= { "三"}を=
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" }
最初の（P4）= { "2"}最初の（P5）= {}事前に選択され（P4）=事前に選択され（P5）=空（P4）が偽空（P5）を= TRUEフォローを=（2）= { "三"}を選択（P4）第（P4）を= = { "2"}（P5）を選択するには、最初の（P5）+フォロー（2つ）= = { "三"}
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.
セレクト（P2）と選択（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 }
SEQUENCE {1 [GROUP] SEQUENCE {2つのUTF8StringをOPTIONAL 4 [ATTRIBUTE] BOOLEAN、5 [ATTRIBUTE] BOOLEAN OPTIONAL} OPTIONAL三の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" }
最初の（P2）= { "2"}最初の（P3）= {}事前に選択された（P3）=空（P2）= FALSE事前に選択された（P2）=空（P3）は、真のフォロー（1）=を= { "三"}を選択（P2）= {}（P3）を選択するには、最初の（P3）+フォロー（1）= { "三"}を=
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" }
最初の（P4）= { "2"}最初の（P5）= {}事前に選択され（P4）=事前に選択され（P5）=空（P4）が偽空（P5）を= TRUEフォローを=（2）= { "三"}を選択（P4）第（P4）を= = { "2"}（P5）を選択するには、最初の（P5）+フォロー（2つ）= = { "三"}
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" }
まず（P7）= {}まず（P8）= {}事前に選択された（P8）=空（P7）偽事前に選択された（P7）を= =空（P8）が真のフォロー（5）=を= { "3"}セレクト（P7） = {}選択（P8）まず（P8）+フォロー（5）=を= { "三"}
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.
選択（P4）と選択（P5）と選択（P7）と選択（P8）の交差点の交差点であるように選択（P2）と選択（P3）の交差は空です。したがって、文法は確定的で、型定義が有効です。正しいRXER符号化では、「1」の成分は、「4つの」属性が存在している場合にのみ存在するであろう。
A.2. Example 2
A.2。例2
Consider this type definition:
このタイプの定義を考えてみましょう：
CHOICE { one [GROUP] SEQUENCE { two [ATTRIBUTE] BOOLEAN OPTIONAL }, three INTEGER, four [GROUP] SEQUENCE { five BOOLEAN OPTIONAL } }
CHOICE {1 [GROUP] SEQUENCE {2 [ATTRIBUTE] BOOLEAN OPTIONAL}三のINTEGER 4 [GROUP] SEQUENCE {5 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", "$" }
最初の（P1）= {}最初の（P2）= { "三"}最初の（P3）= { "5"}事前に選択され（P1）=事前に選択された（P2）=事前に選択された（P3）が偽空（P2）が偽空の==します（P1）=空（P3）は、真のフォロー（S）=を= { "$" は}選択（P1）まず（P1）+フォロー（S）= { "$" が}選択（P2）は=最初の（P2）= = { "3"}（P3）を選択するには、最初の（P3）+フォロー（S）を= = { "5"、 "$"}
First(P5) = { } First(P6) = { } Preselected(P6) = Empty(P5) = false Preselected(P5) = Empty(P6) = true Follow(two) = { "$" } Select(P5) = { } Select(P6) = First(P6) + Follow(two) = { "$" }
まず、（P5）= {}まず（P6）= {}事前に選択された（P6）=空（P5）偽事前に選択された（P5）を= =空（P6）が真のフォロー（2）=を= { "$"}セレクト（P5） = {}（P6）を選択するには、最初の（P6）+フォロー（2）= { "$" を} =
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) = { "$" }
まず（P9）= { "5"}まず（P10）= {}事前に選択された（P9）=事前に選択された（P10）=空（P9）が偽空（P10）が真のフォローは（5）= { "$"}選択します= = （P9）はまず（P9）を= = { "5"}（P10）=最初の（P10）+フォロー（5）= { "$"}を選択
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.
選択（P1）と選択（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 } }
CHOICE {1 [GROUP] SEQUENCE {2 [ATTRIBUTE] BOOLEAN}三のINTEGER 4 [GROUP] SEQUENCE {5 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", "$" }
最初の（P1）= {}最初の（P2）= { "三"}最初の（P3）= { "5"}事前に選択された（P2）=事前に選択された（P3）が偽空（P1）=空（P2）が偽事前に選択された==します（P1）=空（P3）は、真のフォロー（S）= { "$"}選択（P1）= {}選択（P2）をまず（P2）=を== { "三" は}選択（P3）まず（P3を= ）+フォロー（S）= { "5"、 "$"}
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) = { "$" }
まず、（P8）= { "5"}まず（P9）= {}事前に選択された（P8）=事前に選択された（P9）=空（P8）が偽空（P9）を= TRUEフォロー（5）= { "$"}選択= （P8）（P9）を選択するには、最初の（P8）= { "5"} = =最初の（P9）+フォロー（5）= { "$"}
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.
選択（P1）と選択（P2）の交差が空で、選択（P1）と選択（P3）の交差が空で、選択（P2）と選択（P3）の交差は空であり、そして選択の交差点（P8）と選択（P9）が空です。したがって、文法は確定的で、型定義が有効です。 「1」の代替は必須属性を持っているので、「1」と「4」の選択肢は区別することができます。
A.3. Example 3
A.3。例3
Consider this type definition:
このタイプの定義を考えてみましょう：
SEQUENCE { one [GROUP] CHOICE { two [ATTRIBUTE] BOOLEAN, three [GROUP] SEQUENCE OF number INTEGER } OPTIONAL }
SEQUENCE {数INTEGERの[GROUP] CHOICE {2 [ATTRIBUTE] BOOLEAN三[GROUP] SEQUENCE} 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) = { "$" }
最初の（P2）= {}最初（P3）= { "数"}最初の（P4）= {}事前に選択された（P3）=事前に選択され（P4）=空（P2）が偽事前に選択された（P2）=空（P3）を= =空の（P4）は、真のフォロー（1）= { "$"}選択（P2）= {}選択（P3）をまず（P3）+フォロー（1）= { "ナンバー"、 "$"}を選択し（P4 ==します）=最初の（P4）+フォロー（1）= { "$"}
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) = { "$" }
まず、（P6）= { "数"}まず（P7）= {}事前に選択された（P6）=事前に選択された（P7）=空（P6）が偽空（P7）を= TRUEフォロー（3）= { "$"}選択= （P6）第（P6）= { "数" は}（P7）を選択= =最初の（P7）+フォロー（3）= { "$"}
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.
セレクト（P3）と選択（P4）の交点は空ではありません。したがって、文法は確定的ではなく、型定義は有効ではありません。タイプの値のRXERエンコーディングが空である場合、「1」の成分が存在しないか、または空の「三」代替が選択されているかどうかを決定することは不可能です。
A.4. Example 4
A.4。例4
Consider this type definition:
このタイプの定義を考えてみましょう：
SEQUENCE { one [GROUP] CHOICE { two [ATTRIBUTE] BOOLEAN, three [ATTRIBUTE] BOOLEAN } OPTIONAL }
SEQUENCE {1 [GROUP] CHOICE {2 [ATTRIBUTE] BOOLEAN三[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) = { "$" }
最初の（P2）= {}最初（P3）= {}最初の（P4）= {}事前に選択され（P4）=空（P2）=空（P3）は= FALSE事前に選択された（P2）=事前に選択された（P3）=空（P4 ）真のフォロー（1）= { "$" は}（P2）を選択= = {}（P3）を選択= {}（P4）=最初の（P4）+フォロー（1）= { "$"}を選択
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.
選択（P2）と選択（P3）の交差が空で、選択（P2）と選択（P4）の交差は空であり、選択（P3）と選択（P4）の交差は空です。したがって、文法は確定的で、型定義が有効です。
A.5. Example 5
A.5。例5
Consider this type definition:
このタイプの定義を考えてみましょう：
SEQUENCE { one [GROUP] SEQUENCE OF number INTEGER OPTIONAL }
SEQUENCE {数INTEGER OPTIONALの[GROUP] SEQUENCE}
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) = { "$" }
最初の（P2）= { "数"}最初の（P3）= {}最初の（P4）= {}事前に選択された（P2）=事前に選択された（P3）=事前に選択され（P4）偽空（P2）を= FALSE空（P3）を= =空（P4）真フォロー（一つ）= = { "$" は}（P2）を選択するには、最初の（P2）= { "番号"} =（P3）を選択するには、最初の（P3）+フォロー（1）= {「$を= $ "}"}（P4）=最初の（P4）+フォロー（1）= {選択"
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.
セレクト（P3）と選択（P4）の交点は空ではありません。したがって、文法は確定的ではなく、型定義は有効ではありません。タイプの値のRXER符号化は、任意の<番号>子要素を持たない場合、「1」の成分値に存在するか否かを判断することは不可能です。
Consider this similar type definition with a SIZE constraint:
SIZE制約と、この同様のタイプの定義を考えてみましょう：
SEQUENCE { one [GROUP] SEQUENCE SIZE(1..MAX) OF number INTEGER OPTIONAL }
SEQUENCE {数INTEGER OPTIONALの[GROUP] SEQUENCEサイズ（1..MAX）}
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) = { "$" }
まず、（P2）= { "数"}まず（P5）= {}事前に選択された（P2）=事前に選択された（P5）=空（P2）が偽空（P5）を= trueをフォロー（1）=を= { "$"}を選択（P2）が最初に（P2）= { "数" は}（P5）を選択=最初の（P5）+フォロー（一つ）= = { "$"}
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') = { "$" }
まず、（P3）= { "数"}まず（P4）= {}事前に選択された（P3）=事前に選択された（P4）=空（P3）が偽空（P4）が真のフォロー（1 '）を= = = { "$"} （P3）ファースト（P3）= { "数"}（P4）を選択する=最初の（P4）+フォロー（1 '）を= = { "$"}を選択
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.
選択（P3）と選択（P4）との交点であるように選択（P2）と選択（P5）の交差点は、空です。したがって、文法は確定的で、型定義が有効です。何<番号>子要素が存在しない場合は、「1」の成分は必ずしも存在せず、全くあいまいさは存在しません。
A.6. Example 6
A.6。例6
Consider this type definition:
このタイプの定義を考えてみましょう：
SEQUENCE { beginning [GROUP] List, middle UTF8String OPTIONAL, end [GROUP] List }
{[GROUP]一覧、中央UTF8StringをOPTIONAL、エンド[GROUP]一覧開始} SEQUENCE
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", "$" }
最初の（P2）= { "文字列"}最初の（P3）= {}事前に選択された（P2）=事前に選択された（P3）=空（P2）が偽空（P3）を= "真のフォロー（開始）= { "中央の"=文字列」、 "$"}]を選択します（P2）ファースト（P2）= {= "文字列は"}（P3）を選択=最初の（P3）+フォロー（開始）= { "中"、 "文字列"、 "$"}
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", "$" }
最初の（P4）= { "中間"}最初の（P5）= {}事前に選択され（P4）=事前に選択され（P5）=空（P4）」は、真のフォロー（中央）= { "string" を= FALSE空（P5）を= $」}（P4）=最初の（P4）= {SELECT "中間の"（P5）を選択}まず（P5）+フォロー（真ん中）= = { "文字列"、 "$"}
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) = { "$" }
まず、（P6）= { "文字列"}まず（P7）= {}事前に選択された（P6）=事前に選択された（P7）=空（P6）が偽空（P7）を= trueをフォロー（終了）=を= { "$"}を選択（P6）が最初に（P6）= { "文字列"} =（P7）を選択するには、最初の（P7）+フォロー（エンド）= = { "$"}
The intersection of Select(P2) and Select(P3) is not empty; hence, the grammar is not deterministic, and the type definition is not valid.
セレクト（P2）と選択（P3）の交差は空ではありません。したがって、文法は確定的ではなく、型定義は有効ではありません。
Now consider the following type definition:
ここで、次の型定義を考えてみます。
SEQUENCE { beginning [GROUP] List, middleAndEnd [GROUP] SEQUENCE { middle UTF8String, end [GROUP] List } OPTIONAL }
SEQUENCE {[GROUP]一覧、middleAndEnd [GROUP] SEQUENCE {中間UTF8Stringを、エンド[GROUP]一覧を開始} 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", "$" }
最初の（P2）= { "文字列"}最初の（P3）= {}事前に選択された（P2）=事前に選択された（P3）=空（P2）が偽空（P3）を= "真のフォロー（開始）= { "中央の"= $」}（P2）=最初の（P2）= {SELECT "の文字列を"（P3）を選択}まず（P3）+フォロー（開始）を= = { "中"、 "$"}
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) = { "$" }
まず、（P4）= { "中"}まず（P5）= {}は事前に選択された（P4）=事前に選択された（P5）=空（P4）が偽空（P5）を= trueをフォロー（middleAndEnd）=を= { "$"}を選択（P4）=最初の（P4）= { "中間"}（P5）を選択=最初の（P5）+フォロー（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) = { "$" }
まず（P7）= { "文字列"}まず（P8）= {}事前に選択された（P7）=事前に選択された（P8）=空（P7）が偽空（P8）を= trueをフォロー（終了）=を= { "$"}を選択（P7）が最初に（P7）= { "文字列"} =（P8）を選択するには、最初の（P8）+フォロー（エンド）= = { "$"}
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.
選択（P4）と選択（P5）と選択（P7）と選択（P8）の交差点の交差点であるように選択（P2）と選択（P3）の交差は空です。したがって、文法は確定的で、型定義が有効です。
A.7. Example 7
A.7。実施例7
Consider the following type definition:
次の型の定義を考えてみましょう：
SEQUENCE SIZE(1..MAX) OF one [GROUP] SEQUENCE { two INTEGER OPTIONAL }
1 [GROUP] SEQUENCE {2つの整数OPTIONAL}のシーケンスSIZE（1..MAX）
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') = { "$" }
まず、（P2）= { "2"}まず（P3）= {}事前に選択された（P2）=事前に選択された（P3）が偽空（P2）=空（P3）が真のフォロー（S '）を= = = { "$"}選択（P2）は=最初の（P2）+フォロー（S '）= { "2" は、 "$"}選択（P3）は=最初の（P3）+フォロー（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", "$" }
最初（P5）= { "2"}最初の（P6）= {}事前に選択され（P5）=事前に選択された（P6）=空（P5）は偽空（P6）を= TRUEフォロー（2）= { "2" を、 "= $」}（P5）を選択まず（P5）を= = { "2"}（P6）を選択するには、最初の（P6）+フォロー（2）= {= "2"、 "$" を}
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.
選択（P2）と選択（P3）の交差は空ではなく、選択（P5）と選択（P6）の交差は空ではありません。したがって、文法は確定的ではなく、型定義は有効ではありません。タイプの値の符号化は、コンポーネントタイプの空のインスタンスの不確定数を含んでいます。
A.8. Example 8
A.8。実施例8
Consider the following type definition:
次の型の定義を考えてみましょう：
SEQUENCE OF list [GROUP] SEQUENCE SIZE(1..MAX) OF number INTEGER
数の整数リストのシーケンス[GROUP] SEQUENCEサイズ（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) = { "$" }
最初の（P1）= { "数"}最初の（P2）= {}事前に選択され（P1）=事前に選択された（P2）=空（P1）が偽空（P2）を= trueをフォロー（S）=を= { "$"}を選択（P1）=最初の（P1）= { "数"}を選択し（P2）=最初の（P2）+フォロー（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", "$" }
最初の（P4）= { "数"}最初の（P5）= {}事前に選択され（P4）=事前に選択され（P5）=空（P4）が偽空（P5）は、真のフォロー（リスト '）= { "番号" = = "$"}（P4）を選択しますが、まず（P4）を= = { "数"}（P5）を選択するには、最初の（P5）+フォロー（リスト '）= = { "数"、 "$"}
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.
セレクト（P4）と選択（P5）の交点は空ではありません。したがって、文法は確定的ではなく、型定義は有効ではありません。タイプは、リストのリストを記述し、それは外側のリストの開始と終了場所を決定するためにデコーダのために不可能です。
A.9. Example 9
A.9。実施例9
Consider the following type definition:
次の型の定義を考えてみましょう：
SEQUENCE OF item [GROUP] SEQUENCE { before [GROUP] OneAndTwo, core UTF8String, after [GROUP] OneAndTwo OPTIONAL }
項目[GROUP] SEQUENCE OF SEQUENCE {以前[GROUP] OneAndTwo、コアUTF8Stringを、[GROUP]はOPTIONAL OneAndTwo後}
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) = { "$" }
最初の（P1）= { "非コア"}最初の（P2）= {}は事前に選択され（P1）=事前に選択された（P2）=空（P1）が偽空（P2）を= TRUEフォロー（S）= { "$" を= }選択（P1）まず（P1）= { "非コア"}選択（P2）=最初の（P2）+フォロー（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", "$" }
最初（P7）= { "非コア"}最初（P8）= {}事前に選択された（P7）=事前に選択された（P8）=空（P7）が偽空（P8）を= TRUEフォロー（後）= {「非を=コア」、 "$"}を選択（P7）が最初に（P7）を= = { "非コア"}（P8）を選択するには、最初の（P8）+フォロー（後）= {= "非コア"、 "$" を}
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.
セレクト（P7）と選択（P8）の交点は空ではありません。したがって、文法は確定的ではなく、型定義は有効ではありません。 1つの項目の終了と次の開始の間の曖昧さがあります。エンコーディングに先読みすることなく、<非コア>要素には、前後の<コア>要素に属するか否かを決定することは不可能です。
A.10. Example 10
A.10。実施例10
Consider the following type definition:
次の型の定義を考えてみましょう：
CHOICE { one [GROUP] List, two [GROUP] SEQUENCE { three [ATTRIBUTE] UTF8String, four [GROUP] List } }
CHOICE {1 [GROUP]一覧、2 [GROUP] SEQUENCE {3 [ATTRIBUTE] UTF8Stringを4 [GROUP]一覧}}
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) = { }
最初の（P1）= { "文字列"}最初の（P2）= { "文字列"}事前に選択され（P1）=空（P2）が偽事前に選択された（P2）を= =空（P1）は、真のフォロー（S）= {「$を=文字列 "}選択（P1）まず（P1）+フォロー（S）=を{= ""、 "$"}選択（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) = { "$" }
まず、（P3）= { "文字列"}まず（P4）= {}事前に選択された（P3）=事前に選択された（P4）=空（P3）が偽空（P4）を= trueをフォロー（1）=を= { "$"}を選択（P3）はまず（P3）= { "string" を} =（P4）を選択=最初の（P4）+フォロー（1）= { "$"}
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) = { "$" }
まず（P7）= { "文字列"}まず（P8）= {}事前に選択された（P7）=事前に選択された（P8）=空（P7）が偽空（P8）を= trueをフォロー（4）=を= { "$"}を選択（P7）（P8）を選択するには、最初の（P7）= { "の文字列を"} = =最初の（P8）+フォロー（4）= { "$"}
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.
選択（P3）と選択（P4）と選択（P7）と選択（P8）の交差点の交差点であるように選択（P1）と選択（P2）との交点は、空です。したがって、文法は確定的で、型定義が有効です。 CHOICEの両方の選択肢が<文字列>要素で始めることができますが、RXERデコーダは、「2」の代替を選択するか、無視するかどうかを決定するために、「3」の属性の存在を使用します。
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). }
【の特異挿入] CHOICE {1 [GROUP]リスト、...、2 [GROUP] SEQUENCE {3 [ATTRIBUTE] UTF8Stringを4 [GROUP]一覧} - ExtensionAdditionAlternative（E1）。 - 拡張挿入点は、ここで（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) = { "*" }
最初の（P1）= { "文字列"}最初の（P10）= { "文字列"}最初の（P11）= { "*"}事前に選択され（P1）=事前に選択され（P10）=事前に選択され（P11）偽空（P10）を= =空（P11）が偽空（P1）を=には、真のフォロー（S）= { "$"}セレクト（P1）=最初の（P1）+フォロー（S）= { "文字列"、 "$"}選択（P10を= ）=最初の（P10）= { "文字列"}（P11を選択）が最初に（P11）を= = { "*"}
Preselected(P10) evaluates to false because Preselected(P10) is evaluated on the base grammar, wherein P10 is rewritten as:
予め選択された（P10）は、P10は次のように書き換えられる前記ベース文法、上で評価されているため、予め選択され（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.
選択（P1）と選択（P10）との交点が空ではありません。したがって、文法は確定的ではなく、型定義は有効ではありません。定義の元、拡張されていないバージョンを使用してRXERデコーダは「3」属性が「1」の代替と拡張子の間を選択することを知ることはできません。
Appendix B. Insertion Encoding Instruction Examples
付録B.挿入エンコード命令の例
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.
この付録では、グループ符号化命令の使用から生じる拡張の曖昧さを除去するために挿入エンコード命令の使用を示す例を含んでいます。
B.1. Example 1
B.1。例1
Consider the following type definition:
次の型の定義を考えてみましょう：
SEQUENCE { one [GROUP] SEQUENCE { two UTF8String, ... -- Extension insertion point (I1). }, three INTEGER OPTIONAL, ... -- Extension insertion point (I2). }
SEQUENCE {1 [GROUP] SEQUENCE {2つのUTF8Stringを... - 拡張挿入ポイント（I1）。 }三のINTEGER OPTIONAL、... - 拡張挿入ポイント（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", "*", "$" }
最初の（P4）= { "*"}最初の（P5）= {}事前に選択され（P4）=事前に選択され（P5）=空（P4）が偽空（P5）を= = TRUEフォロー（I1）= { "3"、 " *」、 "$ *"}選択（P4）は、まず（P4）= {= ""}選択（P5）を=最初の（P5）+フォロー（I1）= { "3"、 "*"、 "$"}
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) = { "*", "$" }
最初（P6）= { "三"}最初の（P7）= {}事前に選択された（P6）=事前に選択された（P7）=空（P6）が偽空（P7）を= TRUEフォローを（3つ）= { "*"、 "= $」}（P6）を選択は、まず（P6）を= = { "3"}（P7）を選択するには、最初の（P7）+フォロー（3）= {= "*"、 "$" を}
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) = { "$" }
まず、（P8）= { "*"}まず（P9）= {}事前に選択された（P8）=事前に選択された（P9）=空（P8）が偽空（P9）を= TRUEフォロー（I2）= { "$" を} =を選択（P8）（P9）を選択するには、最初の（P8）= { "*"} = =最初の（P9）+フォロー（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.
セレクト（P4）と選択（P5）の交点は空ではありません。したがって、文法は確定的ではなく、型定義は有効ではありません。 RXERデコーダは、<2>要素の直後に認識されていない要素に遭遇した場合、それは、拡張挿入点I1又はI2に関連付けするかどうかを知ることができません。
The non-determinism can be resolved with either a NO-INSERTIONS or HOLLOW-INSERTIONS encoding instruction. Consider this revised type definition:
非決定性は、NO-挿入または中空挿入エンコード命令のいずれかで解決することができます。この改訂された型定義を考えてみましょう：
SEQUENCE { one [GROUP] [HOLLOW-INSERTIONS] SEQUENCE { two UTF8String, ... -- Extension insertion point (I1). }, three INTEGER OPTIONAL, ... -- Extension insertion point (I2). }
SEQUENCE {1 [GROUP] [中空挿入] SEQUENCE {2つのUTF8Stringを... - 拡張挿入ポイント（I1）。 }三のINTEGER OPTIONAL、... - 拡張挿入ポイント（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生産はもはや発生せず、及び選択（P4）と選択（P5）との間の競合がもはや存在しています。 P6、P7、P8、およびP9のための選択設定は変更されません。デコーダは、現在認識されていない要素は、拡張挿入点I2に関連付けられると仮定する。まだ拡張挿入点のいずれかで認識されていない属性を関連付けることが自由です。 NO-挿入エンコード命令が使用されていた場合、認識されていない属性は、拡張挿入点I2に関連付けすることができます。
The non-determinism could also be resolved by adding a NO-INSERTIONS or HOLLOW-INSERTIONS encoding instruction to the outer SEQUENCE:
非決定論は、外側の配列にNO-挿入または中空挿入エンコード命令を追加することによって解決することができます。
[HOLLOW-INSERTIONS] SEQUENCE { one [GROUP] SEQUENCE { two UTF8String, ... -- Extension insertion point (I1). }, three INTEGER OPTIONAL, ... -- Extension insertion point (I2). }
[中空挿入] SEQUENCE {1 [GROUP] SEQUENCE {2つのUTF8Stringを... - 拡張挿入ポイント（I1）。 }三のINTEGER OPTIONAL、... - 拡張挿入ポイント（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", "$" }
最初の（P4）= { "*"}最初の（P5）= {}事前に選択され（P4）=事前に選択され（P5）=空（P4）が偽空（P5）を= = TRUEフォロー（I1）= { "3"、 " $ *」}選択（P4）は、まず（P4）= {= ""}選択（P5）を=最初の（P5）+フォロー（I1）= { "3"、 "$"}
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) = { "$" }
まず、（P6）= { "3"}まず（P7）= {}事前に選択された（P6）=事前に選択された（P7）=空（P6）が偽空（P7）を= TRUEフォロー（3）= { "$"}選択= （P6）、（P7）を選択するには、最初の（P6）= { "三"} = =最初の（P7）+フォロー（3）= { "$"}
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.
選択（P6）と選択（P7）との交点であるように選択（P4）と選択（P5）の交差点は、空です。したがって、文法は確定的で、型定義が有効です。デコーダは、現在認識されていない要素は、拡張挿入点I1に関連付けられると仮定する。まだ拡張挿入点のいずれかで認識されていない属性を関連付けることが自由です。 NO-挿入エンコード命令が使用されていた場合、認識されていない属性は、拡張挿入点I1に関連付けすることができます。
B.2. Example 2
B.2。例2
Consider the following type definition:
次の型の定義を考えてみましょう：
SEQUENCE { one [GROUP] CHOICE { two UTF8String, ... -- Extension insertion point (I1). } OPTIONAL }
SEQUENCE {1 [GROUP] CHOICE {2つのUTF8Stringを... - 拡張挿入ポイント（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) = { "$" }
最初の（P2）= { "2"}最初の（P3）= { "*"}最初の（P4）= {}事前に選択された（P2）=事前に選択された（P3）=事前に選択され（P4）が偽空（P2）が偽空の==します（P3）=空（P4）が真のフォロー（1）= { "$" は}（P2）を選択=最初の（P2）を= = { "2"}は、（P3）を選択するには、最初の（P3）+フォロー（一つ）= = { "*"、 "$"}選択（P4）は、まず（P4）+フォロー（1）= { "$"} =
First(P6) = { "*" } First(P7) = { } Preselected(P6) = Preselected(P7) = Empty(P6) = false Empty(P7) = true
最初（P6）= { "*"}最初の（P7）= {}事前に選択された（P6）=事前に選択された（P7）=空（P6）が偽空（P7）を= TRUE =
Follow(I1) = { "$" } Select(P6) = First(P6) = { "*" } Select(P7) = First(P7) + Follow(I1) = { "$" }
（I1）をフォロー= { "$"}（P6）を選択するには、最初の（P6）を= = { "*"}（P7）を選択=最初の（P7）+フォロー（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.
セレクト（P3）と選択（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 }
SEQUENCE {1 [GROUP] [多形-挿入] CHOICE {2つのUTF8Stringを... - 拡張挿入ポイント（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) = { "$" }
最初の（P2）= { "2"}最初の（P8）= { "*"}最初の（P4）= {}事前に選択された（P2）=事前に選択された事前に選択され（P4）が偽空（P2）を= =（P8）=空（ P8）偽（空P4を=）が真のフォロー（1）を= = { "$"}は（P2を選択します）まず（P2）を= = { "2"}（P8を選択します）まず、（P8）を= = { "*"}まず、（P4）+フォロー（1）を=（P4）を選択= { "$"}
First(P6) = { "*" } First(P7) = { } Preselected(P6) = Preselected(P7) = Empty(P6) = false
最初（P6）= { "*"}最初の（P7）= {}事前に選択された（P6）=事前に選択された（P7）=空（P6）が偽=
Empty(P7) = true Follow(I1) = { "$" } Select(P6) = First(P6) = { "*" } Select(P7) = First(P7) + Follow(I1) = { "$" }
空の（P7）真フォロー（I1）を= = { "$" は}（P6）を選択するには、最初の（P6）を= = { "*"}（P7）を選択するには、最初の（P7）+フォロー（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.
選択（P2）と選択（P4）、選択（P8）と選択（P4）の交差点の交差点、及び選択の交点（P6がそのまま選択（P2）と選択（P8）の交差点は、空であります）と選択（P7）。したがって、文法は確定的で、型定義が有効です。デコーダは、今では少なくとも一つの認識されていない要素、および不在さもなければを見れば「1」の代替が存在すると仮定する。
B.3. Example 3
B.3。例3
Consider the following type definition:
次の型の定義を考えてみましょう：
SEQUENCE { one [GROUP] CHOICE { two UTF8String, ... -- Extension insertion point (I1). }, three [GROUP] CHOICE { four UTF8String, ... -- Extension insertion point (I2). } }
SEQUENCE {1 [GROUP] CHOICE {2つのUTF8Stringを... - 拡張挿入ポイント（I1）。 }三[GROUP] CHOICE {4つのUTF8Stringを... - 拡張挿入ポイント（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
最初の（P2）= { "2"}最初の（P3）= { "*"}事前に選択された（P2）=事前に選択された（P3）=空（P2）が偽空（P3）を= TRUE =
Follow(one) = { "four", "*", "$" } Select(P2) = First(P2) = { "two" } Select(P3) = First(P3) + Follow(one) = { "*", "four", "$" }
（1）= { "4"、 "*"、 "$"}フォローを選択し（P2）ファースト（P2）を= = { "2"}（P3）を選択するには、最初の（P3）+フォロー（1）を= = { " *」、 "4"、 "$"}
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", "*", "$" }
最初（P5）= { "*"}最初の（P6）= {}事前に選択され（P5）=事前に選択された（P6）=空（P5）は偽空（P6）を= = TRUEフォロー（I1）= { "4"、 " *」、 "$ *"}選択（P5）まず（P5）= {= ""}選択（P6）を=最初の（P6）+フォロー（I1）= { "4"、 "*"、 "$"}
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) = { "*", "$" }
まず（P7）= { "4"}まず（P8）= { "*"}事前に選択された（P7）=事前に選択された（P8）=空（P7）が偽空（P8）を= TRUEフォロー（3）= {「$を= "}（P7）を選択するには、最初の（P7）を= = { "4"}（P8）を選択するには、最初の（P8）+フォロー（3）= {= "*"、 "$" を}
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) = { "$" }
まず（P10）= { "*"}まず（P11）= {}事前に選択された（P10）=事前に選択された（P11）=空（P10）が偽空（P11）を= trueをフォロー（I2）=を= { "$"}を選択（P10）=最初の（P10）= { "*"}を選択（P11）=最初の（P11）+フォロー（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.
セレクト（P5）と選択（P6）の交点は空ではありません。したがって、文法は確定的ではなく、型定義は有効ではありません。最初の子要素が認識されない要素である場合、デコーダは、拡張挿入点I1に関連付けするかどうかを決定することができない、または「1」の成分が要素を生成しない未知の拡張子を持っていると仮定して拡張挿入点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:
非決定性は、特異-挿入または均一挿入エンコード命令のいずれかで解決することができます。 SINGULAR-挿入エンコーディング命令を使用して、この改訂された型定義を考えてみましょう：
SEQUENCE { one [GROUP] [SINGULAR-INSERTIONS] CHOICE { two UTF8String, ... -- Extension insertion point (I1). }, three [GROUP] CHOICE { four UTF8String, ... -- Extension insertion point (I2). } }
SEQUENCE {1 [GROUP] [の特異挿入] CHOICE {2つのUTF8Stringを... - 拡張挿入ポイント（I1）。 }三[GROUP] CHOICE {4つのUTF8Stringを... - 拡張挿入ポイント（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) = { "*" }
最初の（P2）= { "2"}最初の（P12）= { "*"}事前に選択された（P2）=事前に選択され（P12）が偽空（P2）を= =空（P12）が偽フォロー（一つ）= = {「4 」、 "*"、 "$"}（P2）を選択するには、最初の（P2）を= = { "2"}（P12）を選択するには、最初の（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.
選択（P7）と選択（P8）と選択（P10）と選択（P11）の交差点の交差点であるように選択（P2）と選択（P12）の交差点は、空です。したがって、文法は確定的で、型定義が有効です。最初の子要素が認識されない要素である場合、デコーダは、現在、それが拡張挿入点I1に関連付けられていると仮定する。おそらく他の認識されていない要素を含め、以下のものは何でも、「3」のコンポーネントに属します。
Now consider the type definition using the UNIFORM-INSERTIONS encoding instruction instead:
今、代わりにUNIFORM-挿入エンコーディング命令を使用して型定義を考えてみます。
SEQUENCE { one [GROUP] [UNIFORM-INSERTIONS] CHOICE { two UTF8String, ... -- Extension insertion point (I1). }, three [GROUP] CHOICE { four UTF8String, ... -- Extension insertion point (I2). } }
SEQUENCE {1 [GROUP] [UNIFORM-挿入] CHOICE {2つのUTF8Stringを... - 拡張挿入ポイント（I1）。 }三[GROUP] CHOICE {4つのUTF8Stringを... - 拡張挿入ポイント（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" }
最初の（P2）= { "2"}最初の（P13）= { "*"}最初の（P14）= { "* 1"}事前に選択された（P2）=事前に選択され（P13）=事前に選択され（P14）は= FALSE空（P2 ）=空（P13）=空（P14）が偽フォロー（1）= { "4"、 "*"、 "$" は}（P2を選択=）=最初の（P2）= { "2"}（P13）を選択します=最初の（P13）= { "*"}選択（P14）は=最初の（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", "*", "$" }
最初の（P15）= { "* 1"}最初（P6）= {}事前に選択され（P15）=事前に選択された（P6）=空（P15）が偽空（P6）を= TRUEフォロー（I1）= { "4" を= "*"、 "$"}選択（P15）まず（P15）= { "* 1"}選択（P6）=最初の（P6）+フォロー（I1）= { "4"、 "*"、「$を= "}
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.
選択（P2）と選択（P14）との交点であるように選択（P2）と選択（P13）の交差点は、空である、選択（P13）と選択（P14）の交点と選択の交点（P15）そして、（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」のコンポーネントによって生成された要素の名前とは異なる名前を持つ要素を生成するために必要とされることです。特異挿入エンコード命令と、「三」コンポーネントへの拡張は、「1」のコンポーネントによって生成された要素の名前と同じである名前の要素を生成することが許可されています。
B.4. Example 4
B.4。例4
Consider the following type definition:
次の型の定義を考えてみましょう：
SEQUENCE OF one [GROUP] CHOICE { two UTF8String, ... -- Extension insertion point (I1). }
拡張挿入ポイント（I1） - オン[GROUP] CHOICE {2つのUTF8Stringを、...のシーケンス。 }
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) = { "$" }
最初の（P1）= { "2"、 "*"}最初の（P2）= {}事前に選択され（P1）=事前に選択された（P2）が偽空（P1）を= =空（P2）は、真のフォロー（S）=を{ "= $」}（P1）を選択するには、最初の（P1）+フォロー（S）を= = { "2"、 "*"、 "$"}（P2）を選択まず（P2）+フォロー（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", "$" }
最初（P3）= { "2"}最初の（P4）= { "*"}事前に選択された（P3）=事前に選択され（P4）=空（P3）が偽空（P4）を= TRUEフォロー（一つ）= = {「二" "*"、 "$"}（P3）を選択するには、最初の（P3）を= = { "2"}（P4）を選択するには、最初の（P4）+フォロー（1）を= = { "*"、 "2"、" $」}
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", "*", "$" }
最初（P6）= { "*"}最初の（P7）= {}事前に選択された（P6）=事前に選択された（P7）=空（P6）が偽空（P7）を= = TRUEフォロー（I1）= { "2"、 " *」、 "$ *"}選択（P6）まず（P6）= {= ""}選択（P7）を=最初の（P7）+フォロー（I1）= { "2"、 "*"、 "$"}
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.
選択（P3）と選択（P4）と選択（P6）と選択（P7）の交差点の交差点であるように選択（P1）と選択（P2）との交点は、空ではありません。したがって、文法は確定的ではなく、型定義は有効ではありません。デコーダは、行に2つの以上の認識されていない要素に遭遇した場合、これは一例又は「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:
非決定論は、UNIFORM-挿入エンコードの命令で解決することはできません。 UNIFORM-挿入エンコーディング命令を使用して、この改訂された型定義を考えてみましょう：
SEQUENCE OF one [GROUP] [UNIFORM-INSERTIONS] CHOICE { two UTF8String, ... -- Extension insertion point (I1). }
拡張挿入ポイント（I1） - オン[GROUP] [UNIFORM-挿入] CHOICE {2つのUTF8Stringを、...のシーケンス。 }
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) = { "$" }
最初の（P1）= { "2"、 "*"、 "* 1"}最初の（P2）= {}事前に選択され（P1）=事前に選択された（P2）=空（P1）が偽空（P2）を=（真のフォローを= S）= { "$"}選択（P1）がまず=（P1）= { "2"、 "*"、 "* 1"}（P2を選択）まず（P2）+フォロー（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" }
最初（P3）= { "2"}最初の（P8）= { "*"}最初の（P9）= { "* 1"}事前に選択された（P3）=事前に選択された（P8）=事前に選択され（P9）は= FALSE空（P3 ）=空（P8）=空（P9）が偽フォロー（1）= { "2"、 "*"、 "* 1"、 "$" は}（P3を選択=）=最初の（P3）= { "2" }選択（P8）が最初に（P8）= { "*"}を選択し（P9）を= =最初の（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", "$" }
最初の（P10）= { "* 1"}最初（P7）= {}事前に選択され（P10）=事前に選択された（P7）=空（P10）が偽空（P7）を= TRUEフォロー（I1）= { "二" を= "*"、 "* 1"、 "$"}選択（P10）は=最初の（P10）= { "* 1"}選択（P7）=最初の（P7）+フォロー（I1）= { "2"、 " *」、 "* 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.
選択（P1）と選択（P2）との交点は、現在空であるが、選択（P10）と選択（P7）の交差点ではありません。したがって、文法は確定的ではなく、型定義は有効ではありません。いかなる要素を生成しない拡張子から「1」の構成要素の不確定数の問題が解決されています。デコーダは、同じ名前を持つ一連の要素に遭遇した場合は、これは一例又は「1」の成分の複数のインスタンスを表しているかどうかを決定することができません。
The non-determinism can be fully resolved with a SINGULAR-INSERTIONS encoding instruction. Consider this revised type definition:
非決定論は完全にSINGULAR-挿入エンコードの命令で解決することができます。この改訂された型定義を考えてみましょう：
SEQUENCE OF one [GROUP] [SINGULAR-INSERTIONS] CHOICE { two UTF8String, ... -- Extension insertion point (I1). }
拡張挿入ポイント（I1） - オン〔GROUP〕〔の特異挿入] CHOICE {2つのUTF8Stringを、...のシーケンス。 }
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) = { "$" }
最初の（P1）= { "2"、 "*"}最初の（P2）= {}事前に選択され（P1）=事前に選択された（P2）=空（P1）が偽空（P2）を= TRUEフォロー（S）を= = { " $」}を選択（P1）が最初に（P1）を= = { "2"、 "* $ "}"}（P2）=最初の（P2）+フォロー（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) = { "*" }
最初（P3）= { "2"}最初の（P8）= { "*"}事前に選択された事前に選択された（P8）が偽空（P3）を= =（P3）=空（P8）が偽フォロー（1）= {「二つ= 」、 "*"、 "$"}（P3）を選択するには、最初の（P3）を= = { "2"}（P8）を選択するには、最初の（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.
選択（P3）と選択（P8）の交点であるように選択（P1）と選択（P2）との交点は、空です。したがって、文法は確定的で、型定義が有効です。デコーダは、現在「1」の成分の正確な数が復号されるように「1」コンポーネントにすべての拡張は、単一の要素を生成することを知っています。
Appendix C. Extension and Versioning Examples
付録C.拡張とバージョン管理の例
This appendix is non-normative.
この付録は非規範的です。
C.1. Valid Extensions for Insertion Encoding Instructions
C.1。挿入エンコーディング手順の有効な拡張機能
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 } }
[中空挿入] CHOICE {1つのBOOLEAN、...、2 [ATTRIBUTE] INTEGER、3 [GROUP] SEQUENCE {4 [ATTRIBUTE] UTF8Stringを、5 [ATTRIBUTE] INTEGER OPTIONAL、...}、6 [GROUP] CHOICE { 7 [ATTRIBUTE] BOOLEAN 8 [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.
第二の例は、特異-挿入エンコード命令を満たす拡張を示しています。
[SINGULAR-INSERTIONS] CHOICE { one BOOLEAN, ..., two INTEGER, three [GROUP] SEQUENCE { four [ATTRIBUTE] UTF8String, five INTEGER }, six [GROUP] CHOICE { seven BOOLEAN, eight INTEGER } }
【の特異挿入] CHOICE {1つのBOOLEAN、...、2つの整数、3 [GROUP] SEQUENCE {4 [ATTRIBUTE] UTF8Stringを、5つのINTEGER}、6 [GROUP] CHOICE {7つのBOOLEAN 8つの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」の属性を生成しますが、任意の数の属性は、特異-挿入エンコードの命令によって許可されています。
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 } }
[均一挿入] CHOICE {1つのBOOLEAN、...、2つの整数、3 [GROUP] SEQUENCEサイズ4つの整数の（1..MAX）OPTIONAL、7つのINTEGERをUTF8STRING、5 [GROUP] SEQUENCE {6 [ATTRIBUTE]}、 8 [GROUP] CHOICE {9つのBOOLEAN、10〔GROUP〕11 INTEGERのシーケンスSIZE（1..MAX）}}
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」の属性を生成することがありますが、任意の数の属性は、UNIFORM-挿入エンコードの命令によって許可されています。
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」の成分は、単一の<9>要素または1つ以上の<11>要素を生成しますか。どちらの場合は、拡張の任意のエンコーディングに同じ名前を有する1つ以上の要素が存在しなければならないことを要件を満たします。
C.2. Versioning Example
C.2。バージョン管理の例
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
電話：+61 3 9896 7830ファックス：+61 3 9896 7801 Eメール：steven.legg@eb2bcom.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 Editor機能のための基金は現在、インターネット協会によって提供されます。