RFC4911 日本語訳
4911 Encoding Instructions for the Robust XML Encoding Rules (RXER).S. Legg. July 2007. (Format: TXT=178977 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group S. Legg Request for Comments: 4911 eB2Bcom Category: Experimental July 2007
Leggがコメントのために要求するワーキンググループS.をネットワークでつないでください: 4911年のeB2Bcomカテゴリ: 実験的な2007年7月
Encoding Instructions for the
Robust XML Encoding Rules (RXER)
強健なXML符号化規則のための指示をコード化します。(RXER)
Status of This Memo
このメモの状態
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 それはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(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値がRobust XML Encoding Rules(RXER)によってどうコード化されるかを変更する抽象的なSyntax Notation Oneで中古(ASN.1)の仕様とCanonical Robust XML Encoding Rulesが(CRXER)であったなら例えば子供要素としてというよりむしろ拡張マークアップ言語(XML)属性としてASN.1価値のコンポーネントをコード化するためにそうするかもしれないコード化指示を定義します。 また、指示をコード化するこれらの或るものはASN.1仕様がどう抽象的なSyntax Notation X(ASN.X)仕様に翻訳されるかに影響します。 他のXMLとの参照定義にASN.1仕様を許容する指示をコード化して、また、スキーマ言語は定義されます。
Legg Experimental [Page 1] RFC 4911 Encoding Instructions for RXER July 2007
2007年7月にRXERのために指示をコード化するLeggの実験的な[1ページ]RFC4911
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
1. 序論…3 2. コンベンション…3 3. 定義…4 4. 指示をコード化するRXERのための記法…4 5. 指示をコード化するコンポーネント…6 6. 指示をコード化する参照…8 7. コンポーネントの名前を広げます…10 8. 指示をコード化する属性…11 9. 指示をコード化する属性審判…12 10. 指示をコード化するコンポーネント審判…13 11. 指示をコード化する要素審判…16 12. 指示をコード化するリスト…17 13. 指示をコード化する名前…19 14. 要素としての指示をコード化する審判…19 15. タイプとしての指示をコード化する審判…20 16. 指示をコード化する図式アイデンティティ…22 17. 指示をコード化する簡単な内容…22 18. 指示をコード化する目標名前空間…23 19. バージョンとしての指示をコード化するタイプ…24 20. 指示をコード化するタイプ審判…25 21. 指示をコード化する組合…26 22. 指示をコード化する値…27 23. 指示をコード化する挿入…29 24. 指示をコード化するバージョンインディケータ…32 25. 指示をコード化するグループ…34 25.1. 明白なEncodings…36 25.1.1. 文法工事…37 25.1.2. ユニークなコンポーネント属性…47 25.1.3. 決定論的な文法…52 25.1.4. 未知の拡大における属性…54 26. セキュリティ問題…56 27. 参照…56 27.1. 標準の参照…56 27.2. 有益な参照…指示の例をコード化して、57付録A.は分類されます…58 指示の例をコード化する付録B.挿入…74 付録C.拡大とVersioningの例…87
Legg Experimental [Page 2] RFC 4911 Encoding Instructions for RXER July 2007
2007年7月にRXERのために指示をコード化するLeggの実験的な[2ページ]RFC4911
1. Introduction
1. 序論
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)[XML10]属性としてASN.1価値のコンポーネントをコード化するためにRobust XML Encoding Rules(RXER)[RXER]とCanonical Robust XML Encoding Rules(CRXER)[RXER]によってどうコード化されるかを変更するのに抽象的なSyntax Notation One(ASN.1)[X.680]仕様で使用されるかもしれない指示[X.680-1]をコード化しながら、定義します。 また、指示をコード化するこれらの或るものはASN.1仕様がどう抽象的なSyntax Notation 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 Schema[XSD1]タイプ、要素、および属性についての言及、パターンと要素というRELAX NG[RNG]、およびXMLドキュメント型定義(DTD)[XML10]要素型はサポートされます。
In most cases, the effect of an encoding instruction is only briefly mentioned in this document. The precise effects of these encoding instructions are described fully in the specifications for RXER [RXER] and ASN.X [ASN.X], at the points where they apply.
多くの場合、コード化指示の効果は簡潔に本書では言及されるだけです。 これらが指示をコード化するという正確な効果はRXER[RXER]とASN.X[ASN.X]のための仕様で完全に説明されます、それらが適用するポイントで。
2. Conventions
2. コンベンション
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「」、このドキュメントの「推薦され」て「5月」はBCP14RFC2119[BCP14]で説明されるように解釈されることになっているべきであるものとします。 「任意である」というキーワードはASN.1意味と共に排他的に使用されます。
Throughout this document "type" shall be taken to mean an ASN.1 type, and "value" shall be taken to mean an ASN.1 abstract value, unless qualified otherwise.
このドキュメント中では、ASN.1がタイプすることを意味するために「タイプ」を取るものとします、そして、ASNの.1の抽象的な価値を意味するために「値」を取るものとします、別の方法で資格がない場合。
A reference to an ASN.1 production [X.680] (e.g., Type, NamedType) is a reference to text in an ASN.1 specification corresponding to that production. Throughout this document, "component" is synonymous with NamedType.
ASN.1生産[X.680](例えば、Type、NamedType)の参照はその生産に対応するASN.1仕様によるテキストの参照です。 このドキュメント中では、「コンポーネント」はNamedTypeと同義です。
This document uses the namespace prefix "xsi:" to stand for the namespace name [XMLNS10] "http://www.w3.org/2001/XMLSchema-instance".
名前空間が前に置くこのドキュメント用途は「以下をxsiします」。 名前空間を表すには、[XMLNS10]を" http://www.w3.org/2001/XMLSchema-instance "と命名してください。
Example ASN.1 definitions in this document are assumed to be defined in an ASN.1 module with a TagDefault of "AUTOMATIC TAGS" and an EncodingReferenceDefault [X.680-1] of "RXER INSTRUCTIONS".
「自動タグ」のTagDefaultと「RXER指示」のEncodingReferenceDefault[X.680-1]と共にASN.1モジュールで例のASN.1定義が定義されると本書では思われます。
Legg Experimental [Page 3] RFC 4911 Encoding Instructions for RXER July 2007
2007年7月にRXERのために指示をコード化するLeggの実験的な[3ページ]RFC4911
3. Definitions
3. 定義
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.
傍らに: タグ付けをされたタイプは前に置かれたタイプの特別なケースです。
4. Notation for RXER Encoding Instructions
4. 指示をコード化するRXERのための記法
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.
Robust XML Encoding規則を特定するコード化参照は文字通りRXERです。 指示をコード化するRXERは等しくRXERとCRXER encodingsの両方に適用します。
The specific notation for an encoding instruction for a specific set of encoding rules is left to the specification of those encoding rules. Consequently, this companion document to the RXER specification [RXER] defines the notation for RXER encoding instructions. Specifically, it elaborates the EncodingInstruction and EncodingInstructionAssignmentList placeholder productions of the ASN.1 basic notation.
特定の符号化規則のためのコード化指示のための特定の記法はそれらの符号化規則の仕様に残されます。 その結果、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の基本的な記法のコンベンションを使用して:
Legg Experimental [Page 4] RFC 4911 Encoding Instructions for RXER July 2007
2007年7月にRXERのために指示をコード化するLeggの実験的な[4ページ]RFC4911
EncodingInstruction ::=
AttributeInstruction |
AttributeRefInstruction |
ComponentRefInstruction |
ElementRefInstruction |
GroupInstruction |
InsertionsInstruction |
ListInstruction |
NameInstruction |
RefAsElementInstruction |
RefAsTypeInstruction |
SimpleContentInstruction |
TypeAsVersionInstruction |
TypeRefInstruction |
UnionInstruction |
ValuesInstruction |
VersionIndicatorInstruction
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 ?
EncodingInstructionAssignmentList:、:= SchemaIdentityInstruction? TargetNamespaceInstruction? TopLevelComponents?
TopLevelComponents ::= TopLevelComponent TopLevelComponents ?
TopLevelComponents:、:= TopLevelComponent TopLevelComponents?
TopLevelComponent ::= "COMPONENT" NamedType
TopLevelComponent:、:= 「コンポーネント」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(同等に、aはコンポーネントを先端で平らにする)である、それである場合にだけ、TopLevelComponentのNamedTypeはそうです。 TopLevelComponentのNamedTypeのTypeの中で入れ子にされた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 SHALLには、異なった識別子があります。
Legg Experimental [Page 5] RFC 4911 Encoding Instructions for RXER July 2007
2007年7月にRXERのために指示をコード化するLeggの実験的な[5ページ]RFC4911
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
NCNameValue:、:= 値
AnyURIValue ::= Value
AnyURIValue:、:= 値
QNameValue ::= Value
QNameValue:、:= 値
NameValue ::= Value
NameValue:、:= 値
The Value production is defined by the ASN.1 basic notation.
Value生産はASN.1の基本的な記法で定義されます。
The governing type for the Value in an NCNameValue is the NCName type from the AdditionalBasicDefinitions module [RXER].
NCNameValueのValueのための支配的なタイプはAdditionalBasicDefinitionsモジュール[RXER]からのNCNameタイプです。
The governing type for the Value in an AnyURIValue is the AnyURI type from the AdditionalBasicDefinitions module.
AnyURIValueのValueのための支配的なタイプはAdditionalBasicDefinitionsモジュールからのAnyURIタイプです。
The governing type for the Value in a QNameValue is the QName type from the AdditionalBasicDefinitions module.
QNameValueのValueのための支配的なタイプはAdditionalBasicDefinitionsモジュールからのQNameタイプです。
The governing type for the Value in a NameValue is the Name type from the AdditionalBasicDefinitions module.
NameValueのValueのための支配的なタイプはAdditionalBasicDefinitionsモジュールからのNameタイプです。
The Value in an NCNameValue, AnyURIValue, QNameValue, or NameValue SHALL NOT be a DummyReference [X.683] and SHALL NOT textually contain a nested DummyReference.
Value、NCNameValue、AnyURIValue、QNameValue、またはNameValue SHALLでは、DummyReference[X.683]とSHALL NOTが原文でなかったなら、入れ子にされた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.
傍らに: したがって、コード化指示によって何らかの方法でparameterizedされることは許可されていません。 ASN.Xのための将来の仕様が明らかにparameterized定義を表して、外に広がることの代わりにparameterized参照が現在の仕様のように参照をparameterizedしたなら、この制限は重要になるでしょう。 完全に指定されたというわけではないコード化指示を含んでいるなら、直接parameterized定義をASN.Xに翻訳できないでしょうに。
5. Component Encoding Instructions
5. 指示をコード化するコンポーネント
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コード化では、指示は指示をコード化するコンポーネントとして分類されます。 コンポーネントコード化指示がATTRIBUTEと、ATTRIBUTE-REFと、COMPONENT-REFと、GROUPと、ELEMENT-REFと、NAMEと、REF-AS-ELEMENTと、SIMPLE-CONTENTと、TYPE-AS-バージョンと、指示をコード化するバージョン-INDICATORである、(記法がAttributeInstruction、AttributeRefInstruction、ComponentRefInstruction、GroupInstructionによってそれぞれ説明される
Legg Experimental [Page 6] RFC 4911 Encoding Instructions for RXER July 2007
2007年7月にRXERのために指示をコード化するLeggの実験的な[6ページ]RFC4911
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:
指示SHALLをコード化するコンポーネントのためのEncodingPrefixedTypeのTypeは以下の通りです。
(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)への(1)のTypeのBuiltinTypeのPrefixedTypeのEncodingPrefixedTypeのType。
(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)への(1)のTypeのBuiltinTypeのPrefixedTypeのTaggedTypeのType。
(4) the Type in a ConstrainedType (excluding a TypeWithConstraint) in
a Type that is one of (1) to (4).
(4) 1歳である(4)への(1)のTypeのConstrainedType(TypeWithConstraintを除いた)のType。
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の中で原文であることを強制することです。 TypeがEncodingPrefixedTypeに属すとき、ケース(2)だけが最初の繰り返しのときに本当である場合があります。 その後の繰り返しのときに(4) 缶への(1)でしかしながら、いくらか、本当であってください。
Case (4) is not permitted when the encoding instruction is the ATTRIBUTE-REF, COMPONENT-REF, ELEMENT-REF, or REF-AS-ELEMENT encoding instruction.
コード化指示が指示をコード化するATTRIBUTE-REF、COMPONENT-REF、ELEMENT-REF、またはREF-AS-ELEMENTであるときに、ケース(4)は受入れられません。
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.
AはNamedType SHALL NOTを先端で平らにします。指示をコード化するATTRIBUTE-REF、COMPONENT-REF、GROUP、ELEMENT-REF、REF-AS-ELEMENT、またはSIMPLE-CONTENTを条件として、いてください。
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 SHALL、同じ種類(例えば、NamedTypeが指示をコード化する2NAMEを受けることがあることは許可されていないa)の指示をコード化する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-バージョンは互いに排他的です。 指示をコード化するNAME、ATTRIBUTE-REF、COMPONENT-REF、ELEMENT-REF、およびREF-AS-ELEMENTは互いに排他的です。 2を受けることがあるか互いに排他的な指示をさらにコード化していないNamedType SHALL。
Legg Experimental [Page 7] RFC 4911 Encoding Instructions for RXER July 2007
2007年7月にRXERのために指示をコード化するLeggの実験的な[7ページ]RFC4911
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]SHALL NOT、使用されて、指示をコード化するATTRIBUTE-REF、COMPONENT-REF、ELEMENT-REFまたは受けることがあるNamedTypeからREF-AS-ELEMENTまでTypeを選択してください。 他のコンポーネントコード化指示は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.
定義(属性コンポーネント): 属性コンポーネントは指示をコード化するATTRIBUTEかATTRIBUTE-REFを受けることがあるNamedTypeであるかCOMPONENT-REFコード化指示を条件としたその参照が指示をコード化するATTRIBUTEを受けることがあるトップレベル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.
定義(要素成分): 要素成分は、指示をコード化するATTRIBUTEを受けることがないNamedType、ATTRIBUTE-REF、GROUP、またはSIMPLE-CONTENTであり、COMPONENT-REFコード化指示を条件としたどんなその参照も指示をコード化するATTRIBUTEを受けることがあるトップレベルNamedTypeではありません。
Aside: A NamedType subject to a GROUP or SIMPLE-CONTENT encoding
instruction is neither an attribute component nor an element
component.
傍らに: 指示をコード化するGROUPかSIMPLE-CONTENTを条件としたNamedTypeは属性コンポーネントでなくてまた要素成分ではありません。
6. Reference Encoding Instructions
6. 指示をコード化する参照
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コード化では、指示は指示をコード化する参照として分類されます。 参照コード化指示は、指示(記法はAttributeRefInstruction、ComponentRefInstruction、ElementRefInstruction、RefAsElementInstruction、RefAsTypeInstruction、およびTypeRefInstructionによってそれぞれ説明される)をコード化するATTRIBUTE-REFと、COMPONENT-REFと、ELEMENT-REFと、REF-AS-ELEMENTと、REF-AS-TYPEと、TYPE-REFです。 指示(COMPONENT-REFを除いた)をコード化するこれらで、ASN.1仕様は他のXMLスキーマ言語で書かれた仕様にタイプ、要素、および属性の定義を取り入れることができます、AdditionalBasicDefinitionsモジュール[RXER](ELEMENT-REF、REF-AS-ELEMENT、REF-AS-TYPE、およびTYPE-REFのための)かUTF8Stringタイプ(ATTRIBUTE-REFのための)からMarkup ASN.1タイプの値に現れるかもしれないマークアップにおける暗示している規制で。 XML Schema[XSD1]タイプ、要素、および属性についての言及、パターンと要素というRELAX NG[RNG]、およびXMLドキュメント型定義(DTD)[XML10]要素型はサポートされます。 また、ASN.1タイプとトップレベルコンポーネントの参照は受入れられます。 指示をコード化するCOMPONENT-REFはトップレベルコンポーネントに参照をつけるより多くのダイレクトメソッドをaに提供します。
The Type in the EncodingPrefixedType for an ELEMENT-REF, REF-AS-ELEMENT, REF-AS-TYPE, or TYPE-REF encoding instruction SHALL be either:
指示SHALLをコード化するELEMENT-REF、REF-AS-ELEMENT、REF-AS-TYPE、またはTYPE-REFのためのEncodingPrefixedTypeのTypeは以下の通りです。
Legg Experimental [Page 8] RFC 4911 Encoding Instructions for RXER July 2007
2007年7月にRXERのために指示をコード化するLeggの実験的な[8ページ]RFC4911
(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
または(1) typereferenceであるDefinedType(DummyReferenceでない)かAdditionalBasicDefinitionsモジュールからMarkup ASN.1タイプに参照をつけるExternalTypeReference[RXER]であるReferencedType。
(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) (3)へのTaggedTypeのTypeが1歳である(1)のTaggedTypeであるPrefixedTypeである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のEncodingPrefixedTypeのTypeが(3)への(1)とEncodingPrefixのひとりであるEncodingPrefixedTypeである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とCOMPONENT-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に関して、場合(1)におけるDefinedTypeはコード化指示「を条件として」、あると言われています。
The restrictions on the Type in the EncodingPrefixedType for an ATTRIBUTE-REF encoding instruction are specified in Section 9. The restrictions on the Type in the EncodingPrefixedType for a COMPONENT-REF encoding instruction are specified in Section 10.
指示をコード化するATTRIBUTE-REFのためのEncodingPrefixedTypeのTypeにおける制限はセクション9で指定されます。 指示をコード化するCOMPONENT-REFのためのEncodingPrefixedTypeのTypeにおける制限はセクション10で指定されます。
The reference encoding instructions make use of a common production defined as follows:
参照コード化指示は以下の通り定義された一般的な生産を利用します:
RefParameters ::= ContextParameter ?
RefParameters:、:= ContextParameter?
ContextParameter ::= "CONTEXT" AnyURIValue
ContextParameter:、:= 「文脈」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は1つ以上の図式ドキュメントか外部のDTD部分集合との定義について言及します。 同じ名前で目標名前空間[XSD1]なしで定義された独自に開発されたXML Schemasからタイプをインポートするとき、例えば、この状況は起こるでしょう。 要素型についての言及に関連して外部のDTD部分集合に使用されると、ContextParameterのAnyURIValueは外部のDTD部分集合に関するシステム識別子(Uniform Resource IdentifierかURI[URI])です。 さもなければ、AnyURIValueは意図している図式ドキュメント、XML Schema仕様、RELAX NG仕様、ASN.1またはASN.X仕様を示すURIです。
Legg Experimental [Page 9] RFC 4911 Encoding Instructions for RXER July 2007
2007年7月にRXERのために指示をコード化するLeggの実験的な[9ページ]RFC4911
7. Expanded Names of Components
7. コンポーネントの拡張名前
Each NamedType has an associated expanded name [XMLNS10], determined as follows:
各NamedTypeには、以下の通り決定する関連拡張名前[XMLNS10]があります:
(1) if the NamedType is subject to a NAME encoding instruction, then
the local name of the expanded name is the character string
specified by the NCNameValue of the NAME encoding instruction,
(1) NamedTypeは指示をコード化するNAMEを受けることがあるなら、拡張名前の地方名が指示をコード化する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は指示をコード化するCOMPONENT-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は指示をコード化するATTRIBUTE-REFかELEMENT-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-ELEMENTを受けることがあるなら、拡張名前の地方名がコード化指示のNameValueによって指定された適切な名前のLocalPart[XMLNS10]です。
(5) otherwise, the local name of the expanded name is the identifier
of the NamedType.
(5) さもなければ、拡張名前の地方名はNamedTypeに関する識別子です。
In cases (1) and (5), if the NamedType is a top-level NamedType and the module containing the NamedType has a TARGET-NAMESPACE encoding instruction, then the namespace name of the expanded name is the character string specified by the AnyURIValue of the TARGET-NAMESPACE encoding instruction; otherwise, the namespace name has no value.
場合(1)と(5)では、NamedTypeがトップレベルNamedTypeであり、TARGET-NAMESPACEがNamedTypeを含むモジュールで指示をコード化するなら、拡張名前の名前空間名は指示をコード化するTARGET-NAMESPACEのAnyURIValueによって指定された文字列です。 さもなければ、名前空間名には、値が全くありません。
Aside: Thus, the TARGET-NAMESPACE encoding instruction applies to
a top-level NamedType but not to any other NamedType.
傍らに: したがって、指示をコード化するTARGET-NAMESPACEはトップレベル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)では、コード化指示がNamespaceを含んでいるなら、拡張名前の名前空間名はNamespaceの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、またはSETタイプの成分のための拡張名前は異なっているに違いありません。 COMPONENTS OF変換がX.680、Clause24.4[X.680]で指定した後にこれらのテストは適用されています。
Legg Experimental [Page 10] RFC 4911 Encoding Instructions for RXER July 2007
2007年7月にRXERのために指示をコード化するLeggの実験的な[10ページ]RFC4911
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.
傍らに: それらの1つが属性コンポーネントであり、もう片方が持っていないなら、同じCHOICE、SEQUENCE、またはSETタイプの2つの成分には同じ拡張名前があるかもしれません。 “not"ケースが指示をコード化するGROUPかSIMPLE-CONTENTを受けることがあるコンポーネントを含んでいることに注意してください。
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.
指示をコード化するATTRIBUTEを条件としたトップレベルNamedTypeという拡張名前は同じモジュールで指示をコード化するATTRIBUTEを条件とした他のあらゆるトップレベル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でないという拡張名前は同じモジュールで指示をコード化するATTRIBUTEを条件とした他のあらゆるトップレベルNamedTypeでないという拡張名前と異なっているに違いありません。
Aside: Two top-level components may have the same expanded name if
one of them is an attribute component and the other is not.
傍らに: それらの1つが属性コンポーネントであり、もう片方が持っていないなら、2つのトップレベルコンポーネントには同じ拡張名前があるかもしれません。
8. The ATTRIBUTE Encoding Instruction
8. 指示をコード化する属性
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.
指示をコード化するATTRIBUTEはRXERエンコーダにそれが子供要素の代わりにXML属性として適用されるコンポーネントの値をコード化させます。
The notation for an ATTRIBUTE encoding instruction is defined as follows:
指示をコード化するATTRIBUTEのための記法は以下の通り定義されます:
AttributeInstruction ::= "ATTRIBUTE"
AttributeInstruction:、:= 「属性」
The base type of the type of a NamedType that is subject to an ATTRIBUTE encoding instruction SHALL NOT be:
ベースはNamedTypeのタイプにタイプされます、すなわち、指示SHALL NOTをコード化するATTRIBUTEを条件として、いてください、:
(1) a CHOICE, SET, or SET OF type, or
または(1) CHOICE、SET、またはSET OFがタイプする。
(2) a SEQUENCE type other than the one defining the QName type from
the AdditionalBasicDefinitions module [RXER] (i.e., QName is
allowed), or
または(2) QNameを定義するもの以外のSEQUENCEタイプがAdditionalBasicDefinitionsモジュール[RXER]からタイプする、(すなわち、QNameは許容されています)。
(3) a SEQUENCE OF type where the SequenceOfType is not subject to a
LIST encoding instruction, or
または(3) SequenceOfTypeは指示をコード化するLISTを受けることがないSEQUENCE OFタイプ。
(4) an open type.
(4) 開放型。
Legg Experimental [Page 11] RFC 4911 Encoding Instructions for RXER July 2007
2007年7月にRXERのために指示をコード化するLeggの実験的な[11ページ]RFC4911
Example
例
PersonalDetails ::= SEQUENCE {
firstName [ATTRIBUTE] UTF8String,
middleName [ATTRIBUTE] UTF8String,
surname [ATTRIBUTE] UTF8String
}
PersonalDetails:、:= 系列firstName[ATTRIBUTE]UTF8String、middleName[ATTRIBUTE]UTF8String、姓[ATTRIBUTE]のUTF8String
9. The ATTRIBUTE-REF Encoding Instruction
9. 指示をコード化する属性審判
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はRXERエンコーダにそれが属性の名前がコード化指示で参照をつけられる属性宣言の適切な名前である子供要素の代わりにXML属性として適用されるコンポーネントの値をコード化させます。 さらに、指示をコード化するATTRIBUTE-REFは、属性宣言のタイプに従うためにUTF8Stringタイプの値を制限させます。
The notation for an ATTRIBUTE-REF encoding instruction is defined as follows:
指示をコード化するATTRIBUTE-REFのための記法は以下の通り定義されます:
AttributeRefInstruction ::=
"ATTRIBUTE-REF" QNameValue RefParameters
AttributeRefInstruction:、:= 「属性審判」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.
一緒に取って、RefParameters(存在しているなら)のQNameValueとContextParameterは指示をコード化するATTRIBUTEを受けることがあるXML Schema属性宣言かトップレベル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 Schemaのタイプは直接か派生によるXML SchemaタイプがQName、NOTATION、ENTITY、ENTITIES、またはanySimpleTypeであったなら宣言SHALL NOTを結果と考えます。
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.1UTF8Stringタイプを前に置くのに制限されるので、そのような文脈を得るために、メカニズムは全くありません。
The type of a referenced top-level NamedType SHALL NOT be, either directly or by subtyping, the QName type from the AdditionalBasicDefinitions module [RXER].
aのタイプはAdditionalBasicDefinitionsからの直接か副タイプするのによるQNameタイプがモジュール[RXER]であったならトップレベルNamedType SHALL NOTに参照をつけました。
The Type in the EncodingPrefixedType for an ATTRIBUTE-REF encoding instruction SHALL be either:
指示SHALLをコード化するATTRIBUTE-REFのためのEncodingPrefixedTypeのTypeは以下の通りです。
(1) the UTF8String type, or
または(1) UTF8Stringがタイプする。
Legg Experimental [Page 12] RFC 4911 Encoding Instructions for RXER July 2007
2007年7月にRXERのために指示をコード化するLeggの実験的な[12ページ]RFC4911
(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) (3)へのTaggedTypeのTypeが1歳である(1)のTaggedTypeであるPrefixedTypeである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のEncodingPrefixedTypeのTypeが(3)への(1)とEncodingPrefixのひとりであるEncodingPrefixedTypeである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コード化における属性の名前に貢献しません。 一貫性、識別子SHOULDのために、可能であるところでは、参照をつけられた属性宣言の地方名と同じにしてください。
10. The COMPONENT-REF Encoding Instruction
10. 指示をコード化するコンポーネント審判
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:
指示をコード化するCOMPONENT-REFのための記法は以下の通り定義されます:
ComponentRefInstruction ::= "COMPONENT-REF" ComponentReference
ComponentRefInstruction:、:= 「コンポーネント審判」ComponentReference
ComponentReference ::=
InternalComponentReference |
ExternalComponentReference
ComponentReference:、:= InternalComponentReference| ExternalComponentReference
InternalComponentReference ::= identifier FromModule ?
InternalComponentReference:、:= 識別子FromModule?
FromModule ::= "FROM" GlobalModuleReference
FromModule:、:= "FROM" GlobalModuleReference
ExternalComponentReference ::= modulereference "." identifier
ExternalComponentReference:、:= "modulereference" 」 識別子
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.
ASN.1の基本的な記法[X.680]でGlobalModuleReference生産は定義されます。 GlobalModuleReferenceがInternalComponentReferenceから欠けるなら、識別子は同じモジュールによるトップレベルNamedTypeに関する識別子であるに違いありません。 GlobalModuleReferenceがInternalComponentReferenceに存在しているなら、識別子は参照をつけられたモジュールによるトップレベルNamedTypeに関する識別子であるに違いありません。
Legg Experimental [Page 13] RFC 4911 Encoding Instructions for RXER July 2007
2007年7月にRXERのために指示をコード化するLeggの実験的な[13ページ]RFC4911
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.
modulereferenceと同様に、ExternalComponentReferenceのmodulereferenceはExternalTypeReferenceで使用されます。 ExternalComponentReferenceの識別子は参照をつけられたモジュールによるトップレベルNamedTypeに関する識別子であるに違いありません。
The Type in the EncodingPrefixedType for a COMPONENT-REF encoding instruction SHALL be either:
指示SHALLをコード化するCOMPONENT-REFのためのEncodingPrefixedTypeのTypeは以下の通りです。
(1) a ReferencedType that is a DefinedType that is a typereference
(not a DummyReference) or an ExternalTypeReference, or
(1) a ReferencedType that is a DefinedType that is a typereference (not a DummyReference) or an ExternalTypeReference, or
(2) a BuiltinType or ReferencedType that is one of the productions in
Table 1 in Section 5 of the specification for RXER [RXER], or
(2) a BuiltinType or ReferencedType that is one of the productions in Table 1 in Section 5 of the specification for RXER [RXER], or
(3) a BuiltinType that is a PrefixedType that is a TaggedType where
the Type in the TaggedType is one of (1) to (4), or
(3) a BuiltinType that is a PrefixedType that is a TaggedType where the Type in the TaggedType is one of (1) to (4), or
(4) a BuiltinType that is a PrefixedType that is an
EncodingPrefixedType where the Type in the EncodingPrefixedType
is one of (1) to (4) and the EncodingPrefix in the
EncodingPrefixedType does not contain a reference encoding
instruction.
(4) a BuiltinType that is a PrefixedType that is an EncodingPrefixedType where the Type in the EncodingPrefixedType is one of (1) to (4) and the EncodingPrefix in the EncodingPrefixedType does not contain a reference encoding instruction.
The restrictions on the use of RXER encoding instructions are such that no other RXER encoding instruction is permitted within a NamedType if the NamedType is subject to a COMPONENT-REF encoding instruction.
The restrictions on the use of RXER encoding instructions are such that no other RXER encoding instruction is permitted within a NamedType if the NamedType is subject to a COMPONENT-REF encoding instruction.
The Type in the top-level NamedType referenced by the COMPONENT-REF encoding instruction MUST be either:
The Type in the top-level NamedType referenced by the COMPONENT-REF encoding instruction MUST be either:
(a) if the preceding case (1) is used, a ReferencedType that is a
DefinedType that is a typereference or ExternalTypeReference that
references the same type as the DefinedType in case (1), or
(a) if the preceding case (1) is used, a ReferencedType that is a DefinedType that is a typereference or ExternalTypeReference that references the same type as the DefinedType in case (1), or
(b) if the preceding case (2) is used, a BuiltinType or
ReferencedType that is the same as the BuiltinType or
ReferencedType in case (2), or
(b) if the preceding case (2) is used, a BuiltinType or ReferencedType that is the same as the BuiltinType or ReferencedType in case (2), or
(c) a BuiltinType that is a PrefixedType that is an
EncodingPrefixedType where the Type in the EncodingPrefixedType
is one of (a) to (c), and the EncodingPrefix in the
EncodingPrefixedType contains an RXER encoding instruction.
(c) a BuiltinType that is a PrefixedType that is an EncodingPrefixedType where the Type in the EncodingPrefixedType is one of (a) to (c), and the EncodingPrefix in the EncodingPrefixedType contains an RXER encoding instruction.
In principle, the COMPONENT-REF encoding instruction creates a notional NamedType where the expanded name is that of the referenced top-level NamedType and the Type in case (1) or (2) is substituted by the Type of the referenced top-level NamedType.
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.
Legg Experimental [Page 14] RFC 4911 Encoding Instructions for RXER July 2007
Legg Experimental [Page 14] RFC 4911 Encoding Instructions for RXER July 2007
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.
In practice, it is sufficient for non-RXER encoders and decoders to use the original NamedType rather than the notional NamedType because the Type in case (1) or (2) can only differ from the Type of the referenced top-level NamedType by having fewer RXER encoding instructions, and RXER encoding instructions are ignored by non-RXER encoders and decoders.
Although any prefixes for the Type in case (1) or (2) would be bypassed, it is sufficient for RXER encoders and decoders to use the referenced top-level NamedType instead of the notional NamedType because these prefixes cannot be RXER encoding instructions (except, of course, for the COMPONENT-REF encoding instruction) and can have no effect on an RXER encoding.
Although any prefixes for the Type in case (1) or (2) would be bypassed, it is sufficient for RXER encoders and decoders to use the referenced top-level NamedType instead of the notional NamedType because these prefixes cannot be RXER encoding instructions (except, of course, for the COMPONENT-REF encoding instruction) and can have no effect on an RXER encoding.
Example
Example
Modules ::= SEQUENCE OF
module [COMPONENT-REF module
FROM AbstractSyntaxNotation-X
{ 1 3 6 1 4 1 21472 1 0 1 }]
ModuleDefinition
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:
Note that the "module" top-level NamedType in the AbstractSyntaxNotation-X module is defined like so:
COMPONENT module ModuleDefinition
COMPONENT module ModuleDefinition
The ASN.X translation of the SEQUENCE OF type definition provides
a more natural representation:
The ASN.X translation of the SEQUENCE OF type definition provides a more natural representation:
<namedType xmlns:asnx="urn:ietf:params:xml:ns:asnx"
name="Modules">
<sequenceOf>
<element ref="asnx:module"/>
</sequenceOf>
</namedType>
<namedType xmlns:asnx="urn:ietf:params:xml:ns:asnx" name="Modules"> <sequenceOf> <element ref="asnx:module"/> </sequenceOf> </namedType>
Aside: The <namedType> element in ASN.X corresponds to a
TypeAssignment, not a NamedType.
Aside: The <namedType> element in ASN.X corresponds to a TypeAssignment, not a NamedType.
The identifier of a NamedType subject to a COMPONENT-REF encoding instruction does not contribute to an RXER encoding. For the sake of consistency with other encoding rules, the identifier SHOULD be the same as the identifier in the ComponentRefInstruction.
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.
Legg Experimental [Page 15] RFC 4911 Encoding Instructions for RXER July 2007
Legg Experimental [Page 15] RFC 4911 Encoding Instructions for RXER July 2007
11. The ELEMENT-REF Encoding Instruction
11. The ELEMENT-REF Encoding Instruction
The ELEMENT-REF encoding instruction causes an RXER encoder to encode a value of the component to which it is applied as an element where the element's name is a qualified name of the element declaration referenced by the encoding instruction. In addition, the ELEMENT-REF encoding instruction causes values of the Markup ASN.1 type to be restricted to conform to the type of the element declaration.
The ELEMENT-REF encoding instruction causes an RXER encoder to encode a value of the component to which it is applied as an element where the element's name is a qualified name of the element declaration referenced by the encoding instruction. In addition, the ELEMENT-REF encoding instruction causes values of the Markup ASN.1 type to be restricted to conform to the type of the element declaration.
The notation for an ELEMENT-REF encoding instruction is defined as follows:
The notation for an ELEMENT-REF encoding instruction is defined as follows:
ElementRefInstruction ::= "ELEMENT-REF" QNameValue RefParameters
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.
Taken together, the QNameValue and the ContextParameter in the RefParameters (if present) MUST reference an XML Schema element declaration, a RELAX NG element definition, or a top-level NamedType that is not subject to an ATTRIBUTE encoding instruction.
A referenced XML Schema element declaration MUST NOT have a type that requires the presence of values for the XML Schema ENTITY or ENTITIES types.
A referenced XML Schema element declaration MUST NOT have a type that requires the presence of values for the XML Schema ENTITY or ENTITIES types.
Aside: Entity declarations are not supported by CRXER.
Aside: Entity declarations are not supported by CRXER.
Example
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
}
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:
The ASN.X translation of the choice type definition provides a more natural representation:
Legg Experimental [Page 16] RFC 4911 Encoding Instructions for RXER July 2007
Legg Experimental [Page 16] RFC 4911 Encoding Instructions for RXER July 2007
<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="urn:ietf:params:xml:ns:asnx" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:rng="http://relaxng.org/ns/structure/1.0" name="AnySchema"> <choice> <element ref="asnx:module" embedded="true"/> <element ref="xs:schema" embedded="true"/> <element ref="rng:grammar" embedded="true"/> </choice> </namedType>
The identifier of a NamedType subject to an ELEMENT-REF encoding instruction does not contribute to the name of an element in an RXER encoding. For the sake of consistency, the identifier SHOULD, where possible, be the same as the local name of the referenced element declaration.
The identifier of a NamedType subject to an ELEMENT-REF encoding instruction does not contribute to the name of an element in an RXER encoding. For the sake of consistency, the identifier SHOULD, where possible, be the same as the local name of the referenced element declaration.
12. The LIST Encoding Instruction
12. The LIST Encoding Instruction
The LIST encoding instruction causes an RXER encoder to encode a value of a SEQUENCE OF type as a white-space-separated list of the component values.
The LIST encoding instruction causes an RXER encoder to encode a value of a SEQUENCE OF type as a white-space-separated list of the component values.
The notation for a LIST encoding instruction is defined as follows:
The notation for a LIST encoding instruction is defined as follows:
ListInstruction ::= "LIST"
ListInstruction ::= "LIST"
The Type in an EncodingPrefixedType for a LIST encoding instruction SHALL be either:
The Type in an EncodingPrefixedType for a LIST encoding instruction SHALL be either:
(1) a BuiltinType that is a SequenceOfType of the
"SEQUENCE OF NamedType" form, or
(1) a BuiltinType that is a SequenceOfType of the "SEQUENCE OF NamedType" form, or
(2) a ConstrainedType that is a TypeWithConstraint of the
"SEQUENCE Constraint OF NamedType" form or
"SEQUENCE SizeConstraint OF NamedType" form, or
(2) a ConstrainedType that is a TypeWithConstraint of the "SEQUENCE Constraint OF NamedType" form or "SEQUENCE SizeConstraint OF NamedType" form, or
(3) a ConstrainedType that is not a TypeWithConstraint where the Type
in the ConstrainedType is one of (1) to (5), or
(3) a ConstrainedType that is not a TypeWithConstraint where the Type in the ConstrainedType is one of (1) to (5), or
(4) a BuiltinType that is a PrefixedType that is a TaggedType where
the Type in the TaggedType is one of (1) to (5), or
(4) a BuiltinType that is a PrefixedType that is a TaggedType where the Type in the TaggedType is one of (1) to (5), or
(5) a BuiltinType that is a PrefixedType that is an
EncodingPrefixedType where the Type in the EncodingPrefixedType
is one of (1) to (5).
(5) a BuiltinType that is a PrefixedType that is an EncodingPrefixedType where the Type in the EncodingPrefixedType is one of (1) to (5).
Legg Experimental [Page 17] RFC 4911 Encoding Instructions for RXER July 2007
Legg Experimental [Page 17] RFC 4911 Encoding Instructions for RXER July 2007
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.
The effect of this condition is to force the LIST encoding instruction to be textually co-located with the SequenceOfType or TypeWithConstraint to which it applies.
Aside: This makes it clear to a reader that the encoding
instruction applies to every use of the type no matter how it
might be referenced.
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.
The SequenceOfType in case (1) and the TypeWithConstraint in case (2) are said to be "subject to" the LIST encoding instruction.
A SequenceOfType or TypeWithConstraint SHALL NOT be subject to more than one LIST encoding instruction.
A SequenceOfType or TypeWithConstraint SHALL NOT be subject to more than one LIST encoding instruction.
The base type of the component type of a SequenceOfType or TypeWithConstraint that is subject to a LIST encoding instruction MUST be one of the following:
The base type of the component type of a SequenceOfType or TypeWithConstraint that is subject to a LIST encoding instruction MUST be one of the following:
(1) the BOOLEAN, INTEGER, ENUMERATED, REAL, OBJECT IDENTIFIER,
RELATIVE-OID, GeneralizedTime, or UTCTime type, or
(1) the BOOLEAN, INTEGER, ENUMERATED, REAL, OBJECT IDENTIFIER, RELATIVE-OID, GeneralizedTime, or UTCTime type, or
(2) the NCName, AnyURI, Name, or QName type from the
AdditionalBasicDefinitions module [RXER].
(2) the NCName, AnyURI, Name, or QName type from the AdditionalBasicDefinitions module [RXER].
Aside: While it would be feasible to allow the component type to
also be any character string type that is constrained such that
all its abstract values have a length greater than zero and none
of its abstract values contain any white space characters, testing
whether this condition is satisfied can be quite involved. For
the sake of simplicity, only certain immediately useful
constrained UTF8String types, which are known to be suitable, are
permitted (i.e., NCName, AnyURI, and Name).
Aside: While it would be feasible to allow the component type to also be any character string type that is constrained such that all its abstract values have a length greater than zero and none of its abstract values contain any white space characters, testing whether this condition is satisfied can be quite involved. For the sake of simplicity, only certain immediately useful constrained UTF8String types, which are known to be suitable, are permitted (i.e., NCName, AnyURI, and Name).
The NamedType in a SequenceOfType or TypeWithConstraint that is subject to a LIST encoding instruction MUST NOT be subject to an ATTRIBUTE, ATTRIBUTE-REF, COMPONENT-REF, GROUP, ELEMENT-REF, REF-AS-ELEMENT, SIMPLE-CONTENT, or TYPE-AS-VERSION encoding instruction.
The NamedType in a SequenceOfType or TypeWithConstraint that is subject to a LIST encoding instruction MUST NOT be subject to an ATTRIBUTE, ATTRIBUTE-REF, COMPONENT-REF, GROUP, ELEMENT-REF, REF-AS-ELEMENT, SIMPLE-CONTENT, or TYPE-AS-VERSION encoding instruction.
Example
Example
UpdateTimes ::= [LIST] SEQUENCE OF updateTime GeneralizedTime
UpdateTimes ::= [LIST] SEQUENCE OF updateTime GeneralizedTime
Legg Experimental [Page 18] RFC 4911 Encoding Instructions for RXER July 2007
Legg Experimental [Page 18] RFC 4911 Encoding Instructions for RXER July 2007
13. The NAME Encoding Instruction
13. The NAME Encoding Instruction
The NAME encoding instruction causes an RXER encoder to use a nominated character string instead of a component's identifier wherever that identifier would otherwise appear in the encoding (e.g., as an element or attribute name).
The NAME encoding instruction causes an RXER encoder to use a nominated character string instead of a component's identifier wherever that identifier would otherwise appear in the encoding (e.g., as an element or attribute name).
The notation for a NAME encoding instruction is defined as follows:
The notation for a NAME encoding instruction is defined as follows:
NameInstruction ::= "NAME" "AS"? NCNameValue
NameInstruction ::= "NAME" "AS"? NCNameValue
Example
Example
CHOICE {
foo-att [ATTRIBUTE] [NAME AS "Foo"] INTEGER,
foo-elem [NAME "Foo"] INTEGER
}
CHOICE { foo-att [ATTRIBUTE] [NAME AS "Foo"] INTEGER, foo-elem [NAME "Foo"] INTEGER }
14. The REF-AS-ELEMENT Encoding Instruction
14. The REF-AS-ELEMENT Encoding Instruction
The REF-AS-ELEMENT encoding instruction causes an RXER encoder to encode a value of the component to which it is applied as an element where the element's name is the name of the external DTD subset element type declaration referenced by the encoding instruction. In addition, the REF-AS-ELEMENT encoding instruction causes values of the Markup ASN.1 type to be restricted to conform to the content and attributes permitted by that element type declaration and its associated attribute-list declarations.
The REF-AS-ELEMENT encoding instruction causes an RXER encoder to encode a value of the component to which it is applied as an element where the element's name is the name of the external DTD subset element type declaration referenced by the encoding instruction. In addition, the REF-AS-ELEMENT encoding instruction causes values of the Markup ASN.1 type to be restricted to conform to the content and attributes permitted by that element type declaration and its associated attribute-list declarations.
The notation for a REF-AS-ELEMENT encoding instruction is defined as follows:
The notation for a REF-AS-ELEMENT encoding instruction is defined as follows:
RefAsElementInstruction ::=
"REF-AS-ELEMENT" NameValue Namespace ? RefParameters
RefAsElementInstruction ::= "REF-AS-ELEMENT" NameValue Namespace ? RefParameters
Namespace ::= "NAMESPACE" AnyURIValue
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].
Taken together, the NameValue and the ContextParameter in the RefParameters (if present) MUST reference an element type declaration in an external DTD subset that is conformant with Namespaces in XML 1.0 [XMLNS10].
The Namespace is present if and only if the Name of the referenced element type declaration conforms to a PrefixedName (a QName) [XMLNS10], in which case the Namespace specifies the namespace name to be associated with the Prefix of the PrefixedName.
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.
Legg Experimental [Page 19] RFC 4911 Encoding Instructions for RXER July 2007
Legg Experimental [Page 19] RFC 4911 Encoding Instructions for RXER July 2007
The referenced element type declaration MUST NOT require the presence of attributes of type ENTITY or ENTITIES.
The referenced element type declaration MUST NOT require the presence of attributes of type ENTITY or ENTITIES.
Aside: Entity declarations are not supported by CRXER.
Aside: Entity declarations are not supported by CRXER.
Example
Example
Suppose that the following external DTD subset has been defined
with a system identifier of "http://www.example.com/inventory":
Suppose that the following external DTD subset has been defined with a system identifier of "http://www.example.com/inventory":
<?xml version='1.0'?>
<!ELEMENT product EMPTY>
<!ATTLIST product
name CDATA #IMPLIED
partNumber CDATA #REQUIRED
quantity CDATA #REQUIRED >
<?xml version='1.0'?> <!ELEMENT product EMPTY> <!ATTLIST product name CDATA #IMPLIED partNumber CDATA #REQUIRED quantity CDATA #REQUIRED >
The product element type declaration can be referenced as an
element in an ASN.1 type definition:
The product element type declaration can be referenced as an element in an ASN.1 type definition:
CHOICE {
product [REF-AS-ELEMENT "product"
CONTEXT "http://www.example.com/inventory"]
Markup
}
CHOICE { product [REF-AS-ELEMENT "product" CONTEXT "http://www.example.com/inventory"] Markup }
Here is the ASN.X translation of this ASN.1 type definition:
Here is the ASN.X translation of this ASN.1 type definition:
<type>
<choice>
<element elementType="product"
context="http://www.example.com/inventory"/>
</choice>
</type>
<type> <choice> <element elementType="product" context="http://www.example.com/inventory"/> </choice> </type>
The identifier of a NamedType subject to a REF-AS-ELEMENT encoding instruction does not contribute to the name of an element in an RXER encoding. For the sake of consistency, the identifier SHOULD, where possible, be the same as the Name of the referenced element type declaration (or the LocalPart if the Name conforms to a PrefixedName).
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).
15. The REF-AS-TYPE Encoding Instruction
15. The REF-AS-TYPE Encoding Instruction
The REF-AS-TYPE encoding instruction causes values of the Markup ASN.1 type to be restricted to conform to the content and attributes permitted by a nominated element type declaration and its associated attribute-list declarations in an external DTD subset.
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.
Legg Experimental [Page 20] RFC 4911 Encoding Instructions for RXER July 2007
Legg Experimental [Page 20] RFC 4911 Encoding Instructions for RXER July 2007
The notation for a REF-AS-TYPE encoding instruction is defined as follows:
The notation for a REF-AS-TYPE encoding instruction is defined as follows:
RefAsTypeInstruction ::= "REF-AS-TYPE" NameValue RefParameters
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].
Taken together, the NameValue and the ContextParameter of the RefParameters (if present) MUST reference an element type declaration in an external DTD subset that is conformant with Namespaces in XML 1.0 [XMLNS10].
The referenced element type declaration MUST NOT require the presence of attributes of type ENTITY or ENTITIES.
The referenced element type declaration MUST NOT require the presence of attributes of type ENTITY or ENTITIES.
Aside: Entity declarations are not supported by CRXER.
傍らに: 実体宣言はCRXERによってサポートされません。
Example
例
The product element type declaration can be referenced as a type
in an ASN.1 definition:
タイプとしてASN.1定義で製品要素型の宣言に参照をつけることができます:
SEQUENCE OF
inventoryItem
[REF-AS-TYPE "product"
CONTEXT "http://www.example.com/inventory"]
Markup
inventoryItem[タイプとしての審判「製品」文脈" http://www.example.com/inventory "]マーク付けの系列
Here is the ASN.X translation of this definition:
ここに、この定義に関するASN.X翻訳があります:
<sequenceOf>
<element name="inventoryItem">
<type elementType="product"
context="http://www.example.com/inventory"/>
</element>
</sequenceOf>
<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:
要素型の宣言がタイプとして参照をつけられるとき、要素型の宣言のNameがRXER encodingsに貢献しないことに注意してください。 例えば、上のSEQUENCE OFタイプの値のRXERコード化における子供要素は以下に類似しているでしょう:
<inventoryItem name="hammer" partNumber="1543" quantity="29"/>
「1543」<inventoryItem名前=「ハンマー」partNumber=量=の「29インチ/>」
Legg Experimental [Page 21] RFC 4911 Encoding Instructions for RXER July 2007
2007年7月にRXERのために指示をコード化するLeggの実験的な[21ページ]RFC4911
16. The SCHEMA-IDENTITY Encoding Instruction
16. 指示をコード化する図式アイデンティティ
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はユニークな識別子、URI[URI]をコード化指示を含んでいるASN.1モジュールに関連づけます。 このコード化指示は、RXERエンコーダの上に効き目がありませんが、ASN.1仕様に関する翻訳にASN.X表現に影響を与えます。
The notation for a SCHEMA-IDENTITY encoding instruction is defined as follows:
指示をコード化するSCHEMA-IDENTITYのための記法は以下の通り定義されます:
SchemaIdentityInstruction ::= "SCHEMA-IDENTITY" AnyURIValue
SchemaIdentityInstruction:、:= 「図式アイデンティティ」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.
指示をコード化するそれぞれのSCHEMA-IDENTITYのAnyURIValueによって指定された文字列は異なっているに違いありません。 ASN.1モジュールの連続したバージョンには、それぞれ特に、異なった図式アイデンティティURI価値がなければなりません。
17. The SIMPLE-CONTENT Encoding Instruction
17. 指示をコード化する簡単な内容
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.
指示をコード化するSIMPLE-CONTENTがRXERエンコーダにSEQUENCEの部品の値をコード化させるか、またはSETは子供要素でカプセル化なしでタイプします。
The notation for a SIMPLE-CONTENT encoding instruction is defined as follows:
指示をコード化するSIMPLE-CONTENTのための記法は以下の通り定義されます:
SimpleContentInstruction ::= "SIMPLE-CONTENT"
SimpleContentInstruction:、:= 「簡単な内容」
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].
A NamedTypeはコネがRootComponentTypeListのComponentTypeListのComponentTypeであったならSIMPLE-CONTENTコード化指示にSHALLをかけます。 高々、そのようなNamedTypeのSEQUENCEかSETタイプのひとりは指示をコード化するSIMPLE-CONTENTを受けることがあることが許可されています。 何かコンポーネントが指示をコード化するSIMPLE-CONTENTを受けることがあるなら、同じSEQUENCEかSET型定義における他のすべてのコンポーネントが属性コンポーネントであるに違いありません。 COMPONENTS OF変換がX.680、Clause24.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.
傍らに: 子供要素と簡単な内容は互いに唯一です。 仕様作家は、広げることができるSEQUENCEかSETタイプの成分の指示をコード化するSIMPLE-CONTENTの使用が、SEQUENCEかSETタイプへのすべての今後の拡大が属性コンポーネントのために受入れられる限られたセットのタイプがある属性コンポーネントに制限されることを意味することに注意するべきです。 指示をコード化するSIMPLE-CONTENTの代わりに指示をコード化するATTRIBUTEを使用すると、この制限は避けられます。
Legg Experimental [Page 22] RFC 4911 Encoding Instructions for RXER July 2007
2007年7月にRXERのために指示をコード化するLeggの実験的な[22ページ]RFC4911
The base type of the type of a NamedType that is subject to a SIMPLE-CONTENT encoding instruction SHALL NOT be:
ベースはNamedTypeのタイプにタイプされます、すなわち、指示SHALL NOTをコード化するSIMPLE-CONTENTを条件として、いてください、:
(1) a SET or SET OF type, or
または(1) SETかSET OFタイプ。
(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) QNameを定義するもの以外のSEQUENCEタイプがAdditionalBasicDefinitionsモジュール[RXER]からタイプする、(すなわち、QNameは許容されています)。
(4) a SEQUENCE OF type where the SequenceOfType is not subject to a
LIST encoding instruction, or
または(4) SequenceOfTypeは指示をコード化するLISTを受けることがないSEQUENCE OFタイプ。
(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 SHALLはOPTIONALかDEFAULTであるとマークされていませんか?
Example
例
SEQUENCE {
units [ATTRIBUTE] UTF8String,
amount [SIMPLE-CONTENT] INTEGER
}
系列ユニット[ATTRIBUTE]UTF8String、量[SIMPLE-CONTENT]のINTEGER
18. The TARGET-NAMESPACE Encoding Instruction
18. 指示をコード化する目標名前空間
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-NAMESPACEはXML名前空間名[XMLNS10]、オブジェクトのクラス(値)がタイプで反対させるURI[URI]、およびコード化指示を含むASN.1モジュールで定義されたオブジェクトセット参照を関連づけます。 さらに、それはRXERの制御セクションをコード化するそれぞれのトップレベルNamedTypeの名前空間名を関連づけます。
The notation for a TARGET-NAMESPACE encoding instruction is defined as follows:
指示をコード化するTARGET-NAMESPACEのための記法は以下の通り定義されます:
TargetNamespaceInstruction ::=
"TARGET-NAMESPACE" AnyURIValue Prefix ?
TargetNamespaceInstruction:、:= 「目標名前空間」AnyURIValue接頭語?
Prefix ::= "PREFIX" NCNameValue
以下を前に置いてください:= 「接頭語」NCNameValue
The AnyURIValue SHALL NOT specify an empty string.
AnyURIValue SHALLは空のストリングを指定しません。
Legg Experimental [Page 23] RFC 4911 Encoding Instructions for RXER July 2007
2007年7月にRXERのために指示をコード化するLeggの実験的な[23ページ]RFC4911
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.
存在しているなら、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.
トップレベルコンポーネントが全くなければ、TARGET-NAMESPACEが指示をコード化しているモジュールを使用することで生産されたRXER encodingsはTARGET-NAMESPACEが指示をコード化しないで同じモジュールで生産されるRXER encodingsと互換性があった状態で後方です。
19. The TYPE-AS-VERSION Encoding Instruction
19. バージョンとしての指示をコード化するタイプ
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-AS-バージョンで、RXERエンコーダはxsiを含んでいます: コード化指示が適用されているコンポーネントの価値のコード化で属性をタイプしてください。 この属性で、XML Schema[XSD1]validatorは、ASN.1仕様のバージョンのための翻訳が使用した適切なXML Schemaが利用可能であるならコード化を作成するのを選択できます。
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 SchemaへのASN.1仕様に関する翻訳が進歩的な拡大でバージョンの向こう側にASN.1仕様にわずかに異ならせると予想されます。 各バージョンが異なった目標名前空間を使用するなら、これらの翻訳の間のどんな非互換性も設備することができます。 目標名前空間で、xsi: タイプ属性の値で明白であり、XML Schema validatorは適切なバージョンを使用するでしょう。 また、このメカニズムはASN.1仕様の後のバージョンで改名されるASN.1タイプに対応します。
The notation for a TYPE-AS-VERSION encoding instruction is defined as follows:
指示をコード化するTYPE-AS-バージョンのための記法は以下の通り定義されます:
TypeAsVersionInstruction ::= "TYPE-AS-VERSION"
TypeAsVersionInstruction:、:= 「バージョンとして、タイプしてください」
Legg Experimental [Page 24] RFC 4911 Encoding Instructions for RXER July 2007
2007年7月にRXERのために指示をコード化するLeggの実験的な[24ページ]RFC4911
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のTypeは名前空間で適切な参照であるに違いありません[RXER]。
The addition of a TYPE-AS-VERSION encoding instruction does not affect the backward compatibility of RXER encodings.
指示をコード化するTYPE-AS-バージョンの追加はRXER encodingsの後方の互換性に影響しません。
Aside: In a translation of an ASN.1 specification into XML Schema,
any Type in a NamedType that is subject to a TYPE-AS-VERSION
encoding instruction is expected to be translated into the
XML Schema anyType so that the xsi:type attribute acts as a switch
to select the appropriate version.
傍らに: XML SchemaへのASN.1仕様に関する翻訳では、指示をコード化しながらTYPE-AS-バージョンを受けることがあるNamedTypeのどんなTypeによってもXML Schema anyTypeに翻訳されると予想されて、xsi: タイプは、適切なバージョンを選択するために行為をスイッチとみなします。
20. The TYPE-REF Encoding Instruction
20. 指示をコード化するタイプ審判
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がタイプという特定のXML Schemaに従うためにMarkup ASN.1タイプの値を制限させたか、RELAX NGがパターンを命名したか、またはASN.1はタイプを定義しました。
Aside: Referencing an ASN.1 type in a TYPE-REF encoding
instruction does not have the effect of imposing a requirement to
preserve the Infoset [INFOSET] representation of the RXER encoding
of an abstract value of the type. It is still sufficient to
preserve just the abstract value.
傍らに: 指示をコード化するTYPE-REFのASN.1タイプに参照をつけるのにおいて、タイプの抽象的な価値のRXERコード化のInfoset[INFOSET]表現を保存するという要件を課すという効果がありません。 まさしく抽象的な価値を守るのはまだ十分です。
The notation for a TYPE-REF encoding instruction is defined as follows:
指示をコード化するTYPE-REFのための記法は以下の通り定義されます:
TypeRefInstruction ::= "TYPE-REF" QNameValue RefParameters
TypeRefInstruction:、:= 「タイプ審判」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.
一緒に取って、RefParameters(存在しているなら)のQNameValueとContextParameterはXML Schemaがタイプ、パターンという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 SchemaタイプがXML Schema 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 SHALL NOT、XML Schema NOTATIONタイプ[XSD2](すなわち、名前空間名前" http://www.w3.org/2001/XMLSchema "と地方名「記法」)は直接的な言及になってください。 しかしながら、NOTATIONタイプから得られたXML Schemaタイプについての言及は受入れられます。
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]の名前で居住されるのを保証することです。
Legg Experimental [Page 25] RFC 4911 Encoding Instructions for RXER July 2007
2007年7月にRXERのために指示をコード化するLeggの実験的な[25ページ]RFC4911
Example
例
MyDecimal ::=
[TYPE-REF {
namespace-name "http://www.w3.org/2001/XMLSchema",
local-name "decimal" }]
Markup
MyDecimal:、:= [TYPE-REFは" http://www.w3.org/2001/XMLSchema "、地方名を「小数」と名前空間で命名します] マーク付け
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 Schemaの10進タイプを参照への、より当然の道に提供することに注意してください:
<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「><タイプ審判=「xs: 小数」=「本当」埋め込まれた/></namedType>」
21. The UNION Encoding Instruction
21. 指示をコード化する組合
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はRXERエンコーダに子供要素のカプセル化なしでCHOICEタイプの代替手段の値をコード化させます。 選ばれた代替手段はメンバー属性で任意に示されます。 また、任意のPrecedenceListは仕様作家にどの代替手段が使用されたかを決定するとき(実際の代替手段がメンバー属性を通して指定されていないなら)RXERデコーダがCHOICEの代替手段を考えるオーダーを変更させます。
The notation for a UNION encoding instruction is defined as follows:
指示をコード化するUNIONのための記法は以下の通り定義されます:
UnionInstruction ::= "UNION" AlternativesPrecedence ?
UnionInstruction:、:= 「組合」AlternativesPrecedence?
AlternativesPrecedence ::= "PRECEDENCE" PrecedenceList
AlternativesPrecedence:、:= 「先行」PrecedenceList
PrecedenceList ::= identifier PrecedenceList ?
PrecedenceList:、:= 識別子PrecedenceList?
The Type in the EncodingPrefixedType for a UNION encoding instruction SHALL be either:
指示SHALLをコード化するUNIONのためのEncodingPrefixedTypeのTypeは以下の通りです。
(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のTypeが1歳である(4)への(1)のTypeWithConstraintでないConstrainedType。
(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) (4)へのTaggedTypeのTypeが1歳である(1)のTaggedTypeであるPrefixedTypeであるBuiltinType。
Legg Experimental [Page 26] RFC 4911 Encoding Instructions for RXER July 2007
2007年7月にRXERのために指示をコード化するLeggの実験的な[26ページ]RFC4911
(4) a BuiltinType that is a PrefixedType that is an
EncodingPrefixedType where the Type in the EncodingPrefixedType
is one of (1) to (4).
(4) (4)へのEncodingPrefixedTypeのTypeが1歳である(1)の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:
ベースはChoiceTypeのそれぞれの選択肢のタイプにタイプされます、すなわち、指示SHALL NOTをコード化するUNIONを条件として、いてください、:
(1) a CHOICE, SET, or SET OF type, or
または(1) CHOICE、SET、またはSET OFがタイプする。
(2) a SEQUENCE type other than the one defining the QName type from
the AdditionalBasicDefinitions module [RXER] (i.e., QName is
allowed), or
または(2) QNameを定義するもの以外のSEQUENCEタイプがAdditionalBasicDefinitionsモジュール[RXER]からタイプする、(すなわち、QNameは許容されています)。
(3) a SEQUENCE OF type where the SequenceOfType is not subject to a
LIST encoding instruction, or
または(3) SequenceOfTypeは指示をコード化するLISTを受けることがないSEQUENCE OFタイプ。
(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.
特定の識別子SHALL NOTは同じ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、ATTRIBUTE-REF、COMPONENT-REF、GROUP、ELEMENT-REF、REF-AS-ELEMENT、SIMPLE-CONTENT、またはTYPE-AS-バージョンを受けることがあるに違いないというわけではありません。
Example
例
[UNION PRECEDENCE basicName] CHOICE {
extendedName UTF8String,
basicName PrintableString
}
[組合先行basicName] 選択extendedName UTF8String、basicName PrintableString
22. The VALUES Encoding Instruction
22. 指示をコード化する値
The VALUES encoding instruction causes an RXER encoder to use nominated names instead of the identifiers that would otherwise appear in the encoding of a value of a BIT STRING, ENUMERATED, or INTEGER type.
RXERエンコーダが指示をコード化するのに使用するVALUESが識別子の代わりにそうでなければBIT STRINGの価値のコード化に現れる名前、ENUMERATEDを指名したか、またはINTEGERはタイプします。
Legg Experimental [Page 27] RFC 4911 Encoding Instructions for RXER July 2007
2007年7月にRXERのために指示をコード化するLeggの実験的な[27ページ]RFC4911
The notation for a VALUES encoding instruction is defined as follows:
指示をコード化するVALUESのための記法は以下の通り定義されます:
ValuesInstruction ::=
"VALUES" AllValuesMapped ? ValueMappingList ?
ValuesInstruction:、:= 「値」AllValuesMapped? ValueMappingList?
AllValuesMapped ::= AllCapitalized | AllUppercased
AllValuesMapped:、:= AllCapitalized| AllUppercased
AllCapitalized ::= "ALL" "CAPITALIZED"
AllCapitalized:、:= 「すべて」「大文字で書かれます」。
AllUppercased ::= "ALL" "UPPERCASED"
AllUppercased:、:= 「すべて」「大文字されます」。
ValueMappingList ::= ValueMapping ValueMappingList ?
ValueMappingList:、:= ValueMapping ValueMappingList?
ValueMapping ::= "," identifier "AS" NCNameValue
ValueMapping:、:= 「」、識別子“AS" NCNameValue
The Type in the EncodingPrefixedType for a VALUES encoding instruction SHALL be either:
指示SHALLをコード化するVALUESのためのEncodingPrefixedTypeのTypeは以下の通りです。
(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のTypeが1歳である(6)への(1)のTypeWithConstraintでないConstrainedType。
(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) (6)へのTaggedTypeのTypeが1歳である(1)の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) (6)へのEncodingPrefixedTypeのTypeが1歳である(1)の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.
この状態の効果は指示をコード化するVALUESがそれが適用される型定義で原文に共同見つけさせられることです。
The BitStringType, EnumeratedType, or IntegerType in case (1), (2), or (3), respectively, is said to be "subject to" the VALUES encoding instruction.
ケース(1)、(2)、または(3)のBitStringType、EnumeratedType、またはIntegerTypeが指示をコード化するVALUES「を条件として」、あるとそれぞれ言われています。
A BitStringType, EnumeratedType, or IntegerType SHALL NOT be subject to more than one VALUES encoding instruction.
BitStringType、EnumeratedType、またはIntegerType SHALL NOTを条件としているA、1つ以上のVALUESコード化指示。
Each identifier in a ValueMapping MUST be an identifier appearing in the NamedBitList, Enumerations, or NamedNumberList, as the case may be.
ValueMappingの各識別子は場合によってNamedBitList、Enumerations、またはNamedNumberListに現れる識別子であるに違いありません。
Legg Experimental [Page 28] RFC 4911 Encoding Instructions for RXER July 2007
2007年7月にRXERのために指示をコード化するLeggの実験的な[28ページ]RFC4911
The identifier in a ValueMapping SHALL NOT be the same as the identifier in any other ValueMapping for the same ValueMappingList.
識別子、ValueMapping SHALL NOTでは、同じ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.
}
信号:、:= 列挙されます[VALUESすべてのCAPITALIZED、赤いAS「赤」]。交換名はそうです。交換名はAmberです。赤--、REDこはく--緑色になってください--交換名はグリーンです。
23. Insertion Encoding Instructions
23. 指示をコード化する挿入
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コード化では、指示は指示をコード化する挿入として分類されます。 挿入コード化指示は、指示(記法はNoInsertionsInstruction、HollowInsertionsInstruction、SingularInsertionsInstruction、UniformInsertionsInstruction、およびMultiformInsertionsInstructionによってそれぞれ説明される)をコード化するINSERTIONSがなくて、HOLLOW-INSERTIONSと、SINGULAR-INSERTIONSと、UNIFORM-INSERTIONSと、MULTIFORM-INSERTIONSです。
The notation for the insertion encoding instructions is defined as follows:
指示をコード化する挿入のための記法は以下の通り定義されます:
Legg Experimental [Page 29] RFC 4911 Encoding Instructions for RXER July 2007
2007年7月にRXERのために指示をコード化するLeggの実験的な[29ページ]RFC4911
InsertionsInstruction ::=
NoInsertionsInstruction |
HollowInsertionsInstruction |
SingularInsertionsInstruction |
UniformInsertionsInstruction |
MultiformInsertionsInstruction
InsertionsInstruction:、:= NoInsertionsInstruction| HollowInsertionsInstruction| SingularInsertionsInstruction| UniformInsertionsInstruction| MultiformInsertionsInstruction
NoInsertionsInstruction ::= "NO-INSERTIONS"
NoInsertionsInstruction:、:= 「入がありません」
HollowInsertionsInstruction ::= "HOLLOW-INSERTIONS"
HollowInsertionsInstruction:、:= 「空洞の入」
SingularInsertionsInstruction ::= "SINGULAR-INSERTIONS"
SingularInsertionsInstruction:、:= 「まれな入」
UniformInsertionsInstruction ::= "UNIFORM-INSERTIONS"
UniformInsertionsInstruction:、:= 「一定の入」
MultiformInsertionsInstruction ::= "MULTIFORM-INSERTIONS"
MultiformInsertionsInstruction:、:= 「多様な入」
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.
広げることができるタイプでコンポーネントの指示をコード化するGROUPを使用するのは1拡大挿入ポイント以上に未知の拡大を関連づけることができた状況に通じることができます。 挿入コード化指示は、拡大が取ることができる形を制限することによって、このあいまいさを取り除きます。 すなわち、挿入コード化指示は、RXER encodingsのために壊れている下位互換なしでどんな拡大を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、またはSEQUENCEタイプへの拡大は、拡大で指示をコード化するGROUPとATTRIBUTEの潜在的使用のためゼロか以上が属性とゼロか、より多くの要素であると生成するでしょう。
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.
指示をコード化するMULTIFORM-INSERTIONSは、タイプへの前進コンパチブル拡大で生産されたRXER encodingsが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
指示をコード化するUNIFORM-INSERTIONSは、タイプへの前進コンパチブル拡大で生産されたRXER encodingsが同じ拡張名前と、ゼロかその他の属性を持っている1つ以上の要素からいつも成るのを示します。 拡張名前は共有しました。
Legg Experimental [Page 30] RFC 4911 Encoding Instructions for RXER July 2007
2007年7月にRXERのために指示をコード化するLeggの実験的な[30ページ]RFC4911
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".
要素に従って、特定のコード化は広げるのと同じくらいが名前であったなら必要でない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.
指示をコード化するSINGULAR-INSERTIONSは、タイプへの前進コンパチブル拡大で生産されたRXER encodingsがただ一つの要素とゼロか、より多くの属性からいつも成るのを示します。 ただ一つの要素の名前は、拡大のあらゆる可能なコード化で同じになるのに必要ではありません。
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.
指示をコード化するHOLLOW-INSERTIONSは、タイプへの前進コンパチブル拡大で生産されたRXER encodingsが零元とゼロか、より多くの属性からいつも成るのを示します。
The NO-INSERTIONS encoding instruction indicates that no forward- compatible extensions can be made to a type.
INSERTIONSがないコード化指示は、どんな前進のコンパチブル拡大もタイプに作ることができないのを示します。
Examples of forward-compatible extensions are provided in Appendix C.
前進コンパチブル拡大に関する例をAppendix Cに提供します。
The Type in the EncodingPrefixedType for an insertion encoding instruction SHALL be either:
指示SHALLをコード化する挿入のためのEncodingPrefixedTypeのTypeは以下の通りです。
(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のTypeが1歳である(5)への(1)のTypeWithConstraintでないConstrainedType。
(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) (5)へのTaggedTypeのTypeが1歳である(1)のTaggedTypeであるPrefixedTypeであるBuiltinType。
(5) a BuiltinType that is a PrefixedType that is an
EncodingPrefixedType where the Type in the EncodingPrefixedType
is one of (1) to (5).
(5) (5)へのEncodingPrefixedTypeのTypeが1歳である(1)のEncodingPrefixedTypeであるPrefixedTypeであるBuiltinType。
Case (2) is not permitted when the insertion encoding instruction is the SINGULAR-INSERTIONS, UNIFORM-INSERTIONS, or MULTIFORM-INSERTIONS encoding instruction.
指示をコード化する挿入が指示をコード化するSINGULAR-INSERTIONS、UNIFORM-INSERTIONS、またはMULTIFORM-INSERTIONSであるときに、ケース(2)は受入れられません。
Legg Experimental [Page 31] RFC 4911 Encoding Instructions for RXER July 2007
2007年7月にRXERのために指示をコード化するLeggの実験的な[31ページ]RFC4911
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タイプへの拡大が連続していて事実上任意であるので、指示をコード化するSINGULAR-INSERTIONS、UNIFORM-INSERTIONS、およびMULTIFORM-INSERTIONSが無制限な拡大(SETかSEQUENCEのための)より利点を全く示しません。 例えば、まれな入の任意のシリーズは、ゼロか以上が要素とゼロか、より多くの属性であると生成します、まさしく無制限な拡大のように。
The Type in case (1) or case (2) is said to be "subject to" the insertion encoding instruction.
場合(1)か場合(2)におけるTypeは指示をコード化する挿入「を条件として」、あると言われています。
The Type in case (1) or case (2) MUST be extensible, either explicitly or by default.
場合(1)か場合(2)におけるTypeは明らかかデフォルトで広げることができなければなりません。
A Type SHALL NOT be subject to more than one insertion encoding instruction.
Type SHALL NOT、1つ以上の挿入コード化命令を受けることがあってください。
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.
挿入コード化指示は、壊れている下位互換なしでどんな種類の拡大をタイプに作ることができるかを示しますが、それらは下位互換を壊す拡大を禁止しません。 すなわち、タイプに影響する指示をコード化する挿入を満たさないのは、タイプのベースタイプが拡大を含む誤りではありません。 しかしながら、いずれかであるなら、そのような拡大をして、次に、新しい値はSHOULDです。範囲が拡大を成就するバージョンインディケータ属性、または属性(セクション24を見る)のために広げることができる受入れられた値に導入してください。 Appendix Cに例を提供します。
24. The VERSION-INDICATOR Encoding Instruction
24. 指示をコード化するバージョンインディケータ
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).
バージョン-INDICATORコード化指示は、RXERデコーダがコード化が下位互換を壊す拡大を含む(先行するセクションを見る)と警告されるためにメカニズムを提供します。
The notation for a VERSION-INDICATOR encoding instruction is defined as follows:
指示をコード化するバージョン-INDICATORのための記法は以下の通り定義されます:
VersionIndicatorInstruction ::= "VERSION-INDICATOR"
VersionIndicatorInstruction:、:= 「バージョンインディケータ」
A NamedType that is subject to a VERSION-INDICATOR encoding instruction MUST also be subject to an ATTRIBUTE encoding instruction.
また、指示をコード化しながらバージョン-INDICATORを受けることがある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
バージョン-INDICATORコード化指示を受けることがあるNamedTypeのタイプは直接そうであるに違いありませんか間接的に、aが、受入れられた値のセットが定義されるタイプが広げることができるのを抑制しました。 各値はASN.1仕様の異なった見解を表します。 通常、アプリケーションはバージョンインディケータの値を設定するでしょう。
Legg Experimental [Page 32] RFC 4911 Encoding Instructions for RXER July 2007
2007年7月にRXERのために指示をコード化するLeggの実験的な[32ページ]RFC4911
attribute to be the last of these permitted values. An application MAY set the value of the version indicator attribute to the value corresponding to an earlier version of the specification if it has not used any of the extensions added in a subsequent version.
これらの最終である属性は値を可能にしました。 それがその後のバージョンで加えられた拡大のいずれも使用していないなら、アプリケーションは仕様の以前のバージョンに対応する値にバージョンインディケータ属性の値を設定するかもしれません。
If an RXER decoder encounters a value of the type that is not one of the root values or extension additions (but that is still allowed since the set of permitted values is extensible), then this indicates that the decoder is using a version of the ASN.1 specification that is not compatible with the version used to produce the encoding. In such cases, the decoder SHOULD treat the element containing the attribute as having an unknown ASN.1 type.
RXERデコーダが根の値か拡大追加の1つでないタイプの値に遭遇するなら(受入れられた値のセットが広げることができるので、それはまだ許容されています)、これは、デコーダがコード化を生産するのに使用されるバージョンと互換性がないASN.1仕様のバージョンを使用しているのを示します。 そのような場合、デコーダSHOULDは未知の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 encodingsに関して不一致を示すだけです。 指示をコード化するGROUPが彼らに適用しないので、他のencodingsは影響を受けません。
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
}
系列バージョン[ATTRIBUTE][バージョン-INDICATOR]INTEGER(2 1、…、.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コード化における、形式属性の値が使用しないならこの2番目の例では、デコーダが両立しない旧式のバージョンを使用している、「1インチ、「1.1インチ、または「2インチ。」
SEQUENCE {
format [ATTRIBUTE] [VERSION-INDICATOR]
UTF8String ("1.0", ..., "1.1" | "2.0"),
message MessageType
}
系列[ATTRIBUTE][バージョン-INDICATOR]UTF8Stringをフォーマットしてください、(「1インチ、…、「1.1インチ|、「2インチ)、メッセージMessageType、」
An extensive example is provided in Appendix C.
Appendix Cによく知られている例を提供します。
It is not necessary for every extensible type to have its own version indicator attribute. It would be typical for only the types of top-level element components to include a version indicator attribute, which would serve as the version indicator for all of the nested components.
すべての広げることができるタイプにはそれ自身のバージョンインディケータ属性があるのは必要ではありません。 トップレベル要素成分のタイプだけがバージョンインディケータ属性を入れるのは、典型的でしょう。(属性は入れ子にされたコンポーネントのすべてのためのバージョンインディケータとして機能するでしょう)。
Legg Experimental [Page 33] RFC 4911 Encoding Instructions for RXER July 2007
2007年7月にRXERのために指示をコード化するLeggの実験的な[33ページ]RFC4911
25. The GROUP Encoding Instruction
25. 指示をコード化するグループ
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.
指示をコード化するGROUPはRXERエンコーダにそれが要素としてカプセル化なしで適用されるコンポーネントの値をコード化させます。 それは要素含有量のための重要な満足しているモデルの構造を許容します。
The notation for a GROUP encoding instruction is defined as follows:
指示をコード化するGROUPのための記法は以下の通り定義されます:
GroupInstruction ::= "GROUP"
GroupInstruction:、:= 「分類してください」
The base type of the type of a NamedType that is subject to a GROUP encoding instruction SHALL be either:
指示SHALLをコード化するGROUPを受けることがあるNamedTypeのタイプのベースタイプは以下の通りです。
(1) a SEQUENCE, SET, or SET OF type, or
または(1) SEQUENCE、SET、またはSET OFがタイプする。
(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は指示をコード化するLISTを受けることがないSEQUENCE OFタイプ。
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.
SEQUENCEは関連が内蔵型のためのタイプであったならケース(1)SHALL NOTをタイプします、AdditionalBasicDefinitionsモジュール[RXER]からのタイプであり、SHALL NOT。SHALL NOTは指示をコード化するSIMPLE-CONTENTを条件としているコンポーネントを含んでいます。
Aside: Thus, the CHARACTER STRING, EMBEDDED PDV, EXTERNAL, REAL,
and QName types are excluded.
傍らに: したがって、CHARACTER STRING、EMBEDDED PDV、EXTERNAL、レアル、およびQNameタイプは遮断されます。
The CHOICE type in case (2) SHALL NOT be a type from the AdditionalBasicDefinitions module.
CHOICEはAdditionalBasicDefinitionsからのタイプがモジュールであったならケース(2)SHALL NOTをタイプします。
Aside: Thus, the Markup type is excluded.
傍らに: したがって、Markupタイプは遮断されます。
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、SEQUENCE OF、またはSET OF)が結合のコンポーネントのセットであるということであるタイプにおいて、目に見えるコンポーネントはそのうえ、定義をタイプします、指示をコード化するGROUPを受けることがあるそれぞれのNamedType(結合型定義の)のために、NamedTypeのタイプにおいて、目に見えるコンポーネント。 COMPONENTS OF変換がX.680、Clause24.4[X.680]で指定した後に目に見えるコンポーネントは決定しています。
Legg Experimental [Page 34] RFC 4911 Encoding Instructions for RXER July 2007
2007年7月にRXERのために指示をコード化するLeggの実験的な[34ページ]RFC4911
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 encodingsに現れる属性と子供要素について説明するタイプ、およびどんな入れ子にされたタイプのすべての成分のセットです。
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.
傍らに: 指示をコード化するGROUPを条件としたコンポーネントはグループ定義としてコンパチブルXML Schema[XSD1]に翻訳されるかもしれません。 それ自身のタイプにおいて、目に見えるNamedTypeは円形のグループに類似しています。(XML Schemaはそれを禁じます)。
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.
指示をコード化するGROUPをどんな使用でも、包含は、タイプがあるのをタイプして、それは指示、およびタイプ、含まれているタイプ、すなわち、そのコンポーネントのベースタイプをコード化するGROUPを条件としてコンポーネントを含んでいます。 タイプは、直接ASN.1伸展性を使用するか、または別のGROUPコード化指示である他の広げることができるタイプを含んでいることによって、広げることができる満足しているモデルを持つことができます。
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.
含んでいて含まれているタイプはその場合、.1のモジュール、包含の所有者がすなわち、人か組織に含んでいるタイプの定義に拡大を加える権威がある場合異なるかもしれないのをタイプする含まれているタイプの所有者と異なったASNで定義されるかもしれません。
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.
包含に加えるかもしれない次に、含まれているタイプの定義の最新のバージョン、包含の所有者が拡大をタイプするタイプが使用していない包含の所有者がタイプするなら、それは、含まれているタイプの旧式のバージョンに関して有効ですが、後で含んでいて含まれている型定義の最新版が集められるとき(恐らく第三者で)、無効であることがわかっています。 含んでいるタイプの所有者は必ず含まれているタイプの存在を知らなければなりませんが、逆は必ず本当であるというわけではありません。 他の誰かのものを無効にするのを知っているのがタイプを含んでいなくて、含まれているタイプの所有者は含まれているタイプに拡大を追加できました。
Legg Experimental [Page 35] RFC 4911 Encoding Instructions for RXER July 2007
2007年7月にRXERのために指示をコード化するLeggの実験的な[35ページ]RFC4911
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) 承認されて、発行される前にすべての変化が一般的な第三者によって診察されるでしょう。
25.1. Unambiguous Encodings
25.1. 明白なEncodings
Unregulated use of the GROUP encoding instruction can easily lead to specifications in which distinct abstract values have indistinguishable RXER encodings, i.e., ambiguous encodings. This section imposes restrictions on the use of the GROUP encoding instruction to ensure that distinct abstract values have distinct RXER encodings. In addition, these restrictions ensure that an abstract value can be easily decoded in a single pass without back-tracking.
指示をコード化するGROUPの調節されない使用は容易に異なった抽象的な値が区別できないRXER encodingsを持っている仕様につながることができます、すなわち、あいまいなencodings。 このセクションは異なった抽象的な値には異なったRXER encodingsがあるのを保証するために指示をコード化する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 文法として指示をコード化するGROUPを条件としてコンポーネントを含む型定義を書き直すための手順について説明します。 セクション25.1.2と.3が指定する25.1はそれを条件とさせます。
Legg Experimental [Page 36] RFC 4911 Encoding Instructions for RXER July 2007
2007年7月にRXERのために指示をコード化するLeggの実験的な[36ページ]RFC4911
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には、よく知られている例があります。
25.1.1. Grammar Construction
25.1.1. 文法工事
A grammar consists of a collection of productions. A production has a left-hand side and a right-hand side (in this document, separated by the "::=" symbol). The left-hand side (in a context-free grammar) is a single non-terminal symbol. The right-hand side is a sequence of non-terminal and terminal symbols. The terminal symbols are the lexical items of the language that the grammar describes. One of the non-terminals is nominated to be the start symbol. A valid sequence of terminals for the language can be generated from the grammar by beginning with the start symbol and repeatedly replacing any non-terminal with the right-hand side of one of the productions where that non-terminal is on the production's left-hand side. The final sequence of terminals is achieved when there are no remaining non-terminals to replace.
文法は創作の収集から成ります。 「生産には左側と右側がある、(切り離されたこのドキュメント、」 : : =、」、シンボル) 左側(文脈自由文法の)はただ一つの非終端記号です。 右側は非端末の、そして、端末のシンボルの系列です。 終端記号は文法が説明する言語の語彙項目です。 非端末の1つは開始記号であることが指名されます。 文法から開始記号で始まることによって発生できて、そんなに非端末であるところで繰り返してどんな非端末も創作の1つの右側に取り替える言語のための端末の有効な系列が生産の左側にあります。 取り替える残っている非端末が全くないとき、端末の最終的な系列は達成されます。
Aside: X.680 describes the ASN.1 basic notation using a
context-free grammar.
傍らに: X.680は、文脈自由文法を使用することでASN.1の基本的な記法を説明します。
Each NamedType has an associated primary and secondary non-terminal.
各NamedTypeには、関連第一の、そして、二次の非端末があります。
Aside: The secondary non-terminal for a NamedType is used when the
base type of the type in the NamedType is a SEQUENCE OF type or
SET OF type.
傍らに: NamedTypeのタイプのベースタイプがSEQUENCE OFタイプであるかSET OFがタイプするとき、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の例のための非端末が1ユーロ、2ユーロ、3ユーロなどであり、I1、I2、I3などであるためには非端末の第一の始めに。 二次非端末がaを追加することによってラベルされる、「'「第一の非端末ラベルへのキャラクタ、例えば、第一の、そして、二次のスタート非端末は、それぞれSとS'です。」
Legg Experimental [Page 37] RFC 4911 Encoding Instructions for RXER July 2007
2007年7月にRXERのために指示をコード化するLeggの実験的な[37ページ]RFC4911
Each NamedType and extension insertion point has an associated terminal. There exists a terminal called the general extension terminal that is not associated with any specific notation. The general extension terminal and the terminals for the extension insertion points are used to represent elements in unknown extensions. The exact nature of the terminals is not important; however, the aforementioned terminals MUST be mutually distinct. The terminals are further categorized as either element terminals or attribute terminals. A terminal for a NamedType is an attribute terminal if its associated NamedType is an attribute component; otherwise, it is an element terminal. The general extension terminal and the terminals for the extension insertion points are categorized as element terminals.
各NamedTypeと拡大挿入ポイントには、関連端末があります。 どんな特定の記法にも関連づけられない一般的な拡大端末と呼ばれる端末は存在しています。 一般的な拡大端末と拡大挿入ポイント単位で端末は、未知の拡大で要素を表すのに使用されます。 端末の正確な本質は重要ではありません。 しかしながら、前述の端末は互いに異なっていなければなりません。 端末は要素端末か属性端末のどちらかとしてさらに分類されます。 関連NamedTypeが属性コンポーネントであるなら、NamedTypeのための端末は属性端末です。 さもなければ、それは要素端末です。 一般的な拡大端末と拡大挿入ポイント単位で端末は要素端末として分類されます。
Terminals for attributes in unknown extensions are not explicitly provided in the grammar. Certain productions in the grammar are categorized as insertion point productions, and their role in accepting unknown attributes is described in Section 25.1.4.
未知の拡大における属性のための端末は明らかに文法に提供されません。文法のある創作は挿入ポイント創作として分類されます、そして、未知の属性を受け入れることにおけるそれらの役割はセクション25.1.4で説明されます。
In the examples in this document, the terminal for a component other than an attribute component will be represented as the local name of the expanded name of the component enclosed in double quotes, and the terminal for an attribute component will be represented as the local name of the expanded name of the component prefixed by the '@' character and enclosed in double quotes. The general extension terminal will be represented as "*" and the terminals for the extension insertion points will be represented as "*1", "*2", "*3", and so on.
このドキュメントの例では、属性コンポーネント以外のコンポーネントのための端末は二重引用符に同封されたコンポーネントの拡張名前の地方名として表されるでしょう、そして、属性コンポーネントのための端末は'@'キャラクタによって前に置かれていて、二重引用符に同封されたコンポーネントの拡張名前の地方名として表されるでしょう。 「拡大挿入ポイント単位で「*」と端末が」 *として」 1インチと、*2インチ表されるように一般的な拡大端末は表され」、*3インチなど。
The productions generated from a NamedType depend on the base type of the type of the NamedType. The productions for the start non-terminals depend on the combining type definition being tested. In either case, the procedure for generating productions takes a primary non-terminal, a secondary non-terminal (sometimes), and a type definition.
NamedTypeから発生する創作はNamedTypeのタイプのベースタイプに頼っています。 スタート非端末が結合であることによるので、創作はテストされる定義をタイプします。 どちらの場合ではも、創作を発生させるための手順は第一の非端末、(時々)二次非端末、および型定義を取ります。
The grammar is constructed beginning with the start non-terminals and the combining type definition being tested.
文法は、始めで非端末とテストされる結合型定義を始めながら、構成されます。
A grammar is constructed after the COMPONENTS OF transformation specified in X.680, Clause 24.4 [X.680].
COMPONENTS OF変化がX.680、Clause24.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:
第一の非端末、N、およびベースタイプがSEQUENCEであるかSETがタイプするタイプを考えて、生産はNと共に左側として文法に追加されます。 整然とすると考えられた以下のケースによると、右側は初期の人影のない状態から構成されます:
Legg Experimental [Page 38] RFC 4911 Encoding Instructions for RXER July 2007
2007年7月にRXERのために指示をコード化するLeggの実験的な[38ページ]RFC4911
(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.
(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例がベースタイプで空であるか、または存在していなくて、またベースタイプが広げることができて(明らかかデフォルトで)、ベースタイプはいいえ-INSERTIONSか指示をコード化するHOLLOW-INSERTIONSを受けることがないなら、ベースタイプの拡大挿入ポイント単位で非端末を右側に追加します。
(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例がベースタイプで空であるか、または存在していないなら、生産は挿入ポイント生産です、そして、ベースタイプは広げることができます、そして、(明らかかデフォルトで)ベースタイプは、指示をコード化しながら、INSERTIONSがないのを受けることがありません。
If a component in a ComponentTypeList (in either a RootComponentTypeList or an ExtensionAdditionGroup) is marked OPTIONAL or DEFAULT, then a production with the primary non-terminal of the component as the left-hand side and an empty right-hand side is added to the grammar.
ComponentTypeList(RootComponentTypeListかExtensionAdditionGroupのどちらかの)のコンポーネントが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を受けることがあるなら、コンポーネントのタイプに従って構成された1つ以上の創作が文法に追加されます。それぞれのこれらの創作には、左側としてコンポーネントの第一の非端末があります。
If a component (regardless of the ASN.1 combining type containing it) is not subject to a GROUP encoding instruction, then a production is added to the grammar with the primary non-terminal of the component as the left-hand side and the terminal of the component as the right-hand side.
コンポーネント(それを含むタイプを結合するASN.1にかかわらず)は指示をコード化するGROUPを受けることがないなら、右手としてのコンポーネントの左側と端末に面があるとき、生産はコンポーネントの第一の非端末で文法に追加されます。
Legg Experimental [Page 39] RFC 4911 Encoding Instructions for RXER July 2007
2007年7月にRXERのために指示をコード化するLeggの実験的な[39ページ]RFC4911
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.
}
系列--初期のRootComponentTypeListある[ATTRIBUTE]UTF8String、2BOOLEAN OPTIONAL、3INTEGERを始動してください--初期のRootComponentTypeListの端
Here is the grammar derived from this type:
ここに、このタイプから得られた文法があります:
S ::= one two three
one ::= "@one"
two ::= "two"
two ::=
three ::= "three"
S:、:= 1 2 3 1つ:、:= 「@1」2:、:= 「2」時2分:、:= 3:、:= 「3」
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.
各ExtensionAddition(SEQUENCEかSETベースタイプの)に関しては、生産は左側がExtensionAdditionのための非端末である文法に追加されます、そして、右側は初めは、人影がありません。 ExtensionAdditionがComponentTypeであるなら、ComponentTypeのNamedTypeのための第一の非端末を右側に追加します。 そうでなければ、(ExtensionAdditionGroup)、ExtensionAdditionGroupのComponentTypeListで入れ子にされたコンポーネントのための第一の非端末の系列を彼らの定義の注文における右側に追加します。 別のExtensionAdditionがExtensionAdditionに続くなら、次のExtensionAdditionのための非端末を右側に追加します。 さもなければ、ベースタイプはいいえ-INSERTIONSか指示をコード化するHOLLOW-INSERTIONSを受けることがないなら、ベースタイプの拡大挿入ポイント単位で非端末を右側に追加します。 ExtensionAdditionが別のExtensionAdditionによって続かれていなくて、またベースタイプは指示をコード化しながらINSERTIONSがないのを受けることがないなら、生産が挿入ポイント生産です。 端末の空の系列が生産から発生できないなら(この決断をする前に、それがそうでなければ、文法が完全になるまで待つのに必要であるかもしれません)、別の生産は左側が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仕様の以前のバージョンを使用しているかもしれないので、事実上、拡大はいつも任意です。
Legg Experimental [Page 40] RFC 4911 Encoding Instructions for RXER July 2007
2007年7月にRXERのために指示をコード化するLeggの実験的な[40ページ]RFC4911
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であるなら、ベースタイプは、広げることができて(明らかかデフォルトで)、いいえ-INSERTIONSか指示をコード化するHOLLOW-INSERTIONSを受けることがありません、そして:
(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
}
系列拡大挿入ポイントがここにあります。--、2INTEGER OPTIONAL、ブールで初期のRootComponentTypeList1つを始めてください--初期のRootComponentTypeListの端--ExtensionAdditions4INTEGER--ExtensionAddition(1E)最初に、5BOOLEAN OPTIONAL--第2ExtensionAddition(2E)の始まり[--ExtensionAdditionGroup6UTF8String、7INTEGER OPTIONAL] --第3ExtensionAddition(3E)--ExtensionAdditionsの端、--、(I1) --最終的なRootComponentTypeListを始動してください、3INTEGER
Here is the grammar derived from this type:
ここに、このタイプから得られた文法があります:
S ::= one two E1 three
S:、:= 1つ2E1 3
E1 ::= four E2
E1 ::=
1E:、:= 2ユーロの4E1:、:=
Legg Experimental [Page 41] RFC 4911 Encoding Instructions for RXER July 2007
2007年7月にRXERのために指示をコード化するLeggの実験的な[41ページ]RFC4911
E2 ::= five E3
E3 ::= six seven I1
E3 ::=
2E:、:= 3ユーロの5E3:、:= 6 7I1E3:、:=
I1 ::= "*" I1
I1 ::=
I1:、:= 「*」I1 I1:、:=
one ::= "one"
two ::= "two"
two ::=
three ::= "three"
four ::= "four"
five ::= "five"
five ::=
six ::= "six"
seven ::= "seven"
seven ::=
1:、:= 「1」時2分:、:= 「2」時2分:、:= 3:、:= 「3」時4分:、:= 「4」時5分:、:= 「5」時5分:、:= 6:、:= 「6」時7分:、:= 「7」時7分:、:=
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タイプはいいえ-INSERTIONSか指示をコード化するHOLLOW-INSERTIONSを受けることがあるなら、I1のための創作が現れないでしょうに、そして、3Eのための最初の生産があるでしょう:
E3 ::= six seven
3E:、:= 6時7分
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) 生産はベースタイプの各ExtensionAdditionAlternativeのために文法に追加されます。(そこでは、左の手の側がNであり、右側は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.
(a) 生産は左側がNであり、右側がベースタイプの拡大挿入ポイント単位で非端末である文法に追加されます。 この生産は挿入ポイント生産です。
Legg Experimental [Page 42] RFC 4911 Encoding Instructions for RXER July 2007
2007年7月にRXERのために指示をコード化するLeggの実験的な[42ページ]RFC4911
(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) ベースタイプは指示をコード化するHOLLOW-INSERTIONSを受けることがあるなら、生産が左側が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) ベースタイプは指示をコード化するSINGULAR-INSERTIONSを受けることがあるなら、生産が左側がNである文法に追加されます、そして、右側は一般的な拡大端末です。 この生産は挿入ポイント生産です。
(6) If the base type is subject to a UNIFORM-INSERTIONS encoding
instruction, then:
(6) ベースタイプは次に指示をコード化するUNIFORM-INSERTIONSを受けることがあるなら:
(a) A production is added to the grammar where the left-hand side
is N and the right-hand side is the general extension
terminal.
(a) 生産は左側がNであり、右側が一般的な拡大端末である文法に追加されます。
Aside: This production is used to verify the correctness
of an ASN.1 type definition, but would not be used in the
implementation of an RXER decoder. The next production
takes precedence over it for accepting an unknown element.
傍らに: この生産は、ASN.1型定義の正当性について確かめるのに使用されますが、RXERデコーダの実現では使用されないでしょう。 次の生産は、未知の要素を受け入れるためにそれの上で優先します。
(b) A production is added to the grammar where the left-hand side
is N and the right-hand side is the terminal for the
extension insertion point of the base type followed by the
non-terminal for the extension insertion point. This
production is an insertion point production.
(b) 生産は左側がNであり、右側が非端末が拡大挿入ポイントに支えたベースタイプの拡大挿入ポイント単位で端末である文法に追加されます。 この生産は挿入ポイント生産です。
(c) A production is added to the grammar where the left-hand side
is the non-terminal for the extension insertion point of the
base type and the right-hand side is the terminal for the
extension insertion point followed by the non-terminal for
the extension insertion point.
(c) 生産は左側がベースタイプの拡大挿入ポイント単位で非端末であり、右側が非端末が拡大挿入ポイントに支えた拡大挿入ポイント単位で端末である文法に追加されます。
(d) A production is added to the grammar where the left-hand side
is the non-terminal for the extension insertion point of the
base type and the right-hand side is empty.
(d) 生産は左側がベースタイプの拡大挿入ポイント単位で非端末であり、右側が人影がない文法に追加されます。
Legg Experimental [Page 43] RFC 4911 Encoding Instructions for RXER July 2007
2007年7月にRXERのために指示をコード化するLeggの実験的な[43ページ]RFC4911
(7) If the base type is subject to a MULTIFORM-INSERTIONS encoding
instruction, then:
(7) ベースタイプは次に指示をコード化するMULTIFORM-INSERTIONSを受けることがあるなら:
(a) A production is added to the grammar where the left-hand side
is N and the right-hand side is the general extension
terminal followed by the non-terminal for the extension
insertion point of the base type. This production is an
insertion point production.
(a) 生産は左側がNであり、非端末がベースタイプの拡大挿入ポイントに右側をいうことになった一般的な拡大端末である文法に追加されます。 この生産は挿入ポイント生産です。
(b) A production is added to the grammar where the left-hand side
is the non-terminal for the extension insertion point of the
base type and the right-hand side is the general extension
terminal followed by the non-terminal for the extension
insertion point.
(b) 生産は左側がベースタイプの拡大挿入ポイント単位で非端末であり、非端末が拡大挿入ポイントに右側をいうことになった一般的な拡大端末である文法に追加されます。
(c) A production is added to the grammar where the left-hand side
is the non-terminal for the extension insertion point of the
base type and the right-hand side is empty.
(c) 生産は左側がベースタイプの拡大挿入ポイント単位で非端末であり、右側が人影がない文法に追加されます。
If an ExtensionAdditionAlternative is a NamedType, then a production is added to the grammar where the left-hand side is the non-terminal for the ExtensionAdditionAlternative and the right-hand side is the primary non-terminal for the NamedType.
ExtensionAdditionAlternativeがNamedTypeであるなら、生産は左側が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であるなら、生産はExtensionAdditionAlternativesGroupで入れ子にされた各NamedTypeのために文法に追加されます。そこでは、左側がExtensionAdditionAlternativeのための非端末であり、右側はNamedTypeのための第一の非端末です。
Legg Experimental [Page 44] RFC 4911 Encoding Instructions for RXER July 2007
2007年7月にRXERのために指示をコード化するLeggの実験的な[44ページ]RFC4911
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).
}
選択--、2INTEGER、ブールでRootAlternativeTypeList1つを始めてください--RootAlternativeTypeListの端… 最初の--ExtensionAdditionAlternatives3INTEGERの始まり--ExtensionAdditionAlternative(1E)[--ExtensionAdditionAlternativesGroup4UTF8String、5INTEGER] --第2ExtensionAdditionAlternative(2E)--拡大挿入ポイントがここ(I1)にあります。
Here is the grammar derived from this type:
ここに、このタイプから得られた文法があります:
S ::= one
S ::= two
S ::= E1
S ::= E2
S ::= I1
S:、:= 1つS:、:= 2:、:= E1 S:、:= E2 S:、:= I1
I1 ::= "*" I1
I1 ::=
I1:、:= 「*」I1 I1:、:=
E1 ::= three
E2 ::= four
E2 ::= five
1E:、:= 3E2:、:= 4E2:、:= 5
one ::= "one"
two ::= "two"
three ::= "three"
four ::= "four"
five ::= "five"
1:、:= 「1」時2分:、:= 「2」時3分:、:= 「3」時4分:、:= 「4」時5分:、:= 「5」
If the CHOICE type were subject to a NO-INSERTIONS encoding
instruction, then the fifth, sixth, and seventh productions would
be removed.
CHOICEタイプは指示をコード化しながらどんなINSERTIONSも受けることがないなら、5番目、6番目、および7番目の創作は取り除かれるでしょうに。
If the CHOICE type were subject to a HOLLOW-INSERTIONS encoding
instruction, then the fifth, sixth, and seventh productions would
be replaced by:
CHOICEタイプは指示をコード化するHOLLOW-INSERTIONSを受けることがあるなら、5番目、6番目、および7番目の創作を以下に取り替えるでしょうに。
Legg Experimental [Page 45] RFC 4911 Encoding Instructions for RXER July 2007
2007年7月にRXERのために指示をコード化するLeggの実験的な[45ページ]RFC4911
S ::=
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タイプは指示をコード化するSINGULAR-INSERTIONSを受けることがあるなら、5番目、6番目、および7番目の創作を以下に取り替えるでしょうに。
S ::= "*"
S:、:= "*"
If the CHOICE type were subject to a UNIFORM-INSERTIONS encoding
instruction, then the fifth and sixth productions would be
replaced by:
CHOICEタイプは指示をコード化するUNIFORM-INSERTIONSを受けることがあるなら、5番目と6番目の創作を以下に取り替えるでしょうに。
S ::= "*"
S ::= "*1" I1
S:、:= 「*」S:、:= 「*の1インチのI1」
I1 ::= "*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タイプは指示をコード化するMULTIFORM-INSERTIONSを受けることがあるなら、5番目の生産を以下に取り替えるでしょうに。
S ::= "*" I1
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、およびSEQUENCE OFかSET OFベースをタイプさせて、サイズの値を可能にするタイプを考えて、(すなわち、空の系列かセット)のゼロを合わせてください:
(1) a production is added to the grammar where the left-hand side of
the production is N and the right-hand side is the primary
non-terminal for the NamedType of the component of the
SEQUENCE OF or SET OF base type, followed by N, and
そして(1) 生産が生産の左側がNである文法に追加されて、右側がNがいうことになった第一のSEQUENCE OFかSET OFの部品の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 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:
'第一の非端末を考えて、N、二次非端末、N'、およびSEQUENCE OFかSET OFベースをタイプさせて、サイズの値を可能にしないタイプは以下のゼロに合っています。
Legg Experimental [Page 46] RFC 4911 Encoding Instructions for RXER July 2007
2007年7月にRXERのために指示をコード化するLeggの実験的な[46ページ]RFC4911
(1) a production is added to the grammar where the left-hand side of
the production is N and the right-hand side is the primary
non-terminal for the NamedType of the component of the
SEQUENCE OF or SET OF base type, followed by N', and
そして'(1) 生産が生産の左側がNである文法に追加されて、右側がN'がいうことになった第一のSEQUENCE OFかSET OFの部品の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である文法に追加され'て、右側がN'がいうことになった第一のSEQUENCE OFかSET OFの部品のNamedTypeにおける非端末のベースタイプである。
(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
SEQUENCE SIZE(1..MAX)OF番号INTEGER
Here is the grammar derived from this type:
ここに、このタイプから得られた文法があります:
S ::= number S'
S' ::= number S'
S' ::=
S:、:= 数SのS:、:= 数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)がサイズゼロの値がSEQUENCE OFによって可能にされるか、またはSET OFがタイプするかを決める目的のために無視されます。
This completes the description of the transformation of ASN.1 combining type definitions into a grammar.
これは型定義を文法に結合するASN.1の変化の記述を終了します。
25.1.2. Unique Component Attribution
25.1.2. ユニークなコンポーネント属性
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は非端末が左の方に文法によって使用される生産の右側に載っています。
Legg Experimental [Page 47] RFC 4911 Encoding Instructions for RXER July 2007
2007年7月にRXERのために指示をコード化するLeggの実験的な[47ページ]RFC4911
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が1以上の右側生産のときに非端末が左の方に文法によって使用されるところに現れる。
(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:
指示をコード化するGROUPを受けることがあるコンポーネントを含んでいるベースタイプがあるすべてのASN.1タイプのために、本書では説明された方法で引き出された文法は以下を持ってはいけません。
(1) two or more primary non-terminals that are used by the grammar
and are associated with element components having the same
expanded name, or
または(1) 2台以上の文法によって使用された、同じくらい持っている要素成分に関連している第一の非端末が名前を広げた。
(2) two or more primary non-terminals that are used by the grammar
and are associated with attribute components having the same
expanded name, or
または(2) 2台以上の文法によって使用された、同じくらい持っている属性コンポーネントに関連している第一の非端末が名前を広げた。
(3) a primary non-terminal that has multiple derivation paths and is
associated with an attribute component.
(3) 複数の派生経路を持っている、属性コンポーネントに関連している第一の非端末。
Aside: Case (1) is in response to component referencing notations
that are evaluated with respect to the XML encoding of an abstract
value. Case (1) guarantees, without having to do extensive
testing (which would necessarily have to take account of encoding
instructions for all other encoding rules), that all sibling
elements with the same expanded name will be associated with
equivalent type definitions. Such equivalence allows a component
referenced by element name to be re-encoded using a different set
of ASN.1 encoding rules without ambiguity as to which type
definition and encoding instructions apply.
傍らに: ケース(1)は抽象的な価値のXMLコード化に関して評価される記法に参照をつけるコンポーネントに対応しています。 大規模なテスト(必ず規則をコード化しながら、すべてのための他のコード化指示を考慮に入れなければならない)をする必要はなくて、ケース(1)は、同じくらいが広げられている要素が命名するすべての兄弟が同等な型定義に関連するのを保証します。 そのような等価性は、要素名によって参照をつけられるコンポーネントが再コード化されるのを型定義と指示をコード化するのが適用されるあいまいさなしで異なったASN.1符号化規則を使用することで許容します。
Cases (2) and (3) ensure that an attribute name is always uniquely
associated with one component that can occur at most once and is
always nested in the same part of an abstract value.
ケース(2)と(3)は、属性名がいつも唯一高々一度起こることができる1つのコンポーネントに関連づけられて、抽象的な価値の同じ一部分でいつも入れ子にされるのを確実にします。
Legg Experimental [Page 48] RFC 4911 Encoding Instructions for RXER July 2007
2007年7月にRXERのために指示をコード化するLeggの実験的な[48ページ]RFC4911
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
}
バイバイ:、:= 系列[GROUP]TB、b[GROUP]CHOICE、[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、[ATTRIBUTE]OBJECT IDENTIFIER、b INTEGER、e[NAME AS「c」]INTEGER、COMPONENTS OF TD
TB ::= SEQUENCE {
a INTEGER,
b [ATTRIBUTE] BOOLEAN,
COMPONENTS OF TC
}
Tb:、:= 系列INTEGERの、そして、b[ATTRIBUTE]ブールのCOMPONENTS OF TC
TC ::= SEQUENCE {
f OBJECT IDENTIFIER
}
Tc:、:= 系列fオブジェクト識別子
TD ::= SEQUENCE {
g OBJECT IDENTIFIER
}
TD:、:= 系列gオブジェクト識別子
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.
COMPONENTS OF変換を実行した後に、TAのための文法は構成されます。 この変換の結果は次に、示されます。 この例はそのNamedTypeのためにプライマリ非端末を表すのにまさしくNamedTypeに関する識別子を使用する普通のコンベンションから出発するでしょう。 一番はずれのタイプに比例したラベルは、ユニークなコンポーネント属性をよりよく例証するのに代わりに使用されるでしょう。 非端末に使用されるラベルは右側の下側に案内されます。
Legg Experimental [Page 49] RFC 4911 Encoding Instructions for RXER July 2007
2007年7月にRXERのために指示をコード化するLeggの実験的な[49ページ]RFC4911
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
}
バイバイ:、:= 系列[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
}
Tb:、:= 系列TB.a b[ATTRIBUTE]ブール(TB.b f OBJECT IDENTIFIER)のINTEGER、TB.f
-- Type TC is no longer of interest. --
-- タイプTCはもう興味がありません。 --
TD ::= SEQUENCE {
g OBJECT IDENTIFIER -- TD.g
}
TD:、:= 系列gオブジェクト識別子--、TD.g
The associated grammar is:
関連文法は以下の通りです。
S ::= TA.a TA.b TA.c TA.d TA.e TA.g
S:、:= TA.a TA.b TA.c TA.d TA.e TA.g
TA.a ::= TB.a TB.b TB.f
TA.a:、:= TB.a TB.b TB.f
TB.a ::= "a"
TB.b ::= "@b"
TB.f ::= "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:、:= 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
Legg Experimental [Page 50] RFC 4911 Encoding Instructions for RXER July 2007
2007年7月にRXERのために指示をコード化するLeggの実験的な[50ページ]RFC4911
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"
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"
TD.g:、:= 「g」
TA.c ::= "@c"
TA.c:、:= "@c"
TA.d ::= TA.d.a TA.d
TA.d ::=
TA.d:、:= TA.d.a TA.d TA.d:、:=
TA.d.a ::= TA.d.a.a TA.d.a.b
TA.d.a:、:= TA.d.a.はTA.d.a.bです。
TA.d.a.a := "@a"
TA.d.a.b ::= "b"
TA.d.a.:="@a"TA.d.a.b:、:= 「b」
TA.e ::= "c"
TA.e:、:= 「c」
TA.g ::= "g"
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つのインスタンスが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)では、NamedType記法の同じインスタンスからTD.gとTA.gを得ますが、COMPONENTS OF変換に続いて、異なったコンポーネントになってください。 COMPONENTS OF変換としたがって、タイプが同等にならなかったつもりであった後にAUTOMATICタグ付けは適用されています。変換は、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").
また、1つのインスタンスが2台以上のプライマリ非端末が同じ拡張名前を持っている属性コンポーネントに関連しているところにあるので、TAのための型定義も無効です: TA.b.bとTA.c(ともに、端末の"@c"を生成します)。
Legg Experimental [Page 51] RFC 4911 Encoding Instructions for RXER July 2007
2007年7月にRXERのために指示をコード化するLeggの実験的な[51ページ]RFC4911
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.a.のTA.d、TA.d.a、a、TA.d.a.b、TB.a、TB.b、およびTB.f。 また、TA.d.a.のaとTB.bが属性コンポーネントに関連しているプライマリ非端末であるので、TAのための型定義も無効です。
25.1.3. Deterministic Grammars
25.1.3. 決定論的な文法
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のFirst Setをさせてください、とFirst(P)は指示して、Tが最初の要素であるすべての要素端末TのセットがP.の右側から生成することができる端末の系列で端末であったなら、Thereは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のFollow Setをさせてください、とFollow(N)は指示しました、すべての要素端末のセットがTが次々にNに続く非端末と文法から生成することができる端末の最初の要素端末であるTであったなら。どんな要素端末もNを支えていなくて、次に、またFollow(N)が「$」指示された特別な端の端末を含む文法から非端末と端末の系列を生成することができるNとT.Ifの間には、いろいろな属性端末があることができます。
Aside: If N does not appear on the right-hand side of any
production, then Follow(N) will be empty.
傍らに: Nがどんな生産の右側にも載っていないと、Follow(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のために、述部Empty(P)が本当にさせてください、P.Otherwiseから端末の空の系列を生成することができる場合にだけ、Empty(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のために、述部Preselected(P)が本当にさせてください、Pの右側からベース文法だけを使用することで生成することができる端末のあらゆる系列が少なくとも1つを含む場合にだけ、端末を結果と考えてください。 さもなければ、Preselected(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).
Select(P)は、Preselected(P)が本当であるなら生産PのSelect Setが空であることを指示しました。 さもなければ、それはFirst(P)を含んでいます。 NがP.If Empty(P)の左側の上の非端末が本当である、次に、また、Select(P)がFollow(N)を含んでいるということであることをさせてください。
Legg Experimental [Page 52] RFC 4911 Encoding Instructions for RXER July 2007
2007年7月にRXERのために指示をコード化するLeggの実験的な[52ページ]RFC4911
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.
傍らに: 属性が要素に関する開始タグの中の順不同の、子供要素で点在していないようにほんとうは見えるので、文法が示すように文法に属性コンポーネントを含んでいるのはいくらか疑わしく見えるかもしれません。 これは属性端末がFirst SetsとFollow Setsを構成する際に無視される理由です。 しかしながら、属性端末は彼らが、生産を前選択できて、生産が端末の空の系列を生成することができるのを防ぐことができるのでSelect Setsを構成するのにおいて重要です。 実物称呼で、これは任意のコンポーネントの存在か欠如を決定して、間にCHOICEの代替手段を選択するのに属性を使用する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のReach Setをさせてください、とReach(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.
傍らに: それは彼らの省略がPreselectedとEmptyのFirst、Follow、Select、Reach Sets、または評価を変更しないので文法を構成する際に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) 2つの創作PとQは存在していません、同じ非端末がSelect(P)とSelect(Q)の交差点が人影がなくない左側にある状態で。
(2) there does not exist a non-terminal E for an ExtensionAddition or
ExtensionAdditionAlternative where the intersection of Reach(E)
and Follow(E) is not empty.
(2) Reach(E)とFollow(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仕様の以前のバージョンを使用するデコーダは未知(そのデコーダへの)の拡大で拡大に続く知られているコンポーネントに要素を混乱させるでしょう。
Legg Experimental [Page 53] RFC 4911 Encoding Instructions for RXER July 2007
2007年7月にRXERのために指示をコード化するLeggの実験的な[53ページ]RFC4911
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.
指示をコード化するGROUPを受けることがあるコンポーネントを含んでいるベースタイプがあるすべてのASN.1タイプにおいて、本書では説明されたメソッドで引き出された文法は決定論的であるに違いありません。
25.1.4. Attributes in Unknown Extensions
25.1.4. 未知の拡大における属性
An insertion point production is able to accept unknown attributes if the non-terminal on the left-hand side of the production does not have multiple derivation paths.
生産の左側の上の非端末に複数の派生経路がないなら、挿入ポイント生産は未知の属性を受け入れることができます。
Aside: If the non-terminal has multiple derivation paths, then any
future extension cannot possibly contain an attribute component
because that would violate the requirements of Section 25.1.2.
傍らに: それはセクション25.1.2の要件に違反するでしょう、そして、どんな未来にもしたがって、非端末に複数の派生経路があるなら、拡大が属性コンポーネントを含むことができません。
For a deterministic grammar, there is only one possible way to construct a sequence of element terminals matching the element content of an element in a correctly formed RXER encoding. Any unknown attributes of the element are accepted if at least one insertion point production that is able to accept unknown attributes is used in that construction.
決定論的な文法のために、正しく形成されたRXERの要素がコード化される要素含有量に合っている要素端末の系列を構成する1つの可能な方法しかありません。 その構造に未知の属性を受け入れることができる生産を少なくとも1挿入ポイント使用するなら、要素のどんな未知の属性も受け入れます。
Example
例
Consider this type definition:
この型定義を考えてください:
CHOICE {
one UTF8String,
two [GROUP] SEQUENCE {
three INTEGER,
...
}
}
選択1UTF8String、2[GROUP]のSEQUENCE、3INTEGER…
The associated grammar is:
関連文法は以下の通りです。
S ::= one
S ::= two
S:、:= 1つS:、:= 2
two ::= three I1
2:、:= 3I1
I1 ::= "*" I1
I1 ::=
I1:、:= 「*」I1 I1:、:=
one ::= "one"
three ::= "three"
1:、:= 「1」時3分:、:= 「3」
Legg Experimental [Page 54] RFC 4911 Encoding Instructions for RXER July 2007
2007年7月にRXERのために指示をコード化するLeggの実験的な[54ページ]RFC4911
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>要素であると生成する「2」代替手段には、広げることができるタイプがあります)、したがって、要素含有量が<3>要素を含んでいるなら、認識されていない属性を受け入れるでしょう。
If the SEQUENCE type were prefixed by a NO-INSERTIONS encoding
instruction, then the third, fourth, and fifth productions would
be replaced by:
どんなINSERTIONSも指示をコード化しながらSEQUENCEタイプを前に置かないなら、3番目、4番目、および5番目の創作を以下に取り替えるでしょうに。
two ::= three
2:、:= 3
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:
未知の属性を受け入れることができる生産が要素端末の合っている系列を構成する際に1挿入ポイント以上使用されるなら、デコーダは無料でそれらの挿入ポイント創作に対応する拡大挿入ポイントのいずれにも認識されていない属性を関連づけることができます。 そうするための正当化は以下の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.
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.
Legg Experimental [Page 55] RFC 4911 Encoding Instructions for RXER July 2007
Legg Experimental [Page 55] RFC 4911 Encoding Instructions for RXER July 2007
(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) Even if there is a single extension insertion point, an unknown extension could still be the encoding of a value of any one of an infinite number of valid type definitions. For example, an attribute or element component could be nested to any arbitrary depth within CHOICEs whose components are subject to GROUP encoding instructions.
Aside: A similar series of nested CHOICEs could describe an
unknown extension in a Basic Encoding Rules (BER) encoding
[X.690].
Aside: A similar series of nested CHOICEs could describe an unknown extension in a Basic Encoding Rules (BER) encoding [X.690].
26. Security Considerations
26. Security Considerations
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 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.
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.
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.
27. References
27. References
27.1. Normative References
27.1. Normative References
[BCP14] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[BCP14] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[URI] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", STD 66, RFC
3986, January 2005.
[URI] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RXER] Legg, S. and D. Prager, "Robust XML Encoding Rules (RXER)
for Abstract Syntax Notation One (ASN.1)", RFC 4910, July
2007.
[RXER] Legg, S. and D. Prager, "Robust XML Encoding Rules (RXER) for Abstract Syntax Notation One (ASN.1)", RFC 4910, July 2007.
[ASN.X] Legg, S., "Abstract Syntax Notation X (ASN.X)", RFC 4912,
July 2007.
[ASN.X] Legg, S., "Abstract Syntax Notation X (ASN.X)", RFC 4912, July 2007.
Legg Experimental [Page 56] RFC 4911 Encoding Instructions for RXER July 2007
Legg Experimental [Page 56] RFC 4911 Encoding Instructions for RXER July 2007
[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 Recommendation X.680 (07/02) | ISO/IEC 8824-1, Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation.
[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 Recommendation X.680 (2002) Amendment 1 (10/03) | ISO/IEC 8824-1:2002/Amd 1:2004, Support for 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 Recommendation X.683 (07/02) | ISO/IEC 8824-4, Information technology - Abstract Syntax Notation One (ASN.1): Parameterization of ASN.1 specifications.
[XML10] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E. and
F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fourth
Edition)", W3C Recommendation,
http://www.w3.org/TR/2006/REC-xml-20060816, August 2006.
[XML10] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E. and F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fourth Edition)", W3C Recommendation, http://www.w3.org/TR/2006/REC-xml-20060816, August 2006.
[XMLNS10] Bray, T., Hollander, D., Layman, A., and R. Tobin,
"Namespaces in XML 1.0 (Second Edition)", W3C
Recommendation,
http://www.w3.org/TR/2006/REC-xml-names-20060816, August
2006.
[XMLNS10] Bray, T., Hollander, D., Layman, A., and R. Tobin, "Namespaces in XML 1.0 (Second Edition)", W3C Recommendation, http://www.w3.org/TR/2006/REC-xml-names-20060816, August 2006.
[XSD1] Thompson, H., Beech, D., Maloney, M. and N. Mendelsohn,
"XML Schema Part 1: Structures Second Edition", W3C
Recommendation,
http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/,
October 2004.
[XSD1] Thompson, H., Beech, D., Maloney, M. and N. Mendelsohn, "XML Schema Part 1: Structures Second Edition", W3C Recommendation, http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/, October 2004.
[XSD2] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes
Second Edition", W3C Recommendation,
http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/,
October 2004.
[XSD2] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes Second Edition", W3C Recommendation, http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/, October 2004.
[RNG] Clark, J. and M. Makoto, "RELAX NG Tutorial", OASIS
Committee Specification, http://www.oasis-open.org/
committees/relax-ng/tutorial-20011203.html, December 2001.
[RNG] Clark, J. and M. Makoto, "RELAX NG Tutorial", OASIS Committee Specification, http://www.oasis-open.org/ committees/relax-ng/tutorial-20011203.html, December 2001.
27.2. Informative References
27.2. Informative References
[INFOSET] Cowan, J. and R. Tobin, "XML Information Set (Second
Edition)", W3C Recommendation, http://www.w3.org/
TR/2004/REC-xml-infoset-20040204, February 2004.
[INFOSET] Cowan, J. and R. Tobin, "XML Information Set (Second Edition)", W3C Recommendation, http://www.w3.org/ TR/2004/REC-xml-infoset-20040204, February 2004.
[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 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).
Legg Experimental [Page 57] RFC 4911 Encoding Instructions for RXER July 2007
Legg Experimental [Page 57] RFC 4911 Encoding Instructions for RXER July 2007
Appendix A. GROUP Encoding Instruction Examples
Appendix A. GROUP Encoding Instruction Examples
This appendix is non-normative.
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.
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.
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.
A.1. Example 1
A.1. Example 1
Consider this type definition:
Consider this type definition:
SEQUENCE {
one [GROUP] SEQUENCE {
two UTF8String OPTIONAL
} OPTIONAL,
three INTEGER
}
SEQUENCE { one [GROUP] SEQUENCE { two UTF8String OPTIONAL } OPTIONAL, three INTEGER }
The associated grammar is:
The associated grammar is:
P1: S ::= one three
P2: one ::= two
P3: one ::=
P4: two ::= "two"
P5: two ::=
P6: three ::= "three"
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:
Select Sets have to be evaluated to test the validity of the type definition. The grammar leads to the following sets and predicates:
First(P2) = { "two" }
First(P3) = { }
Preselected(P2) = Preselected(P3) = false
Empty(P2) = Empty(P3) = true
Follow(one) = { "three" }
Select(P2) = First(P2) + Follow(one) = { "two", "three" }
Select(P3) = First(P3) + Follow(one) = { "three" }
First(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" }
Legg Experimental [Page 58] RFC 4911 Encoding Instructions for RXER July 2007
Legg Experimental [Page 58] RFC 4911 Encoding Instructions for RXER July 2007
First(P4) = { "two" }
First(P5) = { }
Preselected(P4) = Preselected(P5) = Empty(P4) = false
Empty(P5) = true
Follow(two) = { "three" }
Select(P4) = First(P4) = { "two" }
Select(P5) = First(P5) + Follow(two) = { "three" }
First(P4) = { "two" } First(P5) = { } Preselected(P4) = Preselected(P5) = Empty(P4) = false Empty(P5) = true Follow(two) = { "three" } Select(P4) = First(P4) = { "two" } Select(P5) = First(P5) + Follow(two) = { "three" }
The intersection of Select(P2) and Select(P3) is not empty; hence, the grammar is not deterministic, and the type definition is not valid. If the RXER encoding of a value of the type does not have a child element <two>, then it is not possible to determine whether the "one" component is present or absent in the value.
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.
Now consider this type definition with attributes in the "one" component:
Now consider this type definition with attributes in the "one" component:
SEQUENCE {
one [GROUP] SEQUENCE {
two UTF8String OPTIONAL,
four [ATTRIBUTE] BOOLEAN,
five [ATTRIBUTE] BOOLEAN OPTIONAL
} OPTIONAL,
three INTEGER
}
SEQUENCE { one [GROUP] SEQUENCE { two UTF8String OPTIONAL, four [ATTRIBUTE] BOOLEAN, five [ATTRIBUTE] BOOLEAN OPTIONAL } OPTIONAL, three INTEGER }
The associated grammar is:
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"
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:
This grammar leads to the following sets and predicates:
First(P2) = { "two" }
First(P3) = { }
Preselected(P3) = Empty(P2) = false
Preselected(P2) = Empty(P3) = true
Follow(one) = { "three" }
Select(P2) = { }
Select(P3) = First(P3) + Follow(one) = { "three" }
First(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" }
Legg Experimental [Page 59] RFC 4911 Encoding Instructions for RXER July 2007
Legg Experimental [Page 59] RFC 4911 Encoding Instructions for RXER July 2007
First(P4) = { "two" }
First(P5) = { }
Preselected(P4) = Preselected(P5) = Empty(P4) = false
Empty(P5) = true
Follow(two) = { "three" }
Select(P4) = First(P4) = { "two" }
Select(P5) = First(P5) + Follow(two) = { "three" }
First(P4) = { "two" } First(P5) = { } Preselected(P4) = Preselected(P5) = Empty(P4) = false Empty(P5) = true Follow(two) = { "three" } Select(P4) = First(P4) = { "two" } Select(P5) = First(P5) + Follow(two) = { "three" }
First(P7) = { }
First(P8) = { }
Preselected(P8) = Empty(P7) = false
Preselected(P7) = Empty(P8) = true
Follow(five) = { "three" }
Select(P7) = { }
Select(P8) = First(P8) + Follow(five) = { "three" }
First(P7) = { } First(P8) = { } Preselected(P8) = Empty(P7) = false Preselected(P7) = Empty(P8) = true Follow(five) = { "three" } Select(P7) = { } Select(P8) = First(P8) + Follow(five) = { "three" }
The intersection of Select(P2) and Select(P3) is empty, as is the intersection of Select(P4) and Select(P5) and the intersection of Select(P7) and Select(P8); hence, the grammar is deterministic, and the type definition is valid. In a correct RXER encoding, the "one" component will be present if and only if the "four" attribute is present.
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.
A.2. Example 2
A.2. Example 2
Consider this type definition:
Consider this type definition:
CHOICE {
one [GROUP] SEQUENCE {
two [ATTRIBUTE] BOOLEAN OPTIONAL
},
three INTEGER,
four [GROUP] SEQUENCE {
five BOOLEAN OPTIONAL
}
}
CHOICE { one [GROUP] SEQUENCE { two [ATTRIBUTE] BOOLEAN OPTIONAL }, three INTEGER, four [GROUP] SEQUENCE { five BOOLEAN OPTIONAL } }
The associated grammar is:
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"
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"
Legg Experimental [Page 60] RFC 4911 Encoding Instructions for RXER July 2007
Legg Experimental [Page 60] RFC 4911 Encoding Instructions for RXER July 2007
P10: five ::=
P10: five ::=
This grammar leads to the following sets and predicates:
This grammar leads to the following sets and predicates:
First(P1) = { }
First(P2) = { "three" }
First(P3) = { "five" }
Preselected(P1) = Preselected(P2) = Preselected(P3) = false
Empty(P2) = false
Empty(P1) = Empty(P3) = true
Follow(S) = { "$" }
Select(P1) = First(P1) + Follow(S) = { "$" }
Select(P2) = First(P2) = { "three" }
Select(P3) = First(P3) + Follow(S) = { "five", "$" }
First(P1) = { } First(P2) = { "three" } First(P3) = { "five" } Preselected(P1) = Preselected(P2) = Preselected(P3) = false Empty(P2) = false Empty(P1) = Empty(P3) = true Follow(S) = { "$" } Select(P1) = First(P1) + Follow(S) = { "$" } Select(P2) = First(P2) = { "three" } Select(P3) = First(P3) + Follow(S) = { "five", "$" }
First(P5) = { }
First(P6) = { }
Preselected(P6) = Empty(P5) = false
Preselected(P5) = Empty(P6) = true
Follow(two) = { "$" }
Select(P5) = { }
Select(P6) = First(P6) + Follow(two) = { "$" }
First(P5) = { } First(P6) = { } Preselected(P6) = Empty(P5) = false Preselected(P5) = Empty(P6) = true Follow(two) = { "$" } Select(P5) = { } Select(P6) = First(P6) + Follow(two) = { "$" }
First(P9) = { "five" }
First(P10) = { }
Preselected(P9) = Preselected(P10) = Empty(P9) = false
Empty(P10) = true
Follow(five) = { "$" }
Select(P9) = First(P9) = { "five" }
Select(P10) = First(P10) + Follow(five) = { "$" }
First(P9) = { "five" } First(P10) = { } Preselected(P9) = Preselected(P10) = Empty(P9) = false Empty(P10) = true Follow(five) = { "$" } Select(P9) = First(P9) = { "five" } Select(P10) = First(P10) + Follow(five) = { "$" }
The intersection of Select(P1) and Select(P3) is not empty; hence, the grammar is not deterministic, and the type definition is not valid. If the RXER encoding of a value of the type is empty, then it is not possible to determine whether the "one" alternative or the "four" alternative has been chosen.
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.
Now consider this slightly different type definition:
Now consider this slightly different type definition:
CHOICE {
one [GROUP] SEQUENCE {
two [ATTRIBUTE] BOOLEAN
},
three INTEGER,
four [GROUP] SEQUENCE {
five BOOLEAN OPTIONAL
}
}
CHOICE { one [GROUP] SEQUENCE { two [ATTRIBUTE] BOOLEAN }, three INTEGER, four [GROUP] SEQUENCE { five BOOLEAN OPTIONAL } }
Legg Experimental [Page 61] RFC 4911 Encoding Instructions for RXER July 2007
Legg Experimental [Page 61] RFC 4911 Encoding Instructions for RXER July 2007
The associated grammar is:
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 ::=
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:
This grammar leads to the following sets and predicates:
First(P1) = { }
First(P2) = { "three" }
First(P3) = { "five" }
Preselected(P2) = Preselected(P3) = false
Empty(P1) = Empty(P2) = false
Preselected(P1) = Empty(P3) = true
Follow(S) = { "$" }
Select(P1) = { }
Select(P2) = First(P2) = { "three" }
Select(P3) = First(P3) + Follow(S) = { "five", "$" }
First(P1) = { } First(P2) = { "three" } First(P3) = { "five" } Preselected(P2) = Preselected(P3) = false Empty(P1) = Empty(P2) = false Preselected(P1) = Empty(P3) = true Follow(S) = { "$" } Select(P1) = { } Select(P2) = First(P2) = { "three" } Select(P3) = First(P3) + Follow(S) = { "five", "$" }
First(P8) = { "five" }
First(P9) = { }
Preselected(P8) = Preselected(P9) = Empty(P8) = false
Empty(P9) = true
Follow(five) = { "$" }
Select(P8) = First(P8) = { "five" }
Select(P9) = First(P9) + Follow(five) = { "$" }
First(P8) = { "five" } First(P9) = { } Preselected(P8) = Preselected(P9) = Empty(P8) = false Empty(P9) = true Follow(five) = { "$" } Select(P8) = First(P8) = { "five" } Select(P9) = First(P9) + Follow(five) = { "$" }
The intersection of Select(P1) and Select(P2) is empty, the intersection of Select(P1) and Select(P3) is empty, the intersection of Select(P2) and Select(P3) is empty, and the intersection of Select(P8) and Select(P9) is empty; hence, the grammar is deterministic, and the type definition is valid. The "one" and "four" alternatives can be distinguished because the "one" alternative has a mandatory attribute.
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.
Legg Experimental [Page 62] RFC 4911 Encoding Instructions for RXER July 2007
Legg Experimental [Page 62] RFC 4911 Encoding Instructions for RXER July 2007
A.3. Example 3
A.3. Example 3
Consider this type definition:
Consider this type definition:
SEQUENCE {
one [GROUP] CHOICE {
two [ATTRIBUTE] BOOLEAN,
three [GROUP] SEQUENCE OF number INTEGER
} OPTIONAL
}
SEQUENCE { one [GROUP] CHOICE { two [ATTRIBUTE] BOOLEAN, three [GROUP] SEQUENCE OF number INTEGER } OPTIONAL }
The associated grammar is:
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"
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:
This grammar leads to the following sets and predicates:
First(P2) = { }
First(P3) = { "number" }
First(P4) = { }
Preselected(P3) = Preselected(P4) = Empty(P2) = false
Preselected(P2) = Empty(P3) = Empty(P4) = true
Follow(one) = { "$" }
Select(P2) = { }
Select(P3) = First(P3) + Follow(one) = { "number", "$" }
Select(P4) = First(P4) + Follow(one) = { "$" }
First(P2) = { } First(P3) = { "number" } First(P4) = { } Preselected(P3) = Preselected(P4) = Empty(P2) = false Preselected(P2) = Empty(P3) = Empty(P4) = true Follow(one) = { "$" } Select(P2) = { } Select(P3) = First(P3) + Follow(one) = { "number", "$" } Select(P4) = First(P4) + Follow(one) = { "$" }
First(P6) = { "number" }
First(P7) = { }
Preselected(P6) = Preselected(P7) = Empty(P6) = false
Empty(P7) = true
Follow(three) = { "$" }
Select(P6) = First(P6) = { "number" }
Select(P7) = First(P7) + Follow(three) = { "$" }
First(P6) = { "number" } First(P7) = { } Preselected(P6) = Preselected(P7) = Empty(P6) = false Empty(P7) = true Follow(three) = { "$" } Select(P6) = First(P6) = { "number" } Select(P7) = First(P7) + Follow(three) = { "$" }
The intersection of Select(P3) and Select(P4) is not empty; hence, the grammar is not deterministic, and the type definition is not valid. If the RXER encoding of a value of the type is empty, then it is not possible to determine whether the "one" component is absent or the empty "three" alternative has been chosen.
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.
Legg Experimental [Page 63] RFC 4911 Encoding Instructions for RXER July 2007
Legg Experimental [Page 63] RFC 4911 Encoding Instructions for RXER July 2007
A.4. Example 4
A.4. Example 4
Consider this type definition:
Consider this type definition:
SEQUENCE {
one [GROUP] CHOICE {
two [ATTRIBUTE] BOOLEAN,
three [ATTRIBUTE] BOOLEAN
} OPTIONAL
}
SEQUENCE { one [GROUP] CHOICE { two [ATTRIBUTE] BOOLEAN, three [ATTRIBUTE] BOOLEAN } OPTIONAL }
The associated grammar is:
The associated grammar is:
P1: S ::= one
P2: one ::= two
P3: one ::= three
P4: one ::=
P5: two ::= "@two"
P6: three ::= "@three"
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:
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) = { "$" }
First(P2) = { } First(P3) = { } First(P4) = { } Preselected(P4) = Empty(P2) = Empty(P3) = false Preselected(P2) = Preselected(P3) = Empty(P4) = true Follow(one) = { "$" } Select(P2) = { } Select(P3) = { } Select(P4) = First(P4) + Follow(one) = { "$" }
The intersection of Select(P2) and Select(P3) is empty, the intersection of Select(P2) and Select(P4) is empty, and the intersection of Select(P3) and Select(P4) is empty; hence, the grammar is deterministic, and the type definition is valid.
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.
A.5. Example 5
A.5. Example 5
Consider this type definition:
Consider this type definition:
SEQUENCE {
one [GROUP] SEQUENCE OF number INTEGER OPTIONAL
}
SEQUENCE { one [GROUP] SEQUENCE OF number INTEGER OPTIONAL }
Legg Experimental [Page 64] RFC 4911 Encoding Instructions for RXER July 2007
Legg Experimental [Page 64] RFC 4911 Encoding Instructions for RXER July 2007
The associated grammar is:
The associated grammar is:
P1: S ::= one
P2: one ::= number one
P3: one ::=
P4: one ::=
P5: number ::= "number"
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 is generated during the processing of the SEQUENCE OF type. P4 is generated because the "one" component is optional.
This grammar leads to the following sets and predicates:
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) = { "$" }
First(P2) = { "number" } First(P3) = { } First(P4) = { } Preselected(P2) = Preselected(P3) = Preselected(P4) = false Empty(P2) = false Empty(P3) = Empty(P4) = true Follow(one) = { "$" } Select(P2) = First(P2) = { "number" } Select(P3) = First(P3) + Follow(one) = { "$" } Select(P4) = First(P4) + Follow(one) = { "$" }
The intersection of Select(P3) and Select(P4) is not empty; hence, the grammar is not deterministic, and the type definition is not valid. If the RXER encoding of a value of the type does not have any <number> child elements, then it is not possible to determine whether the "one" component is present or absent in the value.
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.
Consider this similar type definition with a SIZE constraint:
Consider this similar type definition with a SIZE constraint:
SEQUENCE {
one [GROUP] SEQUENCE SIZE(1..MAX) OF number INTEGER OPTIONAL
}
SEQUENCE { one [GROUP] SEQUENCE SIZE(1..MAX) OF number INTEGER OPTIONAL }
The associated grammar is:
The associated grammar is:
P1: S ::= one
P2: one ::= number one'
P3: one' ::= number one'
P4: one' ::=
P5: one ::=
P6: number ::= "number"
P1: S ::= one P2: one ::= number one' P3: one' ::= number one' P4: one' ::= P5: one ::= P6: number ::= "number"
Legg Experimental [Page 65] RFC 4911 Encoding Instructions for RXER July 2007
Legg Experimental [Page 65] RFC 4911 Encoding Instructions for RXER July 2007
This grammar leads to the following sets and predicates:
This grammar leads to the following sets and predicates:
First(P2) = { "number" }
First(P5) = { }
Preselected(P2) = Preselected(P5) = Empty(P2) = false
Empty(P5) = true
Follow(one) = { "$" }
Select(P2) = First(P2) = { "number" }
Select(P5) = First(P5) + Follow(one) = { "$" }
First(P2) = { "number" } First(P5) = { } Preselected(P2) = Preselected(P5) = Empty(P2) = false Empty(P5) = true Follow(one) = { "$" } Select(P2) = First(P2) = { "number" } Select(P5) = First(P5) + Follow(one) = { "$" }
First(P3) = { "number" }
First(P4) = { }
Preselected(P3) = Preselected(P4) = Empty(P3) = false
Empty(P4) = true
Follow(one') = { "$" }
Select(P3) = First(P3) = { "number" }
Select(P4) = First(P4) + Follow(one') = { "$" }
First(P3) = { "number" } First(P4) = { } Preselected(P3) = Preselected(P4) = Empty(P3) = false Empty(P4) = true Follow(one') = { "$" } Select(P3) = First(P3) = { "number" } Select(P4) = First(P4) + Follow(one') = { "$" }
The intersection of Select(P2) and Select(P5) is empty, as is the intersection of Select(P3) and Select(P4); hence, the grammar is deterministic, and the type definition is valid. If there are no <number> child elements, then the "one" component is necessarily absent and there is no ambiguity.
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.
A.6. Example 6
A.6. Example 6
Consider this type definition:
Consider this type definition:
SEQUENCE {
beginning [GROUP] List,
middle UTF8String OPTIONAL,
end [GROUP] List
}
SEQUENCE { beginning [GROUP] List, middle UTF8String OPTIONAL, end [GROUP] List }
List ::= SEQUENCE OF string UTF8String
List ::= SEQUENCE OF string UTF8String
The associated grammar is:
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"
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"
Legg Experimental [Page 66] RFC 4911 Encoding Instructions for RXER July 2007
Legg Experimental [Page 66] RFC 4911 Encoding Instructions for RXER July 2007
This grammar leads to the following sets and predicates:
This grammar leads to the following sets and predicates:
First(P2) = { "string" }
First(P3) = { }
Preselected(P2) = Preselected(P3) = Empty(P2) = false
Empty(P3) = true
Follow(beginning) = { "middle", "string", "$" }
Select(P2) = First(P2) = { "string" }
Select(P3) = First(P3) + Follow(beginning)
= { "middle", "string", "$" }
First(P2) = { "string" } First(P3) = { } Preselected(P2) = Preselected(P3) = Empty(P2) = false Empty(P3) = true Follow(beginning) = { "middle", "string", "$" } Select(P2) = First(P2) = { "string" } Select(P3) = First(P3) + Follow(beginning) = { "middle", "string", "$" }
First(P4) = { "middle" }
First(P5) = { }
Preselected(P4) = Preselected(P5) = Empty(P4) = false
Empty(P5) = true
Follow(middle) = { "string", "$" }
Select(P4) = First(P4) = { "middle" }
Select(P5) = First(P5) + Follow(middle) = { "string", "$" }
First(P4) = { "middle" } First(P5) = { } Preselected(P4) = Preselected(P5) = Empty(P4) = false Empty(P5) = true Follow(middle) = { "string", "$" } Select(P4) = First(P4) = { "middle" } Select(P5) = First(P5) + Follow(middle) = { "string", "$" }
First(P6) = { "string" }
First(P7) = { }
Preselected(P6) = Preselected(P7) = Empty(P6) = false
Empty(P7) = true
Follow(end) = { "$" }
Select(P6) = First(P6) = { "string" }
Select(P7) = First(P7) + Follow(end) = { "$" }
First(P6) = { "string" } First(P7) = { } Preselected(P6) = Preselected(P7) = Empty(P6) = false Empty(P7) = true Follow(end) = { "$" } Select(P6) = First(P6) = { "string" } Select(P7) = First(P7) + Follow(end) = { "$" }
The intersection of Select(P2) and Select(P3) is not empty; hence, the grammar is not deterministic, and the type definition is not valid.
The intersection of Select(P2) and Select(P3) is not empty; hence, the grammar is not deterministic, and the type definition is not valid.
Now consider the following type definition:
Now consider the following type definition:
SEQUENCE {
beginning [GROUP] List,
middleAndEnd [GROUP] SEQUENCE {
middle UTF8String,
end [GROUP] List
} OPTIONAL
}
SEQUENCE { beginning [GROUP] List, middleAndEnd [GROUP] SEQUENCE { middle UTF8String, end [GROUP] List } OPTIONAL }
The associated grammar is:
The associated grammar is:
P1: S ::= beginning middleAndEnd
P2: beginning ::= string beginning
P3: beginning ::=
P4: middleAndEnd ::= middle end
P5: middleAndEnd ::=
P1: S ::= beginning middleAndEnd P2: beginning ::= string beginning P3: beginning ::= P4: middleAndEnd ::= middle end P5: middleAndEnd ::=
Legg Experimental [Page 67] RFC 4911 Encoding Instructions for RXER July 2007
Legg Experimental [Page 67] RFC 4911 Encoding Instructions for RXER July 2007
P6: middle ::= "middle"
P7: end ::= string end
P8: end ::=
P9: string ::= "string"
P6: middle ::= "middle" P7: end ::= string end P8: end ::= P9: string ::= "string"
This grammar leads to the following sets and predicates:
This grammar leads to the following sets and predicates:
First(P2) = { "string" }
First(P3) = { }
Preselected(P2) = Preselected(P3) = Empty(P2) = false
Empty(P3) = true
Follow(beginning) = { "middle", "$" }
Select(P2) = First(P2) = { "string" }
Select(P3) = First(P3) + Follow(beginning) = { "middle", "$" }
First(P2) = { "string" } First(P3) = { } Preselected(P2) = Preselected(P3) = Empty(P2) = false Empty(P3) = true Follow(beginning) = { "middle", "$" } Select(P2) = First(P2) = { "string" } Select(P3) = First(P3) + Follow(beginning) = { "middle", "$" }
First(P4) = { "middle" }
First(P5) = { }
Preselected(P4) = Preselected(P5) = Empty(P4) = false
Empty(P5) = true
Follow(middleAndEnd) = { "$" }
Select(P4) = First(P4) = { "middle" }
Select(P5) = First(P5) + Follow(middleAndEnd) = { "$" }
First(P4) = { "middle" } First(P5) = { } Preselected(P4) = Preselected(P5) = Empty(P4) = false Empty(P5) = true Follow(middleAndEnd) = { "$" } Select(P4) = First(P4) = { "middle" } Select(P5) = First(P5) + Follow(middleAndEnd) = { "$" }
First(P7) = { "string" }
First(P8) = { }
Preselected(P7) = Preselected(P8) = Empty(P7) = false
Empty(P8) = true
Follow(end) = { "$" }
Select(P7) = First(P7) = { "string" }
Select(P8) = First(P8) + Follow(end) = { "$" }
First(P7) = { "string" } First(P8) = { } Preselected(P7) = Preselected(P8) = Empty(P7) = false Empty(P8) = true Follow(end) = { "$" } Select(P7) = First(P7) = { "string" } Select(P8) = First(P8) + Follow(end) = { "$" }
The intersection of Select(P2) and Select(P3) is empty, as is the intersection of Select(P4) and Select(P5) and the intersection of Select(P7) and Select(P8); hence, the grammar is deterministic, and the type definition is valid.
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.
A.7. Example 7
A.7. Example 7
Consider the following type definition:
Consider the following type definition:
SEQUENCE SIZE(1..MAX) OF
one [GROUP] SEQUENCE {
two INTEGER OPTIONAL
}
SEQUENCE SIZE(1..MAX) OF one [GROUP] SEQUENCE { two INTEGER OPTIONAL }
Legg Experimental [Page 68] RFC 4911 Encoding Instructions for RXER July 2007
Legg Experimental [Page 68] RFC 4911 Encoding Instructions for RXER July 2007
The associated grammar is:
The associated grammar is:
P1: S ::= one S'
P2: S' ::= one S'
P3: S' ::=
P4: one ::= two
P5: two ::= "two"
P6: two ::=
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:
This grammar leads to the following sets and predicates:
First(P2) = { "two" }
First(P3) = { }
Preselected(P2) = Preselected(P3) = false
Empty(P2) = Empty(P3) = true
Follow(S') = { "$" }
Select(P2) = First(P2) + Follow(S') = { "two", "$" }
Select(P3) = First(P3) + Follow(S') = { "$" }
First(P2) = { "two" } First(P3) = { } Preselected(P2) = Preselected(P3) = false Empty(P2) = Empty(P3) = true Follow(S') = { "$" } Select(P2) = First(P2) + Follow(S') = { "two", "$" } Select(P3) = First(P3) + Follow(S') = { "$" }
First(P5) = { "two" }
First(P6) = { }
Preselected(P5) = Preselected(P6) = Empty(P5) = false
Empty(P6) = true
Follow(two) = { "two", "$" }
Select(P5) = First(P5) = { "two" }
Select(P6) = First(P6) + Follow(two) = { "two", "$" }
First(P5) = { "two" } First(P6) = { } Preselected(P5) = Preselected(P6) = Empty(P5) = false Empty(P6) = true Follow(two) = { "two", "$" } Select(P5) = First(P5) = { "two" } Select(P6) = First(P6) + Follow(two) = { "two", "$" }
The intersection of Select(P2) and Select(P3) is not empty and the intersection of Select(P5) and Select(P6) is not empty; hence, the grammar is not deterministic, and the type definition is not valid. The encoding of a value of the type contains an indeterminate number of empty instances of the component type.
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.
A.8. Example 8
A.8. Example 8
Consider the following type definition:
Consider the following type definition:
SEQUENCE OF
list [GROUP] SEQUENCE SIZE(1..MAX) OF number INTEGER
SEQUENCE OF list [GROUP] SEQUENCE SIZE(1..MAX) OF number INTEGER
The associated grammar is:
The associated grammar is:
P1: S ::= list S
P2: S ::=
P3: list ::= number list'
P4: list' ::= number list'
P5: list' ::=
P6: number ::= "number"
P1: S ::= list S P2: S ::= P3: list ::= number list' P4: list' ::= number list' P5: list' ::= P6: number ::= "number"
Legg Experimental [Page 69] RFC 4911 Encoding Instructions for RXER July 2007
Legg Experimental [Page 69] RFC 4911 Encoding Instructions for RXER July 2007
This grammar leads to the following sets and predicates:
This grammar leads to the following sets and predicates:
First(P1) = { "number" }
First(P2) = { }
Preselected(P1) = Preselected(P2) = Empty(P1) = false
Empty(P2) = true
Follow(S) = { "$" }
Select(P1) = First(P1) = { "number" }
Select(P2) = First(P2) + Follow(S) = { "$" }
First(P1) = { "number" } First(P2) = { } Preselected(P1) = Preselected(P2) = Empty(P1) = false Empty(P2) = true Follow(S) = { "$" } Select(P1) = First(P1) = { "number" } Select(P2) = First(P2) + Follow(S) = { "$" }
First(P4) = { "number" }
First(P5) = { }
Preselected(P4) = Preselected(P5) = Empty(P4) = false
Empty(P5) = true
Follow(list') = { "number", "$" }
Select(P4) = First(P4) = { "number" }
Select(P5) = First(P5) + Follow(list') = { "number", "$" }
First(P4) = { "number" } First(P5) = { } Preselected(P4) = Preselected(P5) = Empty(P4) = false Empty(P5) = true Follow(list') = { "number", "$" } Select(P4) = First(P4) = { "number" } Select(P5) = First(P5) + Follow(list') = { "number", "$" }
The intersection of Select(P4) and Select(P5) is not empty; hence, the grammar is not deterministic, and the type definition is not valid. The type describes a list of lists, but it is not possible for a decoder to determine where the outer lists begin and end.
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.
A.9. Example 9
A.9. Example 9
Consider the following type definition:
Consider the following type definition:
SEQUENCE OF item [GROUP] SEQUENCE {
before [GROUP] OneAndTwo,
core UTF8String,
after [GROUP] OneAndTwo OPTIONAL
}
SEQUENCE OF item [GROUP] SEQUENCE { before [GROUP] OneAndTwo, core UTF8String, after [GROUP] OneAndTwo OPTIONAL }
OneAndTwo ::= SEQUENCE {
non-core UTF8String
}
OneAndTwo ::= SEQUENCE { non-core UTF8String }
The associated grammar is:
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 ::=
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 ::=
Legg Experimental [Page 70] RFC 4911 Encoding Instructions for RXER July 2007
Legg Experimental [Page 70] RFC 4911 Encoding Instructions for RXER July 2007
This grammar leads to the following sets and predicates:
This grammar leads to the following sets and predicates:
First(P1) = { "non-core" }
First(P2) = { }
Preselected(P1) = Preselected(P2) = Empty(P1) = false
Empty(P2) = true
Follow(S) = { "$" }
Select(P1) = First(P1) = { "non-core" }
Select(P2) = First(P2) + Follow(S) = { "$" }
First(P1) = { "non-core" } First(P2) = { } Preselected(P1) = Preselected(P2) = Empty(P1) = false Empty(P2) = true Follow(S) = { "$" } Select(P1) = First(P1) = { "non-core" } Select(P2) = First(P2) + Follow(S) = { "$" }
First(P7) = { "non-core" }
First(P8) = { }
Preselected(P7) = Preselected(P8) = Empty(P7) = false
Empty(P8) = true
Follow(after) = { "non-core", "$" }
Select(P7) = First(P7) = { "non-core" }
Select(P8) = First(P8) + Follow(after) = { "non-core", "$" }
First(P7) = { "non-core" } First(P8) = { } Preselected(P7) = Preselected(P8) = Empty(P7) = false Empty(P8) = true Follow(after) = { "non-core", "$" } Select(P7) = First(P7) = { "non-core" } Select(P8) = First(P8) + Follow(after) = { "non-core", "$" }
The intersection of Select(P7) and Select(P8) is not empty; hence, the grammar is not deterministic, and the type definition is not valid. There is ambiguity between the end of one item and the start of the next. Without looking ahead in an encoding, it is not possible to determine whether a <non-core> element belongs with the preceding or following <core> element.
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.
A.10. Example 10
A.10. Example 10
Consider the following type definition:
Consider the following type definition:
CHOICE {
one [GROUP] List,
two [GROUP] SEQUENCE {
three [ATTRIBUTE] UTF8String,
four [GROUP] List
}
}
CHOICE { one [GROUP] List, two [GROUP] SEQUENCE { three [ATTRIBUTE] UTF8String, four [GROUP] List } }
List ::= SEQUENCE OF string UTF8String
List ::= SEQUENCE OF string UTF8String
The associated grammar is:
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
P1: S ::= one P2: S ::= two P3: one ::= string one P4: one ::= P5: two ::= three four P6: three ::= "@three" P7: four ::= string four
Legg Experimental [Page 71] RFC 4911 Encoding Instructions for RXER July 2007
Legg Experimental [Page 71] RFC 4911 Encoding Instructions for RXER July 2007
P8: four ::=
P9: string ::= "string"
P8: four ::= P9: string ::= "string"
This grammar leads to the following sets and predicates:
This grammar leads to the following sets and predicates:
First(P1) = { "string" }
First(P2) = { "string" }
Preselected(P1) = Empty(P2) = false
Preselected(P2) = Empty(P1) = true
Follow(S) = { "$" }
Select(P1) = First(P1) + Follow(S) = { "string", "$" }
Select(P2) = { }
First(P1) = { "string" } First(P2) = { "string" } Preselected(P1) = Empty(P2) = false Preselected(P2) = Empty(P1) = true Follow(S) = { "$" } Select(P1) = First(P1) + Follow(S) = { "string", "$" } Select(P2) = { }
First(P3) = { "string" }
First(P4) = { }
Preselected(P3) = Preselected(P4) = Empty(P3) = false
Empty(P4) = true
Follow(one) = { "$" }
Select(P3) = First(P3) = { "string" }
Select(P4) = First(P4) + Follow(one) = { "$" }
First(P3) = { "string" } First(P4) = { } Preselected(P3) = Preselected(P4) = Empty(P3) = false Empty(P4) = true Follow(one) = { "$" } Select(P3) = First(P3) = { "string" } Select(P4) = First(P4) + Follow(one) = { "$" }
First(P7) = { "string" }
First(P8) = { }
Preselected(P7) = Preselected(P8) = Empty(P7) = false
Empty(P8) = true
Follow(four) = { "$" }
Select(P7) = First(P7) = { "string" }
Select(P8) = First(P8) + Follow(four) = { "$" }
First(P7) = { "string" } First(P8) = { } Preselected(P7) = Preselected(P8) = Empty(P7) = false Empty(P8) = true Follow(four) = { "$" } Select(P7) = First(P7) = { "string" } Select(P8) = First(P8) + Follow(four) = { "$" }
The intersection of Select(P1) and Select(P2) is empty, as is the intersection of Select(P3) and Select(P4) and the intersection of Select(P7) and Select(P8); hence, the grammar is deterministic, and the type definition is valid. Although both alternatives of the CHOICE can begin with a <string> element, an RXER decoder would use the presence of a "three" attribute to decide whether to select or disregard the "two" alternative.
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.
However, an attribute in an extension cannot be used to select between alternatives. Consider the following type definition:
However, an attribute in an extension cannot be used to select between alternatives. Consider the following type definition:
Legg Experimental [Page 72] RFC 4911 Encoding Instructions for RXER July 2007
Legg Experimental [Page 72] RFC 4911 Encoding Instructions for RXER July 2007
[SINGULAR-INSERTIONS] CHOICE {
one [GROUP] List,
...,
two [GROUP] SEQUENCE {
three [ATTRIBUTE] UTF8String,
four [GROUP] List
} -- ExtensionAdditionAlternative (E1).
-- The extension insertion point is here (I1).
}
[SINGULAR-INSERTIONS] CHOICE { one [GROUP] List, ..., two [GROUP] SEQUENCE { three [ATTRIBUTE] UTF8String, four [GROUP] List } -- ExtensionAdditionAlternative (E1). -- The extension insertion point is here (I1). }
List ::= SEQUENCE OF string UTF8String
List ::= SEQUENCE OF string UTF8String
The associated grammar is:
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"
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:
This grammar leads to the following sets and predicates for P1, P10 and 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) = { "*" }
First(P1) = { "string" } First(P10) = { "string" } First(P11) = { "*" } Preselected(P1) = Preselected(P10) = Preselected(P11) = false Empty(P10) = Empty(P11) = false Empty(P1) = true Follow(S) = { "$" } Select(P1) = First(P1) + Follow(S) = { "string", "$" } Select(P10) = First(P10) = { "string" } Select(P11) = First(P11) = { "*" }
Preselected(P10) evaluates to false because Preselected(P10) is evaluated on the base grammar, wherein P10 is rewritten as:
Preselected(P10) evaluates to false because Preselected(P10) is evaluated on the base grammar, wherein P10 is rewritten as:
P10: S ::=
P10: S ::=
Legg Experimental [Page 73] RFC 4911 Encoding Instructions for RXER July 2007
Legg Experimental [Page 73] RFC 4911 Encoding Instructions for RXER July 2007
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.
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.
Appendix B. Insertion Encoding Instruction Examples
Appendix B. Insertion Encoding Instruction Examples
This appendix is non-normative.
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.
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. Example 1
Consider the following type definition:
Consider the following type definition:
SEQUENCE {
one [GROUP] SEQUENCE {
two UTF8String,
... -- Extension insertion point (I1).
},
three INTEGER OPTIONAL,
... -- Extension insertion point (I2).
}
SEQUENCE { one [GROUP] SEQUENCE { two UTF8String, ... -- Extension insertion point (I1). }, three INTEGER OPTIONAL, ... -- Extension insertion point (I2). }
The associated grammar is:
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 ::=
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:
This grammar leads to the following sets and predicates:
First(P4) = { "*" }
First(P5) = { }
Preselected(P4) = Preselected(P5) = Empty(P4) = false
Empty(P5) = true
Follow(I1) = { "three", "*", "$" }
Select(P4) = First(P4) = { "*" }
Select(P5) = First(P5) + Follow(I1) = { "three", "*", "$" }
First(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", "*", "$" }
Legg Experimental [Page 74] RFC 4911 Encoding Instructions for RXER July 2007
Legg Experimental [Page 74] RFC 4911 Encoding Instructions for RXER July 2007
First(P6) = { "three" }
First(P7) = { }
Preselected(P6) = Preselected(P7) = Empty(P6) = false
Empty(P7) = true
Follow(three) = { "*", "$" }
Select(P6) = First(P6) = { "three" }
Select(P7) = First(P7) + Follow(three) = { "*", "$" }
First(P6) = { "three" } First(P7) = { } Preselected(P6) = Preselected(P7) = Empty(P6) = false Empty(P7) = true Follow(three) = { "*", "$" } Select(P6) = First(P6) = { "three" } Select(P7) = First(P7) + Follow(three) = { "*", "$" }
First(P8) = { "*" }
First(P9) = { }
Preselected(P8) = Preselected(P9) = Empty(P8) = false
Empty(P9) = true
Follow(I2) = { "$" }
Select(P8) = First(P8) = { "*" }
Select(P9) = First(P9) + Follow(I2) = { "$" }
First(P8) = { "*" } First(P9) = { } Preselected(P8) = Preselected(P9) = Empty(P8) = false Empty(P9) = true Follow(I2) = { "$" } Select(P8) = First(P8) = { "*" } Select(P9) = First(P9) + Follow(I2) = { "$" }
The intersection of Select(P4) and Select(P5) is not empty; hence, the grammar is not deterministic, and the type definition is not valid. If an RXER decoder encounters an unrecognized element immediately after a <two> element, then it will not know whether to associate it with extension insertion point I1 or I2.
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.
The non-determinism can be resolved with either a NO-INSERTIONS or HOLLOW-INSERTIONS encoding instruction. Consider this revised type definition:
The non-determinism can be resolved with either a NO-INSERTIONS or HOLLOW-INSERTIONS encoding instruction. Consider this revised type definition:
SEQUENCE {
one [GROUP] [HOLLOW-INSERTIONS] SEQUENCE {
two UTF8String,
... -- Extension insertion point (I1).
},
three INTEGER OPTIONAL,
... -- Extension insertion point (I2).
}
SEQUENCE { one [GROUP] [HOLLOW-INSERTIONS] SEQUENCE { two UTF8String, ... -- Extension insertion point (I1). }, three INTEGER OPTIONAL, ... -- Extension insertion point (I2). }
The associated grammar is:
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 ::=
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
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
Legg Experimental [Page 75] RFC 4911 Encoding Instructions for RXER July 2007
Legg Experimental [Page 75] RFC 4911 Encoding Instructions for RXER July 2007
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.
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.
The non-determinism could also be resolved by adding a NO-INSERTIONS or HOLLOW-INSERTIONS encoding instruction to the outer SEQUENCE:
The non-determinism could also be resolved by adding a NO-INSERTIONS or HOLLOW-INSERTIONS encoding instruction to the outer SEQUENCE:
[HOLLOW-INSERTIONS] SEQUENCE {
one [GROUP] SEQUENCE {
two UTF8String,
... -- Extension insertion point (I1).
},
three INTEGER OPTIONAL,
... -- Extension insertion point (I2).
}
[HOLLOW-INSERTIONS] SEQUENCE { one [GROUP] SEQUENCE { two UTF8String, ... -- Extension insertion point (I1). }, three INTEGER OPTIONAL, ... -- Extension insertion point (I2). }
The associated grammar is:
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 ::=
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:
This grammar leads to the following sets and predicates:
First(P4) = { "*" }
First(P5) = { }
Preselected(P4) = Preselected(P5) = Empty(P4) = false
Empty(P5) = true
Follow(I1) = { "three", "$" }
Select(P4) = First(P4) = { "*" }
Select(P5) = First(P5) + Follow(I1) = { "three", "$" }
First(P4) = { "*" } First(P5) = { } Preselected(P4) = Preselected(P5) = Empty(P4) = false Empty(P5) = true Follow(I1) = { "three", "$" } Select(P4) = First(P4) = { "*" } Select(P5) = First(P5) + Follow(I1) = { "three", "$" }
First(P6) = { "three" }
First(P7) = { }
Preselected(P6) = Preselected(P7) = Empty(P6) = false
Empty(P7) = true
Follow(three) = { "$" }
Select(P6) = First(P6) = { "three" }
Select(P7) = First(P7) + Follow(three) = { "$" }
First(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) = { "$" }
Legg Experimental [Page 76] RFC 4911 Encoding Instructions for RXER July 2007
Legg Experimental [Page 76] RFC 4911 Encoding Instructions for RXER July 2007
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.
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.
B.2. Example 2
B.2. Example 2
Consider the following type definition:
Consider the following type definition:
SEQUENCE {
one [GROUP] CHOICE {
two UTF8String,
... -- Extension insertion point (I1).
} OPTIONAL
}
SEQUENCE { one [GROUP] CHOICE { two UTF8String, ... -- Extension insertion point (I1). } OPTIONAL }
The associated grammar is:
The associated grammar is:
P1: S ::= one
P2: one ::= two
P3: one ::= I1
P4: one ::=
P5: two ::= "two"
P6: I1 ::= "*" I1
P7: I1 ::=
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:
This grammar leads to the following sets and predicates:
First(P2) = { "two" }
First(P3) = { "*" }
First(P4) = { }
Preselected(P2) = Preselected(P3) = Preselected(P4) = false
Empty(P2) = false
Empty(P3) = Empty(P4) = true
Follow(one) = { "$" }
Select(P2) = First(P2) = { "two" }
Select(P3) = First(P3) + Follow(one) = { "*", "$" }
Select(P4) = First(P4) + Follow(one) = { "$" }
First(P2) = { "two" } First(P3) = { "*" } First(P4) = { } Preselected(P2) = Preselected(P3) = Preselected(P4) = false Empty(P2) = false Empty(P3) = Empty(P4) = true Follow(one) = { "$" } Select(P2) = First(P2) = { "two" } Select(P3) = First(P3) + Follow(one) = { "*", "$" } Select(P4) = First(P4) + Follow(one) = { "$" }
First(P6) = { "*" }
First(P7) = { }
Preselected(P6) = Preselected(P7) = Empty(P6) = false
Empty(P7) = true
First(P6) = { "*" } First(P7) = { } Preselected(P6) = Preselected(P7) = Empty(P6) = false Empty(P7) = true
Legg Experimental [Page 77] RFC 4911 Encoding Instructions for RXER July 2007
Legg Experimental [Page 77] RFC 4911 Encoding Instructions for RXER July 2007
Follow(I1) = { "$" }
Select(P6) = First(P6) = { "*" }
Select(P7) = First(P7) + Follow(I1) = { "$" }
Follow(I1) = { "$" } Select(P6) = First(P6) = { "*" } Select(P7) = First(P7) + Follow(I1) = { "$" }
The intersection of Select(P3) and Select(P4) is not empty; hence, the grammar is not deterministic, and the type definition is not valid. If the <two> element is not present, then a decoder cannot determine whether the "one" alternative is absent, or present with an unknown extension that generates no elements.
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.
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:
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 { one [GROUP] [MULTIFORM-INSERTIONS] CHOICE { two UTF8String, ... -- Extension insertion point (I1). } OPTIONAL }
The associated grammar is:
The associated grammar is:
P1: S ::= one
P2: one ::= two
P8: one ::= "*" I1
P4: one ::=
P5: two ::= "two"
P6: I1 ::= "*" I1
P7: I1 ::=
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:
This grammar leads to the following sets and predicates:
First(P2) = { "two" }
First(P8) = { "*" }
First(P4) = { }
Preselected(P2) = Preselected(P8) = Preselected(P4) = false
Empty(P2) = Empty(P8) = false
Empty(P4) = true
Follow(one) = { "$" }
Select(P2) = First(P2) = { "two" }
Select(P8) = First(P8) = { "*" }
Select(P4) = First(P4) + Follow(one) = { "$" }
First(P2) = { "two" } First(P8) = { "*" } First(P4) = { } Preselected(P2) = Preselected(P8) = Preselected(P4) = false Empty(P2) = Empty(P8) = false Empty(P4) = true Follow(one) = { "$" } Select(P2) = First(P2) = { "two" } Select(P8) = First(P8) = { "*" } Select(P4) = First(P4) + Follow(one) = { "$" }
First(P6) = { "*" }
First(P7) = { }
Preselected(P6) = Preselected(P7) = Empty(P6) = false
First(P6) = { "*" } First(P7) = { } Preselected(P6) = Preselected(P7) = Empty(P6) = false
Legg Experimental [Page 78] RFC 4911 Encoding Instructions for RXER July 2007
Legg Experimental [Page 78] RFC 4911 Encoding Instructions for RXER July 2007
Empty(P7) = true
Follow(I1) = { "$" }
Select(P6) = First(P6) = { "*" }
Select(P7) = First(P7) + Follow(I1) = { "$" }
Empty(P7) = true Follow(I1) = { "$" } Select(P6) = First(P6) = { "*" } Select(P7) = First(P7) + Follow(I1) = { "$" }
The intersection of Select(P2) and Select(P8) is empty, as is the intersection of Select(P2) and Select(P4), the intersection of Select(P8) and Select(P4), and the intersection of Select(P6) and Select(P7); hence, the grammar is deterministic, and the type definition is valid. A decoder will now assume the "one" alternative is present if it sees at least one unrecognized element, and absent otherwise.
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.
B.3. Example 3
B.3. Example 3
Consider the following type definition:
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 { one [GROUP] CHOICE { two UTF8String, ... -- Extension insertion point (I1). }, three [GROUP] CHOICE { four UTF8String, ... -- Extension insertion point (I2). } }
The associated grammar is:
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 ::=
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:
This grammar leads to the following sets and predicates:
First(P2) = { "two" }
First(P3) = { "*" }
Preselected(P2) = Preselected(P3) = Empty(P2) = false
Empty(P3) = true
First(P2) = { "two" } First(P3) = { "*" } Preselected(P2) = Preselected(P3) = Empty(P2) = false Empty(P3) = true
Legg Experimental [Page 79] RFC 4911 Encoding Instructions for RXER July 2007
Legg Experimental [Page 79] RFC 4911 Encoding Instructions for RXER July 2007
Follow(one) = { "four", "*", "$" }
Select(P2) = First(P2) = { "two" }
Select(P3) = First(P3) + Follow(one) = { "*", "four", "$" }
Follow(one) = { "four", "*", "$" } Select(P2) = First(P2) = { "two" } Select(P3) = First(P3) + Follow(one) = { "*", "four", "$" }
First(P5) = { "*" }
First(P6) = { }
Preselected(P5) = Preselected(P6) = Empty(P5) = false
Empty(P6) = true
Follow(I1) = { "four", "*", "$" }
Select(P5) = First(P5) = { "*" }
Select(P6) = First(P6) + Follow(I1) = { "four", "*", "$" }
First(P5) = { "*" } First(P6) = { } Preselected(P5) = Preselected(P6) = Empty(P5) = false Empty(P6) = true Follow(I1) = { "four", "*", "$" } Select(P5) = First(P5) = { "*" } Select(P6) = First(P6) + Follow(I1) = { "four", "*", "$" }
First(P7) = { "four" }
First(P8) = { "*" }
Preselected(P7) = Preselected(P8) = Empty(P7) = false
Empty(P8) = true
Follow(three) = { "$" }
Select(P7) = First(P7) = { "four" }
Select(P8) = First(P8) + Follow(three) = { "*", "$" }
First(P7) = { "four" } First(P8) = { "*" } Preselected(P7) = Preselected(P8) = Empty(P7) = false Empty(P8) = true Follow(three) = { "$" } Select(P7) = First(P7) = { "four" } Select(P8) = First(P8) + Follow(three) = { "*", "$" }
First(P10) = { "*" }
First(P11) = { }
Preselected(P10) = Preselected(P11) = Empty(P10) = false
Empty(P11) = true
Follow(I2) = { "$" }
Select(P10) = First(P10) = { "*" }
Select(P11) = First(P11) + Follow(I2) = { "$" }
First(P10) = { "*" } First(P11) = { } Preselected(P10) = Preselected(P11) = Empty(P10) = false Empty(P11) = true Follow(I2) = { "$" } Select(P10) = First(P10) = { "*" } Select(P11) = First(P11) + Follow(I2) = { "$" }
The intersection of Select(P5) and Select(P6) is not empty; hence, the grammar is not deterministic, and the type definition is not valid. If the first child element is an unrecognized element, then a decoder cannot determine whether to associate it with extension insertion point I1, or to associate it with extension insertion point I2 by assuming that the "one" component has an unknown extension that generates no elements.
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.
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:
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:
Legg Experimental [Page 80] RFC 4911 Encoding Instructions for RXER July 2007
Legg Experimental [Page 80] RFC 4911 Encoding Instructions for RXER July 2007
SEQUENCE {
one [GROUP] [SINGULAR-INSERTIONS] CHOICE {
two UTF8String,
... -- Extension insertion point (I1).
},
three [GROUP] CHOICE {
four UTF8String,
... -- Extension insertion point (I2).
}
}
SEQUENCE { one [GROUP] [SINGULAR-INSERTIONS] CHOICE { two UTF8String, ... -- Extension insertion point (I1). }, three [GROUP] CHOICE { four UTF8String, ... -- Extension insertion point (I2). } }
The associated grammar is:
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 ::=
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:
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:
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) = { "*" }
First(P2) = { "two" } First(P12) = { "*" } Preselected(P2) = Preselected(P12) = false Empty(P2) = Empty(P12) = false Follow(one) = { "four", "*", "$" } Select(P2) = First(P2) = { "two" } Select(P12) = First(P12) = { "*" }
The sets for P5 and P6 are no longer generated, and the remaining sets are unchanged.
The sets for P5 and P6 are no longer generated, and the remaining sets are unchanged.
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.
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.
Legg Experimental [Page 81] RFC 4911 Encoding Instructions for RXER July 2007
Legg Experimental [Page 81] RFC 4911 Encoding Instructions for RXER July 2007
Now consider the type definition using the UNIFORM-INSERTIONS encoding instruction instead:
Now consider the type definition using the UNIFORM-INSERTIONS encoding instruction instead:
SEQUENCE {
one [GROUP] [UNIFORM-INSERTIONS] CHOICE {
two UTF8String,
... -- Extension insertion point (I1).
},
three [GROUP] CHOICE {
four UTF8String,
... -- Extension insertion point (I2).
}
}
SEQUENCE { one [GROUP] [UNIFORM-INSERTIONS] CHOICE { two UTF8String, ... -- Extension insertion point (I1). }, three [GROUP] CHOICE { four UTF8String, ... -- Extension insertion point (I2). } }
The associated grammar is:
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 ::=
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:
This grammar leads to the following sets and predicates for the P2, P13, P14, P15, and P6 productions:
First(P2) = { "two" }
First(P13) = { "*" }
First(P14) = { "*1" }
Preselected(P2) = Preselected(P13) = Preselected(P14) = false
Empty(P2) = Empty(P13) = Empty(P14) = false
Follow(one) = { "four", "*", "$" }
Select(P2) = First(P2) = { "two" }
Select(P13) = First(P13) = { "*" }
Select(P14) = First(P14) = { "*1" }
First(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" }
Legg Experimental [Page 82] RFC 4911 Encoding Instructions for RXER July 2007
Legg Experimental [Page 82] RFC 4911 Encoding Instructions for RXER July 2007
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", "*", "$" }
First(P15) = { "*1" } First(P6) = { } Preselected(P15) = Preselected(P6) = Empty(P15) = false Empty(P6) = true Follow(I1) = { "four", "*", "$" } Select(P15) = First(P15) = { "*1" } Select(P6) = First(P6) + Follow(I1) = { "four", "*", "$" }
The remaining sets are unchanged.
The 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.
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.
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.
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.
B.4. Example 4
B.4. Example 4
Consider the following type definition:
Consider the following type definition:
SEQUENCE OF one [GROUP] CHOICE {
two UTF8String,
... -- Extension insertion point (I1).
}
SEQUENCE OF one [GROUP] CHOICE { two UTF8String, ... -- Extension insertion point (I1). }
The associated grammar is:
The associated grammar is:
P1: S ::= one S
P2: S ::=
P3: one ::= two
P4: one ::= I1
P5: two ::= "two"
P6: I1 ::= "*" I1
P7: I1 ::=
P1: S ::= one S P2: S ::= P3: one ::= two P4: one ::= I1 P5: two ::= "two" P6: I1 ::= "*" I1 P7: I1 ::=
Legg Experimental [Page 83] RFC 4911 Encoding Instructions for RXER July 2007
Legg Experimental [Page 83] RFC 4911 Encoding Instructions for RXER July 2007
This grammar leads to the following sets and predicates:
This grammar leads to the following sets and predicates:
First(P1) = { "two", "*" }
First(P2) = { }
Preselected(P1) = Preselected(P2) = false
Empty(P1) = Empty(P2) = true
Follow(S) = { "$" }
Select(P1) = First(P1) + Follow(S) = { "two", "*", "$" }
Select(P2) = First(P2) + Follow(S) = { "$" }
First(P1) = { "two", "*" } First(P2) = { } Preselected(P1) = Preselected(P2) = false Empty(P1) = Empty(P2) = true Follow(S) = { "$" } Select(P1) = First(P1) + Follow(S) = { "two", "*", "$" } Select(P2) = First(P2) + Follow(S) = { "$" }
First(P3) = { "two" }
First(P4) = { "*" }
Preselected(P3) = Preselected(P4) = Empty(P3) = false
Empty(P4) = true
Follow(one) = { "two", "*", "$" }
Select(P3) = First(P3) = { "two" }
Select(P4) = First(P4) + Follow(one) = { "*", "two", "$" }
First(P3) = { "two" } First(P4) = { "*" } Preselected(P3) = Preselected(P4) = Empty(P3) = false Empty(P4) = true Follow(one) = { "two", "*", "$" } Select(P3) = First(P3) = { "two" } Select(P4) = First(P4) + Follow(one) = { "*", "two", "$" }
First(P6) = { "*" }
First(P7) = { }
Preselected(P6) = Preselected(P7) = Empty(P6) = false
Empty(P7) = true
Follow(I1) = { "two", "*", "$" }
Select(P6) = First(P6) = { "*" }
Select(P7) = First(P7) + Follow(I1) = { "two", "*", "$" }
First(P6) = { "*" } First(P7) = { } Preselected(P6) = Preselected(P7) = Empty(P6) = false Empty(P7) = true Follow(I1) = { "two", "*", "$" } Select(P6) = First(P6) = { "*" } Select(P7) = First(P7) + Follow(I1) = { "two", "*", "$" }
The intersection of Select(P1) and Select(P2) is not empty, as is the intersection of Select(P3) and Select(P4) and the intersection of Select(P6) and Select(P7); hence, the grammar is not deterministic, and the type definition is not valid. If a decoder encounters two or more unrecognized elements in a row, then it cannot determine whether this represents one instance or more than one instance of the "one" component. Even without unrecognized elements, there is still a problem that an encoding could contain an indeterminate number of "one" components using an extension that generates no elements.
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.
The non-determinism cannot be resolved with a UNIFORM-INSERTIONS encoding instruction. Consider this revised type definition using the UNIFORM-INSERTIONS encoding instruction:
The non-determinism cannot be resolved with a UNIFORM-INSERTIONS encoding instruction. Consider this revised type definition using the UNIFORM-INSERTIONS encoding instruction:
SEQUENCE OF one [GROUP] [UNIFORM-INSERTIONS] CHOICE {
two UTF8String,
... -- Extension insertion point (I1).
}
SEQUENCE OF one [GROUP] [UNIFORM-INSERTIONS] CHOICE { two UTF8String, ... -- Extension insertion point (I1). }
Legg Experimental [Page 84] RFC 4911 Encoding Instructions for RXER July 2007
Legg Experimental [Page 84] RFC 4911 Encoding Instructions for RXER July 2007
The associated grammar is:
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 ::=
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:
This grammar leads to the following sets and predicates:
First(P1) = { "two", "*", "*1" }
First(P2) = { }
Preselected(P1) = Preselected(P2) = Empty(P1) = false
Empty(P2) = true
Follow(S) = { "$" }
Select(P1) = First(P1) = { "two", "*", "*1" }
Select(P2) = First(P2) + Follow(S) = { "$" }
First(P1) = { "two", "*", "*1" } First(P2) = { } Preselected(P1) = Preselected(P2) = Empty(P1) = false Empty(P2) = true Follow(S) = { "$" } Select(P1) = First(P1) = { "two", "*", "*1" } Select(P2) = First(P2) + Follow(S) = { "$" }
First(P3) = { "two" }
First(P8) = { "*" }
First(P9) = { "*1" }
Preselected(P3) = Preselected(P8) = Preselected(P9) = false
Empty(P3) = Empty(P8) = Empty(P9) = false
Follow(one) = { "two", "*", "*1", "$" }
Select(P3) = First(P3) = { "two" }
Select(P8) = First(P8) = { "*" }
Select(P9) = First(P9) = { "*1" }
First(P3) = { "two" } First(P8) = { "*" } First(P9) = { "*1" } Preselected(P3) = Preselected(P8) = Preselected(P9) = false Empty(P3) = Empty(P8) = Empty(P9) = false Follow(one) = { "two", "*", "*1", "$" } Select(P3) = First(P3) = { "two" } Select(P8) = First(P8) = { "*" } Select(P9) = First(P9) = { "*1" }
First(P10) = { "*1" }
First(P7) = { }
Preselected(P10) = Preselected(P7) = Empty(P10) = false
Empty(P7) = true
Follow(I1) = { "two", "*", "*1", "$" }
Select(P10) = First(P10) = { "*1" }
Select(P7) = First(P7) + Follow(I1) = { "two", "*", "*1", "$" }
First(P10) = { "*1" } First(P7) = { } Preselected(P10) = Preselected(P7) = Empty(P10) = false Empty(P7) = true Follow(I1) = { "two", "*", "*1", "$" } Select(P10) = First(P10) = { "*1" } Select(P7) = First(P7) + Follow(I1) = { "two", "*", "*1", "$" }
The intersection of Select(P1) and Select(P2) is now empty, but the intersection of Select(P10) and Select(P7) is not; hence, the grammar is not deterministic, and the type definition is not valid. The problem of an indeterminate number of "one" components from an extension that generates no elements has been solved. However, if a decoder encounters a series of elements with the same name, it cannot determine whether this represents one instance or more than one instance of the "one" component.
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.
Legg Experimental [Page 85] RFC 4911 Encoding Instructions for RXER July 2007
Legg Experimental [Page 85] RFC 4911 Encoding Instructions for RXER July 2007
The non-determinism can be fully resolved with a SINGULAR-INSERTIONS encoding instruction. Consider this revised type definition:
The non-determinism can be fully resolved with a SINGULAR-INSERTIONS encoding instruction. Consider this revised type definition:
SEQUENCE OF one [GROUP] [SINGULAR-INSERTIONS] CHOICE {
two UTF8String,
... -- Extension insertion point (I1).
}
SEQUENCE OF one [GROUP] [SINGULAR-INSERTIONS] CHOICE { two UTF8String, ... -- Extension insertion point (I1). }
The associated grammar is:
The associated grammar is:
P1: S ::= one S
P2: S ::=
P3: one ::= two
P8: one ::= "*"
P5: two ::= "two"
P1: S ::= one S P2: S ::= P3: one ::= two P8: one ::= "*" P5: two ::= "two"
This grammar leads to the following sets and predicates:
This grammar leads to the following sets and predicates:
First(P1) = { "two", "*" }
First(P2) = { }
Preselected(P1) = Preselected(P2) = Empty(P1) = false
Empty(P2) = true
Follow(S) = { "$" }
Select(P1) = First(P1) = { "two", "*" }
Select(P2) = First(P2) + Follow(S) = { "$" }
First(P1) = { "two", "*" } First(P2) = { } Preselected(P1) = Preselected(P2) = Empty(P1) = false Empty(P2) = true Follow(S) = { "$" } Select(P1) = First(P1) = { "two", "*" } Select(P2) = First(P2) + Follow(S) = { "$" }
First(P3) = { "two" }
First(P8) = { "*" }
Preselected(P3) = Preselected(P8) = false
Empty(P3) = Empty(P8) = false
Follow(one) = { "two", "*", "$" }
Select(P3) = First(P3) = { "two" }
Select(P8) = First(P8) = { "*" }
First(P3) = { "two" } First(P8) = { "*" } Preselected(P3) = Preselected(P8) = false Empty(P3) = Empty(P8) = false Follow(one) = { "two", "*", "$" } Select(P3) = First(P3) = { "two" } Select(P8) = First(P8) = { "*" }
The intersection of Select(P1) and Select(P2) is empty, as is the intersection of Select(P3) and Select(P8); hence, the grammar is deterministic, and the type definition is valid. A decoder now knows that every extension to the "one" component will generate a single element, so the correct number of "one" components will be decoded.
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.
Legg Experimental [Page 86] RFC 4911 Encoding Instructions for RXER July 2007
Legg Experimental [Page 86] RFC 4911 Encoding Instructions for RXER July 2007
Appendix C. Extension and Versioning Examples
Appendix C. Extension and Versioning Examples
This appendix is non-normative.
This appendix is non-normative.
C.1. Valid Extensions for Insertion Encoding Instructions
C.1. Valid Extensions for Insertion Encoding Instructions
The first example shows extensions that satisfy the HOLLOW-INSERTIONS encoding instruction.
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
}
}
[HOLLOW-INSERTIONS] CHOICE { one BOOLEAN, ..., two [ATTRIBUTE] INTEGER, three [GROUP] SEQUENCE { four [ATTRIBUTE] UTF8String, five [ATTRIBUTE] INTEGER OPTIONAL, ... }, six [GROUP] CHOICE { seven [ATTRIBUTE] BOOLEAN, eight [ATTRIBUTE] INTEGER } }
The "two" and "six" components generate only attributes.
The "two" and "six" components generate only attributes.
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.
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.
The second example shows extensions that satisfy the SINGULAR-INSERTIONS encoding instruction.
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
}
}
[SINGULAR-INSERTIONS] CHOICE { one BOOLEAN, ..., two INTEGER, three [GROUP] SEQUENCE { four [ATTRIBUTE] UTF8String, five INTEGER }, six [GROUP] CHOICE { seven BOOLEAN, eight INTEGER } }
Legg Experimental [Page 87] RFC 4911 Encoding Instructions for RXER July 2007
Legg Experimental [Page 87] RFC 4911 Encoding Instructions for RXER July 2007
The "two" component will always generate a single <two> element.
The "two" component will always generate a single <two> element.
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.
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.
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.
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.
The third example shows extensions that satisfy the UNIFORM-INSERTIONS encoding instruction.
3番目の例は、UNIFORM-INSERTIONSを満たす拡大が指示をコード化するのを示します。
[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
}
}
[一定の入] 選択1つ、ブール、…、2INTEGER、3[GROUP]SEQUENCE SIZE(1..MAX)OF4INTEGER、5[GROUP]SEQUENCE、6[ATTRIBUTE]UTF8String OPTIONAL、7INTEGER、8[GROUP]CHOICE9ブール10[GROUP]SEQUENCE SIZE(1..MAX)OF eleven INTEGER
The "two" component will always generate a single <two> element.
「2」コンポーネントは、いつも単一の<が2>要素であると生成するでしょう。
The "three" component will always generate one or more <four> elements.
「3」コンポーネントはいつも4つの>要素を1<に生成するでしょう。
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-INSERTIONSによって許容されています。
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つ以上の要素がいずれにもあるに違いないという要件を満たすでしょう。
Legg Experimental [Page 88] RFC 4911 Encoding Instructions for RXER July 2007
2007年7月にRXERのために指示をコード化するLeggの実験的な[88ページ]RFC4911
C.2. Versioning Example
C.2。 例をVersioningします。
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,
...
},
...
}
MyMessageType:、:= 系列バージョン[ATTRIBUTE][バージョン-INDICATOR]UTF8String、(「1インチ、…)、デフォルト、「1インチ、1つ[グループ]の[まれな入]選択2論理演算子、……、」
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のためにCHOICEに加えられることです。 指示をコード化するSINGULAR-INSERTIONSを満たさないので、この変化はフォワード互換性がありません。 したがって、同時に(または、それが既に存在していなかったなら、加えられる)、バージョンインディケータ属性をアップデートしなければなりません。 これはバージョン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
},
...
}
MyMessageType:、:= 系列バージョン[ATTRIBUTE][バージョン-INDICATOR]UTF8String、(「1インチ、…、「1.1インチ) デフォルト、「1インチ、1つ[グループ]の[まれな入]選択2論理演算子、…、3[属性]整数--バージョン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.1conformantアプリケーションがMyMessageTypeの値にバージョン1.1拡張子を使用していないなら、それは「1インチ」にバージョン属性の値を設定できます。
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組の要素はバージョン1.2のためにCHOICEに加えられます。 一方、変化は指示をコード化するSINGULAR-INSERTIONSを満たしません。 バージョン1.2のための型定義は以下の通りです。
Legg Experimental [Page 89] RFC 4911 Encoding Instructions for RXER July 2007
2007年7月にRXERのために指示をコード化するLeggの実験的な[89ページ]RFC4911
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
},
...
}
MyMessageType:、:= 系列バージョン[ATTRIBUTE][バージョン-INDICATOR]UTF8String、(「1インチ、…、「1.1インチ|、「1.2インチ) デフォルト、「1インチ、1つ[グループ]の[まれな入]選択2論理演算子、…、3[属性]整数--バージョン1.1 4[グループ]系列で、5UTF8String、6GeneralizedTimeを加えます--バージョン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.2conformantアプリケーションがMyMessageTypeの値にバージョン1.2拡張子を使用していないなら、それは「1.1インチ」にバージョン属性の値を設定できます。 どちらの拡大も使用していないなら、それは「1インチ」にバージョン属性の値を設定できます。
Author's Address
作者のアドレス
Dr. Steven Legg eB2Bcom Suite 3, Woodhouse Corporate Centre 935 Station Street Box Hill North, Victoria 3129 AUSTRALIA
スティーブンLegg eB2Bcom Suite博士3、北のウッドハウス法人のセンター935駅の通りBoxヒル、ビクトリア・3129オーストラリア
Phone: +61 3 9896 7830 Fax: +61 3 9896 7801 EMail: steven.legg@eb2bcom.com
以下に電話をしてください。 +61 3 9896 7830、Fax: +61 3 9896 7801はメールされます: steven.legg@eb2bcom.com
Legg Experimental [Page 90] RFC 4911 Encoding Instructions for RXER July 2007
2007年7月にRXERのために指示をコード化するLeggの実験的な[90ページ]RFC4911
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Legg Experimental [Page 91]
Legg実験的です。[91ページ]
一覧
スポンサーリンク
