RFC4910 日本語訳
4910 Robust XML Encoding Rules (RXER) for Abstract Syntax Notation One(ASN.1). S. Legg, D. Prager. July 2007. (Format: TXT=182175 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group S. Legg
Request for Comments: 4910 eB2Bcom
Category: Experimental D. Prager
July 2007
Leggがコメントのために要求するワーキンググループS.をネットワークでつないでください: 4910年のeB2Bcomカテゴリ: 実験的なD.プラーガー2007年7月
Robust XML Encoding Rules (RXER) for
Abstract Syntax Notation One (ASN.1)
抽象構文記法1のための強健なXML符号化規則(RXER)(ASN.1)
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 a set of Abstract Syntax Notation One (ASN.1) encoding rules, called the Robust XML Encoding Rules or RXER, that produce an Extensible Markup Language (XML) representation for values of any given ASN.1 data type. Rules for producing a canonical RXER encoding are also defined.
このドキュメントはASN.1データ型を考えて、いずれの値の拡張マークアップ言語(XML)表現を作成するRobust XML Encoding RulesかRXERと呼ばれる1セットの抽象的なSyntax Notation One(ASN.1)符号化規則を定義します。 また、正準なRXERコード化を生産するための規則は定義されます。
Legg & Prager Experimental [Page 1] RFC 4910 Robust XML Encoding Rules July 2007
強健な[1ページ]RFC4910XML符号化規則2007年7月に実験的なLeggとプラーガー
Table of Contents
目次
1. Introduction ....................................................3
2. Conventions .....................................................4
3. Definitions .....................................................5
4. Additional Basic Types ..........................................6
4.1. The Markup Type ............................................6
4.1.1. Self-Containment ....................................9
4.1.2. Normalization for Canonical Encoding Rules .........12
4.2. The AnyURI Type ...........................................13
4.3. The NCName Type ...........................................14
4.4. The Name Type .............................................14
4.5. The QName Type ............................................14
5. Expanded Names for ASN.1 Types .................................15
6. Encoding Rules .................................................17
6.1. Identifiers ...............................................19
6.2. Component Encodings .......................................20
6.2.1. Referenced Components ..............................20
6.2.2. Element Components .................................20
6.2.2.1. Namespace Properties for Elements .........22
6.2.2.2. Namespace Prefixes for Element Names ......24
6.2.3. Attribute Components ...............................25
6.2.3.1. Namespace Prefixes for Attribute Names ....26
6.2.4. Unencapsulated Components ..........................26
6.2.5. Examples ...........................................27
6.3. Standalone Encodings ......................................28
6.4. Embedded ASN.1 Values .....................................28
6.5. Type Referencing Notations ................................32
6.6. TypeWithConstraint, SEQUENCE OF Type, and SET OF Type .....33
6.7. Character Data Translations ...............................34
6.7.1. Restricted Character String Types ..................35
6.7.2. BIT STRING .........................................36
6.7.3. BOOLEAN ............................................38
6.7.4. ENUMERATED .........................................38
6.7.5. GeneralizedTime ....................................39
6.7.6. INTEGER ............................................41
6.7.7. NULL ...............................................42
6.7.8. ObjectDescriptor ...................................43
6.7.9. OBJECT IDENTIFIER and RELATIVE-OID .................43
6.7.10. OCTET STRING ......................................43
6.7.11. QName .............................................44
6.7.11.1. Namespace Prefixes for Qualified Names ...44
6.7.12. REAL ..............................................45
6.7.13. UTCTime ...........................................46
6.7.14. CHOICE as UNION ...................................47
6.7.15. SEQUENCE OF as LIST ...............................50
6.8. Combining Types ...........................................50
6.8.1. CHARACTER STRING ...................................51
1. 序論…3 2. コンベンション…4 3. 定義…5 4. 追加基本型…6 4.1. マークアップタイプ…6 4.1.1. 自己封じ込め…9 4.1.2. 正準なコード化のための正常化は統治されます…12 4.2. AnyURIはタイプします…13 4.3. NCNameはタイプします…14 4.4. タイプという名前…14 4.5. QNameはタイプします…14 5. ASN.1タイプのために名前を広げます…15 6. コード化は統治されます…17 6.1. 識別子…19 6.2. コンポーネントEncodings…20 6.2.1. コンポーネントに、参照をつけます…20 6.2.2. 要素成分…20 6.2.2.1. Elementsのための名前空間の特性…22 6.2.2.2. 名前空間は要素のために名前を前に置きます…24 6.2.3. コンポーネントを結果と考えてください…25 6.2.3.1. 名前空間は属性のために名前を前に置きます…26 6.2.4. コンポーネントをUnencapsulatedしました…26 6.2.5. 例…27 6.3. スタンドアロンEncodings…28 6.4. ASN.1値を埋め込みます…28 6.5. 記法に参照をつけて、タイプしてください…32 6.6. TypeWithConstraint、タイプ、およびタイプのセットの系列…33 6.7. キャラクターデータ変換…34 6.7.1. 制限されたキャラクターストリングはタイプされます…35 6.7.2. ビット列…36 6.7.3. 論理演算子…38 6.7.4. 列挙されます…38 6.7.5. GeneralizedTime…39 6.7.6. 整数…41 6.7.7. ヌル…42 6.7.8. ObjectDescriptor…43 6.7.9. 識別子と親類-OIDは反対します…43 6.7.10. 八重奏ストリング…43 6.7.11. QName…44 6.7.11.1. 適切な名前のための名前空間接頭語…44 6.7.12. 本当…45 6.7.13. UTCTime…46 6.7.14. 組合としての選択…47 6.7.15. 系列、リストとして…50 6.8. タイプを結合します…50 6.8.1. キャラクタストリング…51
Legg & Prager Experimental [Page 2] RFC 4910 Robust XML Encoding Rules July 2007
強健な[2ページ]RFC4910XML符号化規則2007年7月に実験的なLeggとプラーガー
6.8.2. CHOICE .............................................51
6.8.3. EMBEDDED PDV .......................................52
6.8.4. EXTERNAL ...........................................52
6.8.5. INSTANCE OF ........................................52
6.8.6. SEQUENCE and SET ...................................52
6.8.7. SEQUENCE OF and SET OF .............................54
6.8.8. Extensible Combining Types .........................55
6.8.8.1. Unknown Elements in Extensions ............55
6.8.8.2. Unknown Attributes in Extensions ..........59
6.9. Open Type .................................................60
6.10. Markup ...................................................61
6.11. Namespace Prefixes for CRXER .............................63
6.12. Serialization ............................................65
6.12.1. Non-Canonical Serialization .......................65
6.12.2. Canonical Serialization ...........................68
6.12.3. Unicode Normalization in XML Version 1.1 ..........70
6.13. Syntax-Based Canonicalization ............................70
7. Transfer Syntax Identifiers ....................................71
7.1. RXER Transfer Syntax ......................................71
7.2. CRXER Transfer Syntax .....................................71
8. Relationship to XER ............................................71
9. Security Considerations ........................................73
10. Acknowledgements ..............................................74
11. IANA Considerations ...........................................75
12. References ....................................................75
12.1. Normative References .....................................75
12.2. Informative References ...................................77
Appendix A. Additional Basic Definitions Module ...................78
6.8.2. 選択…51 6.8.3. PDVを埋め込みます…52 6.8.4. 外部…52 6.8.5. インスタンス、…52 6.8.6. 系列とセット…52 6.8.7. そして、系列、セットされます…54 6.8.8. 広げることができる結合はタイプします…55 6.8.8.1. 拡大での未知のElements…55 6.8.8.2. 拡大における未知の属性…59 6.9. タイプを開いてください…60 6.10. マークアップ…61 6.11. CRXERのための名前空間接頭語…63 6.12. 連載…65 6.12.1. 正典外の連載…65 6.12.2. 正準な連載…68 6.12.3. XMLバージョン1.1におけるユニコード正常化…70 6.13. 構文ベースのCanonicalization…70 7. 構文識別子を移してください…71 7.1. RXERは構文を移します…71 7.2. CRXERは構文を移します…71 8. XERとの関係…71 9. セキュリティ問題…73 10. 承認…74 11. IANA問題…75 12. 参照…75 12.1. 標準の参照…75 12.2. 有益な参照…77の付録のA.の追加基本的な定義モジュール…78
1. Introduction
1. 序論
This document defines a set of Abstract Syntax Notation One (ASN.1) [X.680] encoding rules, called the Robust XML Encoding Rules or RXER, that produce an Extensible Markup Language (XML) [XML10][XML11] representation of ASN.1 values of any given ASN.1 type.
このドキュメントはASN.1タイプを考えて、いずれのASN.1値の拡張マークアップ言語(XML)[XML10][XML11]表現を作成するRobust XML Encoding RulesかRXERと呼ばれる1セットの抽象的なSyntax Notation One(ASN.1)[X.680]符号化規則を定義します。
An ASN.1 value is regarded as analogous to the content and attributes of an XML element, or in some cases, just an XML attribute value. The RXER encoding of an ASN.1 value is the well-formed and valid content and attributes of an element, or an attribute value, in an XML document [XML10][XML11] conforming to XML namespaces [XMLNS10][XMLNS11]. Simple ASN.1 data types such as PrintableString, INTEGER, and BOOLEAN define character data content or attribute values, while the ASN.1 combining types (i.e., SET, SEQUENCE, SET OF, SEQUENCE OF, and CHOICE) define element content and attributes. The attribute and child element names are generally provided by the identifiers of the components in combining type definitions, i.e., elements and attributes correspond to the NamedType notation.
ASN.1値はXML要素の内容と属性、またはいくつかの場合まさしくXML属性値への類似と見なされます。 ASN.1価値のRXERコード化は、整形式の、そして、有効な内容と要素の属性か、属性値です、XML名前空間[XMLNS10][XMLNS11]に一致しているXMLドキュメント[XML10][XML11]で。 INTEGERの、そして、ブールのPrintableStringなどの簡単なASN.1データ型、キャラクタデータ内容か属性値を定義してください、タイプを結合する(すなわち、SET、SEQUENCE、SET OF、SEQUENCE OF、およびCHOICE)ASN.1は要素含有量と属性を定義しますが。 一般に、コンポーネントに関する識別子で属性と子供要素名を型定義を結合するのに提供します、すなわち、要素と属性はNamedType記法に対応しています。
Legg & Prager Experimental [Page 3] RFC 4910 Robust XML Encoding Rules July 2007
強健な[3ページ]RFC4910XML符号化規則2007年7月に実験的なLeggとプラーガー
RXER leaves some formatting details to the discretion of the encoder, so there is not a single unique RXER encoding for an ASN.1 value. However, this document also defines a restriction of RXER, called the Canonical Robust XML Encoding Rules (CRXER), which does produce a single unique encoding for an ASN.1 value. Obviously, the CRXER encoding of a value is also a valid RXER encoding of that value. The restrictions on RXER to produce the CRXER encoding are interspersed with the description of the rules for RXER.
RXERがいくつかの形式の詳細をエンコーダに任せるので、ASNのために.1値をコード化する独身のユニークなRXERがありません。 しかしながら、また、このドキュメントはASN.1価値のための単一のユニークなコード化を生産するCanonical Robust XML Encoding Rules(CRXER)と呼ばれるRXERの制限を定義します。 明らかに、また、価値のCRXERコード化はその価値をコード化する有効なRXERです。 CRXERコード化を生産するRXERにおける制限はRXERのために規則の記述で点在します。
Note that "ASN.1 value" does not mean a Basic Encoding Rules (BER) [X.690] encoding. The ASN.1 value is an abstract concept that is independent of any particular encoding. BER is just one possible way to encode an ASN.1 value. This document defines an alternative way to encode an ASN.1 value.
「ASN.1値」がBasic Encoding Rules(BER)[X.690]コード化を意味しないことに注意してください。 ASN.1値はどんな特定のコード化からも独立している抽象概念です。 BERはASN.1値をコード化するちょうど1つの可能な方法です。 このドキュメントはASN.1値をコード化する代替の方法を定義します。
A separate document [RXEREI] defines encoding instructions [X.680-1] that may be used in an ASN.1 specification to modify how values are encoded in RXER, for example, to encode a component of a combining ASN.1 type as an attribute rather than as a child element. A pre-existing ASN.1 specification will not have RXER encoding instructions, so any mention of encoding instructions in this document can be ignored when dealing with such specifications. Encoding instructions for other encoding rules have no effect on RXER encodings.
例えば、値が子供要素としてというよりむしろ属性として結合ASN.1タイプの成分をコード化するためにRXERでどうコード化されるかを変更するのにASN.1仕様で使用されるかもしれない指示[X.680-1]をコード化する[RXEREI]が定義する別々のドキュメント。 RXERが先在のASN.1仕様で指示をコード化しないので、そのような仕様に対処するとき、本書では指示をコード化するどんな言及も無視できます。 他の符号化規則のための指示をコード化して、RXER encodingsで効き目がしないでください。
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意味と共に排他的に使用されます。
A reference to an ASN.1 production [X.680] (e.g., Type, NamedType) is a reference to the text in an ASN.1 specification corresponding to that production.
ASN.1生産[X.680](例えば、Type、NamedType)の参照はその生産に対応するASN.1仕様によるテキストの参照です。
The specification of RXER makes use of definitions from the XML Information Set (Infoset) [INFOSET]. In particular, information item property names follow the Infoset convention of being shown in square brackets, e.g., [local name]. Literal values of Infoset properties are enclosed in double quotes; however, the double quotes are not part of the property values. In the sections that follow, "information item" will be abbreviated to "item", e.g., "element information item" is abbreviated to "element item". The term "element" or "attribute" (without the "item") is referring to an element or attribute in an XML document, rather than an information item.
RXERの仕様はXML情報Set(Infoset)[INFOSET]から定義を利用します。 特に、情報項目特性の名は角括弧、例えば、[地方名]で示されるInfosetコンベンションに続きます。 Infosetの特性の文字通りの値は二重引用符に同封されます。 しかしながら、二重引用符は特性の値の一部ではありません。 従うセクションでは、「情報項目」は「項目」に簡略化されて、例えば、「要素情報の品目」は「要素の品目」に簡略化されています。 「要素」か「属性」(「項目」のない)という用語は情報項目よりむしろXMLドキュメントの要素か属性を示しています。
Legg & Prager Experimental [Page 4] RFC 4910 Robust XML Encoding Rules July 2007
強健な[4ページ]RFC4910XML符号化規則2007年7月に実験的なLeggとプラーガー
Literal character strings to be used in an RXER encoding appear within double quotes; however, the double quotes are not part of the literal value and do not appear in the encoding.
RXERコード化に使用されるべき文字通りの文字列は二重引用符の中に現れます。 しかしながら、二重引用符は、文字通りの価値の一部でなく、またコード化に現れません。
This document uses the namespace prefix [XMLNS10][XMLNS11] "asnx:" to stand for the namespace name "urn:ietf:params:xml:ns:asnx", uses the namespace prefix "xs:" to stand for the namespace name "http://www.w3.org/2001/XMLSchema", and uses the namespace prefix "xsi:" to stand for the namespace name "http://www.w3.org/2001/XMLSchema-instance". However, in practice, any valid namespace prefixes are permitted in non-canonical RXER encodings (namespace prefixes are deterministically generated for CRXER).
名前空間が前に置くこのドキュメント用途[XMLNS10][XMLNS11]は「以下をasnxします」。 名前空間名の「つぼ:ietf:params:xml:ナノ秒: asnx」、用途を表すために、名前空間接頭語は「以下をxsします」。 名前空間を表すために、" http://www.w3.org/2001/XMLSchema "を命名してください。そうすれば、名前空間が前に置く用途は「以下をxsiします」。 名前空間を表すには、" http://www.w3.org/2001/XMLSchema-instance "を命名してください。 しかしながら、実際には、どんな有効な名前空間接頭語も正典外のRXER encodingsで受入れられます(名前空間接頭語はCRXERのために決定論的に生成されます)。
The encoding instructions [X.680-1] referenced by name in this specification are encoding instructions for RXER [RXEREI].
名前によって参照をつけられるコード化指示[X.680-1]はRXER[RXEREI]のためにこの仕様で指示をコード化しています。
Throughout this document, references to the Markup, AnyURI, NCName, Name, and QName ASN.1 types are references to the types described in Section 4 and consolidated in the AdditionalBasicDefinitions module in Appendix A. Any provisions associated with the reference do not apply to types defined in other ASN.1 modules that happen to have these same names.
このドキュメント中では、Markup、AnyURI、NCName、Name、およびQName ASN.1タイプについての言及はセクション4で説明されて、AdditionalBasicDefinitionsモジュールに統合されたタイプが参照に関連している条項がたまたまこれらの同じ名前を持っている他のASN.1モジュールで定義されたタイプに当てはまらないAppendix A.Anyでの言及です。
Code points for characters [UCS][UNICODE] are expressed using the Unicode convention U+n, where n is four to six hexadecimal digits, e.g., the space character is U+0020.
キャラクタ[UCS][ユニコード]のためのコード・ポイントは、ユニコードコンベンションU+n(nが4〜6つの16進数字である、例えば、間隔文字はU+0020です)を使用することで言い表されます。
3. Definitions
3. 定義
Definition (white space character): A white space character is a space (U+0020), tab (U+0009), carriage return (U+000D), or line feed (U+000A) character.
定義(余白キャラクタ): 余白キャラクタはスペース(U+0020)、タブ(U+0009)、復帰(U+000D)、または改行(U+000A)キャラクタです。
Definition (white space): White space is a sequence of one or more white space characters.
定義(余白): 余白は1つ以上の余白キャラクタの系列です。
Definition (line break): A line break is any sequence of characters that is normalized to a line feed by XML End-of-Line Handling [XML10][XML11].
定義(ラインブレイク): ラインブレイクは線のXML End Handling[XML10][XML11]によって改行に正常にされるキャラクタのあらゆる系列です。
Definition (serialized white space): Serialized white space is a sequence of one or more white space characters and/or line breaks.
定義(余白を連載します): 連載された余白は1つ以上の余白キャラクタ、そして/または、ラインブレイクの系列です。
Definition (declaring the default namespace): A namespace declaration attribute item is declaring the default namespace if the [prefix] of the attribute item has no value, the [local name] of the attribute item is "xmlns" and the [normalized value] is not empty.
定義(デフォルト名前空間を宣言します): そして、属性項目の[接頭語]に値が全くないなら属性項目がデフォルト名前空間を宣言しているという名前空間宣言、属性項目の[地方名]が"xmlns"である、[正常にされた値]は空ではありません。
Legg & Prager Experimental [Page 5] RFC 4910 Robust XML Encoding Rules July 2007
強健な[5ページ]RFC4910XML符号化規則2007年7月に実験的なLeggとプラーガー
Definition (undeclaring the default namespace): A namespace declaration attribute item is undeclaring the default namespace if the [prefix] of the attribute item has no value, the [local name] of the attribute item is "xmlns" and the [normalized value] is empty (i.e., xmlns="").
定義(デフォルト名前空間を非宣言します): そして、「属性項目の[接頭語]に値が全くないなら属性項目がデフォルト名前空間を非宣言しているという名前空間宣言、属性項目の[地方名]が"xmlns"である、[正常にされた値]が空である、(すなわち、xmlns=、」、」、)
Definition (canonical namespace prefix): A canonical namespace prefix is an NCName [XMLNS10] beginning with the letter 'n' (U+006E) followed by a non-negative number string. A non-negative number string is either the digit character '0' (U+0030), or a non-zero decimal digit character (U+0031-U+0039) followed by zero, one, or more of the decimal digit characters '0' to '9' (U+0030-U+0039).
定義(正準な名前空間接頭語): ''正準な名前空間接頭語は手紙で始まるNCName[XMLNS10]です、そして、(U+006E)は非負数ストリングで続きました。 非負数ストリングは、ゼロ('9'(U+0030U+0039)への10進数字キャラクタ'0'のより多くのひとり)がいうことになったケタキャラクタ'0'(U+0030)か非ゼロ10進数字キャラクタ(U+0031U+0039)のどちらかです。
For convenience, a CHOICE type where the ChoiceType is subject to a UNION encoding instruction will be referred to as a UNION type, and a SEQUENCE OF type where the SequenceOfType is subject to a LIST encoding instruction will be referred to as a LIST type.
便利において、ChoiceTypeは指示をコード化するUNIONを受けることがあるCHOICEタイプがUNIONタイプと呼ばれるでしょう、そして、SequenceOfTypeは指示をコード化するLISTを受けることがあるSEQUENCE OFタイプがLISTタイプと呼ばれるでしょう。
4. Additional Basic Types
4. 追加基本型
This section defines an ASN.1 type for representing markup in abstract values, as well as basic types that are useful in encoding instructions [RXEREI] and other related specifications [ASN.X].
このセクションは抽象的な値でマーク付けを表すためのASN.1タイプを定義します、指示をコード化する際に役に立つ基本型[RXEREI]と他の関連する仕様[ASN.X]と同様に。
The ASN.1 definitions in this section are consolidated in the AdditionalBasicDefinitions ASN.1 module in Appendix A.
このセクションとのASN.1定義はAppendix AのAdditionalBasicDefinitions ASN.1モジュールに統合されます。
4.1. The Markup Type
4.1. マークアップタイプ
A value of the Markup ASN.1 type holds the [prefix], [attributes], [namespace attributes], and [children] of an element item, i.e., the content and attributes of an element.
すなわち、要素の品目、内容のMarkup ASN.1タイプ船倉[接頭語]、[属性]、[名前空間属性]、および[子供]の値と要素の属性。
RXER has special provisions for encoding values of the Markup type (see Section 6.10). For other encoding rules, a value of the Markup type is encoded according to the following ASN.1 type definition (with AUTOMATIC TAGS):
RXERには、Markupタイプの値をコード化するための特別条項があります(セクション6.10を見てください)。 他の符号化規則において、以下のASN.1型定義(AUTOMATIC TAGSと)に従って、Markupタイプの値はコード化されます:
Markup ::= CHOICE {
text SEQUENCE {
prolog UTF8String (SIZE(1..MAX)) OPTIONAL,
prefix NCName OPTIONAL,
attributes UTF8String (SIZE(1..MAX)) OPTIONAL,
content UTF8String (SIZE(1..MAX)) OPTIONAL
}
}
マークアップ:、:= 選択テキストSEQUENCE、プロローグUTF8String(SIZE(1..MAX))OPTIONAL、NCName OPTIONALを前に置いてください、属性UTF8String(SIZE(1..MAX))OPTIONAL、内容UTF8String(SIZE(1..MAX))OPTIONAL
Legg & Prager Experimental [Page 6] RFC 4910 Robust XML Encoding Rules July 2007
強健な[6ページ]RFC4910XML符号化規則2007年7月に実験的なLeggとプラーガー
The text alternative of the Markup CHOICE type provides for the [prefix], [attributes], [namespace attributes], and [children] of an element item to be represented as serialized XML using the UTF-8 character encoding [UTF-8].
Markup CHOICEタイプのテキスト代替手段は、連載されたXMLとしてUTF-8文字符号化[UTF-8]を使用することで表されるために要素の品目の[接頭語]、[属性]、[名前空間属性]、および[子供]に備えます。
Aside: The CHOICE allows for one or more alternative compact
representations of the content and attributes of an element to be
supported in a future specification.
傍らに: CHOICEは、1つ以上の選択肢のために内容のコンパクトな表現と要素の属性が将来の仕様でサポートされるのを許容します。
With respect to some element item whose content and attributes are represented by a value of the text alternative of the Markup type:
内容と属性が表される何らかの要素の品目に関して、Markupのテキスト代替手段の値で、タイプしてください:
(1) the prolog component of the value contains text that, after line
break normalization, conforms to the XML prolog production
[XML10][XML11],
(1) 価値のプロローグコンポーネントはラインブレイク正常化の後にXMLプロローグ生産[XML10][XML11]に従うテキストを含んでいます。
(2) the prefix component is absent if the [prefix] of the element
item has no value; otherwise, the prefix component contains the
[prefix] of the element item,
(2) 要素の品目の[接頭語]に値が全くないなら、接頭語コンポーネントは欠けています。 さもなければ、接頭語コンポーネントは要素の品目の[接頭語]を含んでいます。
(3) the attributes component of the value contains an XML
serialization of the [attributes] and [namespace attributes] of
the element item, if any, with each attribute separated from the
next by serialized white space, and
そして(3) 価値の属性コンポーネントは[属性]のXML連載と要素の品目の[名前空間属性]を含んでいます、もしあれば、各属性が連載された余白によって次と切り離されている状態で。
(4) the content component is absent if the [children] property of the
element item is empty; otherwise, the content component of the
value contains an XML serialization of the [children] of the
element item.
(4) 要素の品目の[子供]の特性が空であるなら、満足しているコンポーネントは欠けています。 さもなければ、価値の満足しているコンポーネントは要素の品目の[子供]のXML連載を含んでいます。
All the components of a value of the Markup type MUST use the same version of XML, either version 1.0 [XML10] or version 1.1 [XML11]. If XML version 1.1 is used, then the prolog component MUST be present and MUST have an XMLDecl for version 1.1. If the prolog component is absent, then XML version 1.0 is assumed.
Markupタイプの価値のすべてのコンポーネントがXMLバージョン1.0[XML10]かバージョン1.1[XML11]のどちらかの同じバージョンを使用しなければなりません。 XMLバージョン1.1が使用されているなら、プロローグコンポーネントは、存在していなければならなくて、バージョン1.1のためのXMLDeclを持たなければなりません。 プロローグコンポーネントが欠けるなら、XMLバージョン1.0は想定されます。
If the prefix component is present, then there MUST be a namespace declaration attribute in the attributes component that defines that namespace prefix (since an element whose content and attributes are described by a value of Markup is required to be self-contained; see Section 4.1.1).
接頭語コンポーネントが存在しているなら、その名前空間接頭語を定義する属性コンポーネントには名前空間宣言属性があるに違いありません(要素以来、だれの内容と属性がMarkupの値で説明されるかが自己充足的になるのに必要です; セクション4.1.1を見てください)。
Note that the prefix component is critically related to the NamedType that has Markup as its type. If a Markup value is extracted from one enclosing abstract value and embedded in another enclosing abstract value (i.e., becomes associated with a different NamedType), then the prefix may no longer be appropriate, in which case it will need to be revised. It may also be necessary to add another namespace
接頭語コンポーネントが批判的にタイプとしてMarkupを持っているNamedTypeに関連することに注意してください。 Markup値が抽象的な値(すなわち、異なったNamedTypeに関連するようになる)を同封しながら抽象的な値を同封しながら1から抽出されて、別のものに埋め込まれるなら、接頭語はもう適切でないかもしれません、それが改訂されるために必要とするどの場合に。 また、別の名前空間を加えるのも必要であるかもしれません。
Legg & Prager Experimental [Page 7] RFC 4910 Robust XML Encoding Rules July 2007
強健な[7ページ]RFC4910XML符号化規則2007年7月に実験的なLeggとプラーガー
declaration attribute to the attributes component so as to declare a new namespace prefix.
宣言は、新しい名前空間接頭語を宣言するためにコンポーネントを属性の結果と考えます。
Leading and/or trailing serialized white space is permitted in the attributes component. A value of the attributes component consisting only of serialized white space (i.e., no actual attributes) is permitted.
主な、そして/または、引きずっている連載された余白は属性コンポーネントで受入れられます。 連載された余白(すなわち、実際の属性がない)だけから成る属性コンポーネントの値は受入れられます。
The attributes and content components MAY contain entity references [XML10][XML11]. If any entity references are used (other than references to the predefined entities), then the prolog component MUST be present and MUST contain entity declarations for those entities in the internal or external subset of the document type definition.
属性と満足しているコンポーネントは実体参照[XML10][XML11]を含むかもしれません。 何か実体参照が使用されているなら(定義済み実体の参照を除いた)、プロローグコンポーネントは、存在していなければならなくて、ドキュメント型定義の内部の、または、外部の部分集合のそれらの実体のための実体宣言を含まなければなりません。
Example
例
Given the following ASN.1 module:
以下のASN.1モジュールを与えます:
MyModule DEFINITIONS
AUTOMATIC TAGS ::= BEGIN
MyModule定義オートマチックは以下にタグ付けをします:= 始まってください。
Message ::= SEQUENCE {
messageType INTEGER,
messageValue Markup
}
以下を通信させてください:= 系列messageType整数、messageValueマーク付け
ENCODING-CONTROL RXER
コード化しているコントロールRXER
TARGET-NAMESPACE "http://example.com/ns/MyModule"
目標名前空間" http://example.com/ns/MyModule "
COMPONENT message Message
-- a top-level NamedType
COMPONENTメッセージMessage--トップレベルNamedType
END
終わり
consider the following XML document:
以下のXMLドキュメントを考えてください:
<?xml version='1.0'?>
<!DOCTYPE message [
<!ENTITY TRUE 'true'>
]>
<message>
<messageType>1</messageType>
<messageValue xmlns:ns="http://www.example.com/ABD"
ns:foo="1" bar="0">
<this>&TRUE;</this>
<that/>
<?xmlバージョン= '1.0'?1</messageTypeの><!DOCTYPEメッセージ[<!のENTITY TRUEの'本当'の>]><メッセージ><messageType>><messageValue xmlns: ナノ秒=" http://www.example.com/ABD "ナノ秒: fooが0インチの「1インチのバー=」><と等しい、この>とTRUE;、</、この><、その/>、'
Legg & Prager Experimental [Page 8] RFC 4910 Robust XML Encoding Rules July 2007
強健な[8ページ]RFC4910XML符号化規則2007年7月に実験的なLeggとプラーガー
</messageValue>
</message>
</messageValue></メッセージ>。
A Markup value corresponding to the content and attributes of the
<messageValue> element is, in ASN.1 value notation [X.680] (where
"lf" represents the line feed character):
<messageValue>要素の内容と属性に対応するMarkup値はそうです、ASN.1値の記法[X.680]("lf"が改行文字を表すところ)で:
text:{
prolog { "<?xml version='1.0'?>", lf,
"<!DOCTYPE message [", lf,
" <!ENTITY TRUE 'true'>", lf,
"]>", lf },
attributes { " xmlns:ns=""http://www.example.com/ABD""",
lf,
" ns:foo=""1"" bar=""0""" },
content { lf,
" <this>&TRUE;</this>", lf,
" <that/>", lf, " " }
}
テキスト:{ prolog { "<?xml version='1.0'?>", lf, "<!DOCTYPE message [", lf, " <!ENTITY TRUE 'true'>", lf, "]>", lf }, attributes { " xmlns:ns=""http://www.example.com/ABD""", lf, " ns:foo=""1"" bar=""0""" }, content { lf, " <this>&TRUE;</this>", lf, " <that/>", lf, " " } }
The following Markup value is an equivalent representation of the
content and attributes of the <messageValue> element:
以下のMarkup値は、内容の同等な表現と<messageValue>要素の属性です:
text:{
attributes {
"bar=""0"" ns:foo=""1"" ",
"xmlns:ns=""http://www.example.com/ABD""" },
content { lf,
" <this>true</this>", lf,
" <that/>", lf, " " }
}
テキスト:「「」 バー=「0インチに、」 ナノ秒: fooは」 「1インチ」等しい」「」 xmlns: ナノ秒=" http://www.example.com/ABD "」」が満足させる属性、lf、「<、この>の本当の</、この>、」 lfである、「<、その/>、」 lfである、「「」
By itself, the Markup ASN.1 type imposes no data type restriction on the markup contained by its values and is therefore analogous to the XML Schema anyType [XSD1].
それ自体で、Markup ASN.1タイプは、値によって含まれたマークアップにデータ型制限を全く課さないで、したがって、XML Schema anyType[XSD1]に類似しています。
There is no ASN.1 basic notation that can directly impose the constraint that the markup represented by a value of the Markup type must conform to the markup allowed by a specific type definition. However, certain encoding instructions (i.e., the reference encoding instructions [RXEREI]) have been defined to have this effect.
直接、Markupタイプの値によって表されたマークアップが特定のタイプ定義で許容されたマークアップに従わなければならないという規制を課すことができるどんなASN.1の基本的な記法もありません。 しかしながら、あるコード化指示(すなわち、指示[RXEREI]をコード化する参照)は、この効果を持つために定義されました。
4.1.1. Self-Containment
4.1.1. 自己封じ込め
An element, its attributes and its content, including descendent elements, may contain qualified names [XMLNS10][XMLNS11] as the names of elements and attributes, in the values of attributes, and as character data content of elements. The binding between namespace
下降の要素を含む要素、属性、およびその内容は要素の名前と属性の値における属性として要素のキャラクタデータ内容として適切な名前[XMLNS10][XMLNS11]を含むかもしれません。 名前空間の間の結合
Legg & Prager Experimental [Page 9] RFC 4910 Robust XML Encoding Rules July 2007
強健な[9ページ]RFC4910XML符号化規則2007年7月に実験的なLeggとプラーガー
prefix and namespace name for these qualified names is potentially determined by the namespace declaration attributes of ancestor elements (which in the Infoset representation are inherited as namespace items in the [in-scope namespaces]).
これらの適切な名前における、名義の接頭語と名前空間が先祖要素の名前空間宣言属性で潜在的に決定する、(名前空間項目として中でInfoset表現で引き継がれる、[範囲の名前空間。)
In the absence of complete knowledge of the data type of an element item whose content and attributes are described by a value of the Markup type, it is not possible to determine with absolute certainty which of the namespace items inherited from the [in-scope namespaces] of the [parent] element item are significant in interpreting the Markup value. The safe and easy option would be to assume that all the namespace items from the [in-scope namespaces] of the [parent] element item are significant and need to be retained within the Markup value. When the Markup value is re-encoded, any of the retained namespace items that do not appear in the [in-scope namespaces] of the enclosing element item in the new encoding could be made to appear by outputting corresponding namespace declaration attribute items in the [namespace attributes] of the enclosing element item.
内容と属性がMarkupタイプの値によって説明される要素の品目のデータ型に関する完全な知識がないとき絶対確実性で項目が名前空間のどれから世襲されたかを決定するのが可能でない、[親]要素の品目の[範囲の名前空間]はMarkup値を解釈するのにおいて重要です。 安全で簡単なオプションがそれがすべて、名前空間項目であると仮定するだろうことである、[親]要素の品目の[範囲の名前空間]は、重要であり、Markup値の中で保有される必要があります。 いつMarkup値が再コード化されて、保有された名前空間のどれかが現れない商品であるか、新しいコード化における同封の要素の品目の[範囲の名前空間]は中で対応する名前空間宣言属性項目を出力することによって現れさせられることができた、同封の要素の品目の[名前空間属性。]
From the perspective of the receiver of the new encoding, this enlarges the set of attribute items in the [namespace attributes] represented by the Markup value.
新しいコード化の受信機の見解から、これが中で属性項目のセットを拡大する、Markup値によって表された[名前空間属性。]
In addition, there is no guarantee that the sender of the new encoding has recreated the original namespace declaration attributes on the ancestor elements, so the [in-scope namespaces] of the enclosing element item is likely to have new namespace declarations that the receiver will retain and pass on in the [namespace attributes] when it in turn re-encodes the Markup value.
したがって、先祖要素の上にさらに、新しいコード化の送付者が元の名前空間宣言属性を休養させたという保証が全くない、同封の要素の品目の[範囲の名前空間]が受信機がコネを保有して、通過するという新しい名前空間宣言を持っていそうである、[名前空間属性] 順番にMarkup値を再コード化するとき。
This unbounded growth in the set of attribute items in the [namespace attributes] defeats any attempt to produce a canonical encoding.
いずれも試みる[名前空間属性]敗北における属性項目のセットでのこの限りない成長は正準なコード化を生産します。
The principle of self-containment is introduced to avoid this problem. An element item (the subject element item) is self-contained if the constraints of Namespaces in XML 1.0 [XMLNS10] are satisfied (i.e., that prefixes are properly declared) and none of the following bindings are determined by a namespace declaration attribute item in the [namespace attributes] of an ancestor element item of the subject element item:
自己封じ込めの本質は、この問題を避けるために紹介されます。 XML1.0[XMLNS10]でのNamespacesの規制が満たされていて(すなわち、その接頭語は適切に宣言されます)、以下の結合のいずれも中で名前空間宣言属性項目で決定しないなら要素の品目(対象の要素の品目)が自己充足的である、対象の要素の品目の先祖要素の品目の[名前空間属性]:
(1) the binding between the [prefix] and [namespace name] of the
subject element item,
(1) 対象の要素の品目の[接頭語]と[名前空間名]の間の結合
(2) the binding between the [prefix] and [namespace name] of any
descendant element item of the subject element item,
(2) 対象の要素の品目のどんな下降の要素の品目の[接頭語]と[名前空間名]の間の結合
Legg & Prager Experimental [Page 10] RFC 4910 Robust XML Encoding Rules July 2007
強健な[10ページ]RFC4910XML符号化規則2007年7月に実験的なLeggとプラーガー
(3) the binding between the [prefix] and [namespace name] of any
attribute item in the [attributes] of the subject element item or
the [attributes] of any descendant element item of the subject
element item,
(3) 対象の要素の品目の[属性]か対象の要素の品目のどんな下降の要素の品目の[属性]におけるどんな属性項目の[接頭語]と[名前空間名]の間の結合
(4) the binding between the namespace prefix and namespace name of
any qualified name in the [normalized value] of any attribute
item in the [attributes] of the subject element item or the
[attributes] of any descendant element item of the subject
element item, or
または(4) 中のどんな適切な名前の名前空間接頭語と名前空間名の間の結合、[値を正常にします] 対象の要素の品目の[属性]か対象の要素の品目のどんな下降の要素の品目の[属性]におけるどんな属性項目についても。
(5) the binding between the namespace prefix and namespace name of
any qualified name represented by a series of character items
(ignoring processing instruction and comment items) in the
[children] of the subject element item or the [children] of any
descendant element item of the subject element item.
(5) 対象の要素の品目の[子供]か対象の要素の品目のどんな下降の要素の品目の[子供]にも一連のキャラクタ項目によって表された(処理命令とコメント項目を無視します)どんな適切な名前の名前空間接頭語と名前空間名の間の結合。
Aside: If an element is self-contained, then separating the
element from its parent does not change the semantic
interpretation of its name and any names in its content and
attributes.
傍らに: 要素が自己充足的であるなら、親と要素を切り離す場合、その内容と属性における名前とどんな名前の意味解釈も変化しません。
A supposedly self-contained element in a received RXER encoding that is in fact not self-contained SHALL be treated as an ASN.1 constraint violation.
容認されたRXERの事実上自己充足的なSHALLでない推定上自己充足的な要素がコード化されて、ASN.1規制違反として扱われてください。
Aside: ASN.1 does not require an encoding with a constraint
violation to be immediately rejected; however, the constraint
violation must be reported at some point, possibly in a separate
validation step.
傍らに: ASN.1は、規制違反によるコード化がすぐに拒絶されるのを必要としません。 しかしながら、何らかのポイントにおいてことによると別々の合法化ステップで規制違反を報告しなければなりません。
Implementors should note that an RXER decoder will be able to detect some, but not all, violations of self-containment. For example, it can detect element and attribute names that depend on namespace declarations appearing in the ancestors of a supposedly self-contained element. Similarly, where type information is available, it can detect qualified names in character data that depend on the namespace declarations of ancestor elements. However, type information is not always available, so some qualified names will escape constraint checking. Thus, the onus is on the creator of the original encoding to ensure that element items required to be self-contained really are completely self-contained.
作成者は、RXERデコーダが自己封じ込めの違反ではなく、いくつかを検出できることに注意するべきです。 例えば、それは、名前空間宣言に依存する要素と属性名が推定上自己充足的な要素の先祖に現れるのを検出できます。 同様に、タイプ情報が利用可能であるところでは、それは先祖要素の名前空間宣言によるキャラクタデータの適切な名前を検出できます。 しかしながら、タイプ情報がいつも利用可能であるというわけではないので、いくつかの適切な名前が規制の照合から逃げるでしょう。 したがって、自己充足的になるのに必要である要素の品目が確実に本当に完全に独立になるようにするために、オリジナルのコード化のクリエイターの上に重荷はあります。
An element item whose content and attributes are described by a value of the Markup type MUST be self-contained.
内容と属性がMarkupタイプの値によって説明される要素の品目は独立であるに違いありません。
Legg & Prager Experimental [Page 11] RFC 4910 Robust XML Encoding Rules July 2007
強健な[11ページ]RFC4910XML符号化規則2007年7月に実験的なLeggとプラーガー
Aside: The procedures in Section 6 take account of the
requirements for self-containment so that an RXER encoder
following these procedures will not create violations of
self-containment.
傍らに: セクション6の手順は、これらの手順に従うRXERエンコーダが自己封じ込めの違反を作成しないように、自己封じ込めのための要件を考慮に入れます。
4.1.2. Normalization for Canonical Encoding Rules
4.1.2. 正準な符号化規則のための正常化
Implementations are given some latitude in how the content and attributes of an element are represented as an abstract value of the Markup type, in part because an Infoset can have different equivalent serializations. For example, the order of attributes and the amount and kind of white space characters between attributes are irrelevant to the Infoset representation. The content can also include one or more elements corresponding to an ASN.1 top-level NamedType or having a data type that is an ASN.1 type. It is only necessary to preserve the abstract value for such elements, and a particular abstract value can have different Infoset representations.
要素の内容と属性がMarkupタイプの抽象的な値としてどう表されるかで何らかの緯度を実装に与えます、Infosetが一部異なった同等な連載を持つことができるので。 例えば、属性の注文と量とちょっと属性の間の余白性格はInfoset表現と無関係です。 また、内容はASN.1トップレベルNamedTypeかASN.1タイプであるデータ型を持っていると対応する1つ以上の要素を含むことができます。 そのような要素のために単に抽象的な価値を守るのが必要であり、特定の抽象的な値は異なったInfoset表現を持つことができます。
These two characteristics mean that when an RXER encoded value of the Markup type is decoded, the components of the recovered Markup value may not be exactly the same, character for character, as the original value that was encoded, though the recovered value will be semantically equivalent.
これらの2つの特性が、RXERがMarkupタイプの値をコード化したとき、それが解読されることを意味して、回復しているMarkup価値のコンポーネントはまさに同じでないかもしれません、キャラクタのためのキャラクタ、コード化された元の値として、回復している値が意味的に同等になるでしょうが。
However, canonical ASN.1 encoding rules such as the Distinguished Encoding Rules (DER) and the Canonical Encoding Rules (CER) [X.690], which encode Markup values according to the ASN.1 definition of the Markup type, depend on character-for-character preservation of string values. This requirement can be accommodated if values of the Markup type are normalized when they are encoded according to a set of canonical encoding rules.
しかしながら、Distinguished Encoding Rules(DER)やCanonical Encoding Rules(CER)[X.690]などの正準なASN.1符号化規則はストリング値のキャラクタのためのキャラクタ保存によります。(MarkupのASN.1定義に従ったエンコードMarkup値はCanonical Encoding Rulesをタイプします)。 1セットの正準な符号化規則によると、それらがコード化されるとき、Markupタイプの値が正常にされるなら、この要件を設備することができます。
Aside: The RXER encoding and decoding of a Markup value might
change the character string components of the value from the
perspective of BER, but there will be a single, repeatable
encoding for DER.
傍らに: Markup価値をコード化して、解読するRXERはBERの見解から価値の文字列コンポーネントを変えるかもしれませんが、シングル、DERのための反復可能コード化があるでしょう。
A value of the Markup type will appear as the content and attributes of an element in an RXER encoding. When the value is encoded using a set of ASN.1 canonical encoding rules other than CRXER, the components of the text alternative of the value MUST be normalized as follows, by reference to the element as it would appear in a CRXER encoding:
Markupタイプの値はRXERコード化における、要素の内容と属性として現れるでしょう。 値がCRXER以外の1セットのASN.1の正準な符号化規則を使用することでコード化されるとき、以下をコード化するCRXERで要素の参照で以下の通りに見えるでしょうが、価値のテキスト代替手段の成分を正常にしなければなりません。
(1) The value of the prolog component SHALL be the XMLDecl
<?xml version="1.1"?> with no other leading or trailing
characters.
(1) 値、プロローグコンポーネントのSHALLでは、XMLDecl<になってください--xmlバージョンは「1.1インチ?他の主であるか引きずっているキャラクタのない>」と等しいです。
Legg & Prager Experimental [Page 12] RFC 4910 Robust XML Encoding Rules July 2007
強健な[12ページ]RFC4910XML符号化規則2007年7月に実験的なLeggとプラーガー
(2) If the element's name is unprefixed in the CRXER encoding, then
the prefix component SHALL be absent; otherwise, the value of the
prefix component SHALL be the prefix of the element's name in the
CRXER encoding.
名前は(2) 要素のものであるならCRXERコード化、次に、接頭語コンポーネントSHALLに「非-前に置」かれます。休んでください。 そうでなければ、値、接頭語コンポーネントSHALLにおいて、CRXERコード化における要素の名前の接頭語はそうです。
(3) Take the character string representing the element's attributes,
including namespace declarations, in the CRXER encoding. If the
first attribute is a namespace declaration that undeclares the
default namespace (i.e., xmlns=""), then remove it. Remove any
leading space characters. If the resulting character string is
empty, then the attributes component SHALL be absent; otherwise,
the value of the attributes component SHALL be the resulting
character string.
(3) CRXERコード化における名前空間宣言を含む要素の属性を表す文字列を取ってください。 「最初の属性がデフォルト名前空間を非宣言する名前空間宣言である、(すなわち、xmlns=、」、」、)、そして、それを取り除いてください。 あらゆる主な間隔文字を取り除いてください。 結果として起こる文字列は空であり、次に、属性コンポーネントはSHALLです。休んでください。 そうでなければ、値、属性コンポーネントSHALLにおいて、結果として起こる文字列はそうです。
Aside: Note that the attributes of an element can change if an
RXER encoding is re-encoded in CRXER.
傍らに: 要素の属性が、RXERコード化がCRXERで再コード化されるかどうかを変えることができることに注意してください。
(4) If the element has no characters between the start-tag and
end-tag [XML11] in the CRXER encoding, then the content component
SHALL be absent; otherwise, the value of the content component
SHALL be identical to the character string in the CRXER encoding
bounded by the element's start-tag and end-tag.
(4)は要素であるならCRXERコード化における開始タグと終了タグ[XML11]の間で品性がなくて、次に、満足しているコンポーネントはSHALLです。休んでください。 そうでなければ、値、満足しているコンポーネントのSHALLでは、要素の開始タグと終了タグで境界があるCRXERコード化における文字列と同じにしてください。
Aside: A consequence of invoking the CRXER encoding is that any
nested element corresponding to an ASN.1 top-level NamedType, or
indeed the element itself, will be normalized according to its
ASN.1 value rather than its Infoset representation. Likewise for
an element whose data type is an ASN.1 type. Section 6.4
describes how these situations can arise.
傍らに: CRXERコード化を呼び出す結果はInfoset表現よりむしろASN.1値に従ってASN.1トップレベルNamedTypeに対応するどんな入れ子にされた要素、または本当に要素自体も正常にされるということです。 同様にデータ型がASN.1である要素には、タイプしてください。 セクション6.4は、これらの状況がどうしたら起こることができるかを説明します。
Aside: It is only through values of the Markup type that
processing instructions and comments can appear in CRXER
encodings.
傍らに: 処理命令とコメントはCRXER encodingsにMarkupタイプの値だけを通して、現れることができます。
If an application uses DER, but has no knowledge of RXER, then it will not know to normalize values of the Markup type. If RXER is deployed into an environment containing such applications, then Markup values SHOULD be normalized, even when encoding using non-canonical encoding rules.
アプリケーションでは、DERを使用しますが、RXERに関する知識が全くないと、それはMarkupタイプの値を正常にするのを知らないでしょう。 使用をコード化さえするとき、RXERがそのようなアプリケーションを含む環境に配布されるなら、Markup値のSHOULDが正常にされて、正典外のコード化は統治されます。
4.2. The AnyURI Type
4.2. AnyURIはタイプします。
A value of the AnyURI ASN.1 type is a character string conforming to the format of a Uniform Resource Identifier (URI) [URI].
AnyURI ASN.1タイプの値はUniform Resource Identifier(URI)[URI]の形式に従う文字列です。
AnyURI ::= UTF8String (CONSTRAINED BY
{ -- conforms to the format of a URI -- })
AnyURI:、:= UTF8String(CONSTRAINED BY、--URIの形式に従います--、)
Legg & Prager Experimental [Page 13] RFC 4910 Robust XML Encoding Rules July 2007
強健な[13ページ]RFC4910XML符号化規則2007年7月に実験的なLeggとプラーガー
4.3. The NCName Type
4.3. NCNameはタイプします。
A value of the NCName ASN.1 type is a character string conforming to the NCName production of Namespaces in XML 1.0 [XMLNS10].
NCName ASN.1タイプの値はXML1.0[XMLNS10]でのNamespacesのNCName生産に従う文字列です。
NCName ::= UTF8String (CONSTRAINED BY
{ -- conforms to the NCName production of
-- Namespaces in XML 1.0 -- })
NCName:、:= UTF8String(CONSTRAINED BY、--、NCName生産に従う、--XML1.0の名前空間--、)
Aside: The NCName production for Namespaces in XML 1.1 [XMLNS11]
allows a wider range of characters than the NCName production for
Namespaces in XML 1.0. The NCName type for ASN.1 is currently
restricted to the characters allowed by Namespaces in XML 1.0,
though this may change in a future specification of RXER.
傍らに: XML1.1[XMLNS11]のNamespacesのためのNCName生産はXML1.0における、NamespacesのためのNCName生産より広い範囲のキャラクタを許容します。 ASN.1のためのNCNameタイプは現在XML1.0にNamespacesによって許容されたキャラクタに制限されます、これがRXERの将来の仕様で変化するかもしれませんが。
4.4. The Name Type
4.4. タイプという名前
A value of the Name ASN.1 type is a character string conforming to the Name production of XML version 1.0 [XML10].
Name ASN.1タイプの値はXMLバージョン1.0[XML10]のName生産に従う文字列です。
Name ::= UTF8String (CONSTRAINED BY
{ -- conforms to the Name production of XML -- })
以下を命名してください:= UTF8String(CONSTRAINED BY、--XMLのName生産に従います--、)
4.5. The QName Type
4.5. QNameはタイプします。
A value of the QName ASN.1 type describes an expanded name [XMLNS10], which appears as a qualified name [XMLNS10] in an RXER encoding.
QName ASN.1タイプの値は拡張名前[XMLNS10]について説明します。(それは、適切な名前[XMLNS10]としてRXERコード化に現れます)。
RXER has special provisions for encoding values of the QName type (see Section 6.7.11). For other encoding rules, a value of the Qname type is encoded according to the following ASN.1 type definition (with AUTOMATIC TAGS):
RXERには、QNameタイプの値をコード化するための特別条項があります(セクション6.7.11を見てください)。 他の符号化規則において、以下のASN.1型定義(AUTOMATIC TAGSと)に従って、Qnameタイプの値はコード化されます:
QName ::= SEQUENCE {
namespace-name AnyURI OPTIONAL,
local-name NCName
}
QName:、:= 系列名前空間名のAnyURI OPTIONAL、地方名NCName
The namespace-name component holds the namespace name of the expanded name. If the namespace name of the expanded name has no value, then the namespace-name component is absent.
名前空間名のコンポーネントは拡張名前の名前空間名を保持します。 拡張名前の名前空間名に値が全くないなら、名前空間名のコンポーネントは欠けています。
Aside: A namespace name can be associated with ASN.1 types and
top-level NamedType instances by using the TARGET-NAMESPACE
encoding instruction.
傍らに: 指示をコード化するTARGET-NAMESPACEを使用するのによるASN.1タイプとトップレベルNamedTypeインスタンスに名前空間名を関連づけることができます。
The local-name component holds the local name of the expanded name.
地方名コンポーネントは拡張名前の地方名を保持します。
Legg & Prager Experimental [Page 14] RFC 4910 Robust XML Encoding Rules July 2007
強健な[14ページ]RFC4910XML符号化規則2007年7月に実験的なLeggとプラーガー
5. Expanded Names for ASN.1 Types
5. ASN.1タイプのための拡張名前
A TypeAssignment in ASN.1 associates a typereference with a Type. For RXER and Abstract Syntax Notation X (ASN.X) [ASN.X], a TypeAssignment is also regarded as associating an expanded name [XMLNS10] with the Type. The local name of the expanded name is the typereference on the left-hand side of the TypeAssignment. If the target namespace [RXEREI] of the ASN.1 module in which the TypeAssignment is defined is not absent, then the namespace name of the expanded name is that target namespace; otherwise, the namespace name of the expanded name has no value.
ASN.1のTypeAssignmentはtypereferenceをTypeに関連づけます。 また、RXERと抽象的なSyntax Notation X(ASN.X)[ASN.X]に関しては、TypeAssignmentは拡張名前[XMLNS10]をTypeに関連づけると見なされます。 拡張名前の地方名はTypeAssignmentの左側の上のtypereferenceです。 TypeAssignmentが定義されるASN.1モジュールの目標名前空間[RXEREI]が欠けないなら、拡張名前の名前空間名はその目標名前空間です。 さもなければ、拡張名前の名前空間名には、値が全くありません。
A Type that is a BuiltinType or ReferencedType that is one of the productions in Table 1 is regarded as a reference to a built-in ASN.1 type. These built-in types also have expanded names. In each case, the local name of the expanded name is as indicated in Table 1, and the namespace name of the expanded name is "urn:ietf:params:xml:ns:asnx".
BuiltinTypeであるTypeかTable1の創作の1つであるReferencedTypeが内蔵のASN.1タイプについての言及と見なされます。 これらの内蔵型も名前を広くしました。 その都度、拡張名前の地方名がTable1、および存在という拡張名前「つぼ:ietf:params:xml:ナノ秒: asnx」の名前空間名にみられるようにあります。
Legg & Prager Experimental [Page 15] RFC 4910 Robust XML Encoding Rules July 2007
強健な[15ページ]RFC4910XML符号化規則2007年7月に実験的なLeggとプラーガー
Table 1: Local Names for Built-in Types
テーブル1: 内蔵型のための地方名
+------------------------------------+-------------------+
| ASN.1 Production | Local Name |
+====================================+===================+
| BitStringType | |
| without a NamedBitList | BIT-STRING |
+------------------------------------+-------------------+
| BooleanType | BOOLEAN |
+------------------------------------+-------------------+
| CharacterStringType | |
| RestrictedCharacterStringType | |
| BMPString | BMPString |
| GeneralString | GeneralString |
| GraphicString | GraphicString |
| IA5String | IA5String |
| ISO646String | ISO646String |
| NumericString | NumericString |
| PrintableString | PrintableString |
| TeletexString | TeletexString |
| T61String | T61String |
| UniversalString | UniversalString |
| UTF8String | UTF8String |
| VideotexString | VideotexString |
| VisibleString | VisibleString |
| UnrestrictedCharacterStringType | CHARACTER-STRING |
+------------------------------------+-------------------+
| EmbeddedPDVType | EMBEDDED-PDV |
| ExternalType | EXTERNAL |
+------------------------------------+-------------------+
| IntegerType | |
| without a NamedNumberList | INTEGER |
+------------------------------------+-------------------+
| NullType | NULL |
| ObjectIdentifierType | OBJECT-IDENTIFIER |
| OctetStringType | OCTET-STRING |
| RealType | REAL |
| RelativeOIDType | RELATIVE-OID |
+------------------------------------+-------------------+
| UsefulType | |
| GeneralizedTime | GeneralizedTime |
| UTCTime | UTCTime |
| ObjectDescriptor | ObjectDescriptor |
+------------------------------------+-------------------+
+------------------------------------+-------------------+ | ASN.1生産| 地方名| +====================================+===================+ | BitStringType| | | NamedBitListなしで| ビット列| +------------------------------------+-------------------+ | BooleanType| 論理演算子| +------------------------------------+-------------------+ | CharacterStringType| | | RestrictedCharacterStringType| | | BMPString| BMPString| | GeneralString| GeneralString| | GraphicString| GraphicString| | IA5String| IA5String| | ISO646String| ISO646String| | NumericString| NumericString| | PrintableString| PrintableString| | TeletexString| TeletexString| | T61String| T61String| | UniversalString| UniversalString| | UTF8String| UTF8String| | VideotexString| VideotexString| | VisibleString| VisibleString| | UnrestrictedCharacterStringType| 文字列| +------------------------------------+-------------------+ | EmbeddedPDVType| 埋め込まれたPDV| | ExternalType| 外部| +------------------------------------+-------------------+ | IntegerType| | | NamedNumberListなしで| 整数| +------------------------------------+-------------------+ | NullType| ヌル| | ObjectIdentifierType| オブジェクト識別子| | OctetStringType| 八重奏ストリング| | RealType| 本当| | RelativeOIDType| 親類-OID| +------------------------------------+-------------------+ | UsefulType| | | GeneralizedTime| GeneralizedTime| | UTCTime| UTCTime| | ObjectDescriptor| ObjectDescriptor| +------------------------------------+-------------------+
Legg & Prager Experimental [Page 16] RFC 4910 Robust XML Encoding Rules July 2007
強健な[16ページ]RFC4910XML符号化規則2007年7月に実験的なLeggとプラーガー
When the expanded name for an ASN.1 type is used in an RXER encoding, it appears as a qualified name [XMLNS10][XMLNS11]. The namespace prefix for the qualified name is determined according to Section 6.7.11.1.
ASN.1タイプのための拡張名前がRXERコード化に使用されるとき、それは適切な名前[XMLNS10][XMLNS11]として現れます。 セクション6.7.11に従って、適切な名前のための名前空間接頭語は.1に決定しています。
If a compatible XML Schema translation of an ASN.1 specification is provided (see Section 6.4), then that schema SHOULD associate the same expanded name with the XML Schema translation of an ASN.1 type.
ASN.1仕様のコンパチブルXML Schema翻訳を提供するなら(セクション6.4を見てください)、その図式SHOULDはASN.1タイプに関するXML Schema翻訳の同じ拡張名前を関連づけます。
Definition (namespace-qualified reference): An ASN.1 Type is a namespace-qualified reference if one of the following applies:
定義(名前空間で適切な参照): 以下の1つが適用されるなら、ASN.1Typeは名前空間で適切な参照です:
(1) the Type is a typereference (not a DummyReference) or an
ExternalTypeReference in a DefinedType in a ReferencedType, the
ASN.1 module in which the referenced type is defined has a
TARGET-NAMESPACE encoding instruction, the referenced type is not
directly or indirectly an open type [X.681], and the referenced
type is not directly or indirectly the Markup type (Section 4.1),
or
または(1) Typeがtypereference(DummyReferenceでない)かReferencedTypeのDefinedTypeのExternalTypeReferenceである、被参照型が直接そうでない間接的に、開放型[X.681]、および被参照型が直接そうでないTARGET-NAMESPACEが被参照型が定義されるASN.1モジュールで指示をコード化するか、または間接的に、Markupが(セクション4.1)をタイプする。
(2) the Type is a BuiltinType or ReferencedType that is one of the
productions in Table 1.
(2) TypeはTable1の創作の1つであるBuiltinTypeかReferencedTypeです。
The type definition referenced by a namespace-qualified reference will have an expanded name with a value for the namespace name.
名前空間で適切な参照で参照をつけられる型定義は名前空間名のための値の拡張名前を持つでしょう。
6. Encoding Rules
6. 符号化規則
With respect to RXER, ASN.1 abstract values are uniformly regarded as analogous to the content and attributes of an element, or just an attribute value, not complete elements or attributes in their own right. Elements and attributes in an RXER encoding are defined by ASN.1 NamedType notation. Since elements are the fundamental discrete structures of an XML document, the notion of a NamedType having a value that can be encoded is useful for descriptive purposes (particularly for describing the RXER encoding of values of the ASN.1 combining types). There is no conceptual basis in X.680 [X.680] for talking about the value of a NamedType, or its encoding, so the terminology is introduced here.
RXERに関して、ASN.1の抽象的な値は一様にそのものとして完全な要素か属性ではなく、要素の内容と属性、またはまさしく属性値への類似と見なされます。 RXERコード化における要素と属性はASN.1NamedType記法で定義されます。 要素がXMLドキュメントの基本的な離散的な構造であるので、NamedTypeにはコード化できる値があるという概念は描写的である目的(特にタイプを結合するASN.1の値のRXERコード化について説明するための)の役に立ちます。 概念的基礎が全くNamedTypeの値に関して話すか、またはそのコード化のためのX.680[X.680]にないので、用語はここで紹介されます。
Definition (value of a NamedType): An abstract value of the Type in a NamedType is also a value of that NamedType. The RXER encoding of the value of a NamedType is the RXER encoding of the abstract value of the Type encapsulated according to the definition of that NamedType.
定義(NamedTypeの値): また、NamedTypeのTypeの抽象的な値はそのNamedTypeの値です。 NamedTypeの価値のRXERコード化はそのNamedTypeの定義に従ってカプセル化されたTypeの抽象的な価値のRXERコード化です。
Legg & Prager Experimental [Page 17] RFC 4910 Robust XML Encoding Rules July 2007
強健な[17ページ]RFC4910XML符号化規則2007年7月に実験的なLeggとプラーガー
This document does not refer to a value of a NamedType as being an abstract value so as to remain consistent with X.680. An abstract value is exclusively a value of an ASN.1 type.
このドキュメントはX.680と一致していたままで残る抽象的な値であるとNamedTypeの値を呼びません。 抽象的な値は排他的にASN.1タイプの値です。
A complete ASN.1 encoding is traditionally the encoding of an abstract value, but it is more natural to think of an XML document as being the RXER encoding of a value of a NamedType (because an XML document has a single root element that contains all the other elements and attributes). The ASN.1 basic notation does not allow a NamedType to appear on its own, outside of an enclosing combining type. That is, the basic notation does not have a concept analogous to a global element or attribute definition. However, an ASN.1 specification may use an RXER encoding control section [RXEREI] to define global elements and attributes using the NamedType notation. A NamedType that is not contained in an ASN.1 type definition is called a top-level NamedType [RXEREI]. Thus, an RXER encoding would typically be described as the encoding of a value of a top-level NamedType.
完全なASN.1コード化は伝統的に抽象的な価値のコード化ですが、NamedTypeの価値のRXERコード化であるとしてXMLドキュメントを考えるのは、より当然です(XMLドキュメントには他のすべての要素と属性を含むただ一つの根の要素があるので)。 ASNの.1の基本的な記法で、タイプが同封の外で結合して、NamedTypeはそれ自身のところに現れることができません。 すなわち、基本的な記法には、グローバルな要素か属性定義への類似の概念がありません。 しかしながら、ASN.1仕様はNamedType記法を使用することでグローバルな要素と属性を定義するために制御セクション[RXEREI]をコード化するRXERを使用するかもしれません。 ASN.1型定義で含まれていないNamedTypeはトップレベルNamedType[RXEREI]と呼ばれます。 したがって、RXERコード化はトップレベルNamedTypeの価値のコード化として通常記述されているでしょう。
Section 6.2 describes how a value of a NamedType is encoded. Section 6.3 defines an alternative method for encoding the document element of an XML document when a top-level NamedType is not specified. Section 6.4 describes how the encodings of ASN.1 values can be embedded in an XML document where the other parts of the document are validated by an XML Schema.
セクション6.2はNamedTypeの値がどうコード化されるかを説明します。 セクション6.3はトップレベルNamedTypeが指定されないときXMLドキュメントのドキュメント要素をコード化するための別法を定義します。 セクション6.4はどうASN.1値のencodingsを埋め込むことができるかをドキュメントの他の部分がXML Schemaによって有効にされるXMLドキュメントに説明します。
The RXER encoding of an abstract value, or the encoding of a value of a NamedType, is described as a translation into a synthetic Infoset, which is then serialized as XML. This separation has been chosen for descriptive convenience and is not intended to impose any particular architecture on RXER implementations. An RXER encoder is free to encode an ASN.1 value directly to XML provided the result is equivalent to following the two stage procedure described in this document.
抽象的な価値のRXERコード化、またはNamedTypeの価値のコード化が合成のInfosetへの翻訳として記述されています。(次に、InfosetはXMLとして連載されます)。 この分離は、描写的である便利に選ばれて、どんな特定のアーキテクチャもRXER実装に課すことを意図しません。 結果が本書では説明された2ステージ手順に従うのに同等であるなら、RXERエンコーダは無料でASN.1値を直接XMLにコード化できます。
The process of translating an abstract value into an Infoset is described as producing either:
抽象的な値をInfosetに翻訳するプロセスは生産するとして記述されています:
(1) a string of characters that either becomes part of the
[normalized value] of an attribute item or becomes character
items among the [children] of an enclosing element item, or
またはまたは、(1) どちらかが部分になる一連のキャラクタ、属性項目の[正常にされた値]、同封の要素の品目の[子供]の中でキャラクタ項目になる。
(2) a collection of zero or more attribute items contributing to the
[attributes] of an enclosing element item, plus a series of zero
or more character, element, processing instruction (PI), or
comment items contributing to the [children] of the enclosing
element item.
(2) ゼロか以上の収集は同封の要素の品目の[子供]に貢献する同封の要素の品目の[属性]に貢献する項目と、一連のゼロか、より多くのキャラクタ、要素、処理命令(PI)、またはコメント項目を結果と考えます。
Legg & Prager Experimental [Page 18] RFC 4910 Robust XML Encoding Rules July 2007
強健な[18ページ]RFC4910XML符号化規則2007年7月に実験的なLeggとプラーガー
NamedType notation in the ASN.1 specification controls whether the translation of an abstract value is encapsulated in an element item or in an attribute item.
ASN.1仕様によるNamedType記法は、抽象的な価値に関する翻訳が要素の品目か属性項目でカプセル化されるかどうかを制御します。
Sections 6.5 to 6.10 describe the translation of abstract values into an Infoset for each of the ASN.1 type notations.
セクション6.5〜6.10はそれぞれのASN.1タイプ記法のために抽象的な値に関する翻訳についてInfosetに説明します。
Section 6.11 describes post-processing of namespace prefixes for CRXER encodings.
セクション6.11はCRXER encodingsのために名前空間接頭語の後工程について説明します。
Section 6.12 specifies how the Infoset translation is serialized as XML.
セクション6.12はInfoset翻訳がXMLとしてどう連載されるかを指定します。
This specification assumes that the COMPONENTS OF transformation specified in X.680, Clause 24.4 [X.680] has already been applied to all relevant types.
この仕様は、COMPONENTS OF変換がX.680で指定したと仮定して、Clause24.4[X.680]は既にすべての関連タイプに当てはまられました。
Examples of RXER encodings in the following sections use a <value> start-tag and </value> end-tag to hold attributes and delimit the content. These start-tags and end-tags are for illustration only and are not part of the encoding of an abstract value. In normal use, the name of the enclosing element is provided by the context of the type of the abstract value, e.g., a NamedType in an enclosing SEQUENCE type.
以下のセクションのRXER encodingsに関する例は、属性を保持して、内容を区切るのに<値の>開始タグと</値の>終了タグを使用します。 これらの開始タグと終了タグは、イラストだけのためにあって、抽象的な価値のコード化の一部ではありません。 通常の使用で、抽象的な価値(例えば、SEQUENCEがタイプする同封におけるNamedType)のタイプの文脈は同封要素の名前を提供します。
An RXER decoder is a conforming XML processor [XML10][XML11].
RXERデコーダは従うXMLプロセッサ[XML10][XML11]です。
6.1. Identifiers
6.1. 識別子
An identifier, as defined in ASN.1 notation (Clause 11.3 of X.680 [X.680]), is a character string that begins with a Latin lowercase letter (U+0061-U+007A) and is followed by zero, one or more Latin letters (U+0041-U+005A, U+0061-U+007A), decimal digits (U+0030- U+0039), and hyphens (U+002D). A hyphen is not permitted to be the last character, and a hyphen is not permitted to be followed by another hyphen. The case of letters in an identifier is always significant.
ASN.1記法(X.680[X.680]の第11.3節)で定義される識別子は、ラテン語の小文字(U+0061U+007A)で始まって、ゼロがあとに続く文字列と、1個以上のラテン語の手紙(U+0041U+005A、U+0061U+007A)と、10進数字(U+0030U+0039)と、ハイフン(U+002D)です。 ハイフンは最後のキャラクタであることが許可されていません、そして、ハイフンは別のハイフンがあとに続くことが許可されていません。 識別子における、手紙のケースはいつも重要です。
ASN.1 identifiers are used for the [local name] of attribute and element items, and may also appear in the character data content of elements or the values of attributes. RXER encoding instructions can be used to substitute an NCName [XMLNS10] for an identifier.
ASN.1識別子は、属性と要素の品目の[地方名]に使用されて、また、要素のキャラクタデータ内容か属性の値に現れるかもしれません。 NCName[XMLNS10]を識別子の代わりに用いるのに指示をコード化するRXERは使用できます。
Legg & Prager Experimental [Page 19] RFC 4910 Robust XML Encoding Rules July 2007
強健な[19ページ]RFC4910XML符号化規則2007年7月に実験的なLeggとプラーガー
6.2. Component Encodings
6.2. コンポーネントEncodings
The translation of the value of a NamedType is the translation of the abstract value of the Type of the NamedType encapsulated according to the definition of that NamedType. This section specifies the form of this encapsulation.
NamedTypeの価値に関する翻訳はそのNamedTypeの定義に従ってカプセル化されたNamedTypeのTypeの抽象的な価値に関する翻訳です。 このセクションはこのカプセル化のフォームを指定します。
6.2.1. Referenced Components
6.2.1. 参照をつけられたコンポーネント
A value of a NamedType that is subject to a COMPONENT-REF encoding instruction is translated as a value of the top-level NamedType referenced by the encoding instruction.
指示をコード化するCOMPONENT-REFを受けることがあるNamedTypeの値はNamedTypeがコード化指示で参照をつけたトップレベルの値として翻訳されます。
6.2.2. Element Components
6.2.2. 要素成分
A value of a NamedType that is not subject to an ATTRIBUTE, ATTRIBUTE-REF, GROUP, or SIMPLE-CONTENT encoding instruction is translated as an element item, either as a child element item added to the [children] of the enclosing element item or as the document element item added to the [children] and [document element] of the document item. If the element item is a child element item, then the [parent] is the enclosing element item; otherwise, the [parent] is the document item.
指示をコード化するATTRIBUTEを受けることがないNamedType、ATTRIBUTE-REF、GROUP、またはSIMPLE-CONTENTの値は要素の品目として翻訳されます、子供要素の品目が同封の要素の品目かドキュメント要素の品目として加えられることの[子供]への[子供]とドキュメントの品目の[ドキュメント要素]に加えたように。 要素の品目が子供要素の品目であるなら、[親]は同封の要素の品目です。 さもなければ、[親]はドキュメントの品目です。
The [local name] of the element item is the local name of the expanded name of the NamedType (see [RXEREI]).
要素の品目の[地方名]はNamedTypeという拡張名前の地方名([RXEREI]を見る)です。
Aside: If there are no NAME, ATTRIBUTE-REF, COMPONENT-REF,
ELEMENT-REF, or REF-AS-ELEMENT encoding instructions, then the
local name of the expanded name of a NamedType is the same as the
identifier of the NamedType.
傍らに: 指示をコード化するどんなNAME、ATTRIBUTE-REF、COMPONENT-REF、ELEMENT-REFも、またはREF-AS-ELEMENTもなければ、NamedTypeという拡張名前の地方名はNamedTypeに関する識別子と同じです。
If the namespace name of the expanded name has no value, then the [namespace name] of the element item has no value (i.e., the element's name is not namespace qualified); otherwise, the [namespace name] is the namespace name of the expanded name.
次に、拡張名前の名前空間名で値が全くない、要素の品目の[名前空間名]には、値が全くありません(すなわち、要素の名前は名前空間適切ではありません)。 そうでなければ、[名前空間名]は拡張名前の名前空間名です。
If the type of the NamedType is directly or indirectly the Markup type, then the [in-scope namespaces] and [namespace attributes] of the element item are constructed as specified in Section 6.10; otherwise, the [in-scope namespaces] and [namespace attributes] of the element item are constructed as specified in Section 6.2.2.1.
MarkupはNamedTypeのタイプが直接か間接的にそうならタイプします、そして要素の品目の[範囲の名前空間]と[名前空間属性]はセクション6.10で指定されるように組み立てられます。 そうでなければ、要素の品目の[範囲の名前空間]と[名前空間属性]はセクション6.2.2で.1に指定されるように組み立てられます。
If the [namespace name] of the element item has no value, then the [prefix] of the element item has no value; else if the type of the NamedType is not directly or indirectly the Markup type, then the
要素の品目の[名前空間名]には、値が全くありません、次に、要素の品目の[接頭語]では、値が全くありません。 ほか、NamedTypeのタイプは直接そうではありませんそして、Markupが間接的にタイプします。
Legg & Prager Experimental [Page 20] RFC 4910 Robust XML Encoding Rules July 2007
強健な[20ページ]RFC4910XML符号化規則2007年7月に実験的なLeggとプラーガー
[prefix] of the element item is determined as specified in Section 6.2.2.2; otherwise, the [prefix] is determined by the Markup value as specified in Section 6.10.
要素の品目の[接頭語]はセクション6.2.2で.2を指定するので、断固としています。 さもなければ、[接頭語]はセクション6.10における指定されるとしてのMarkup値で決定します。
The element item becomes the enclosing element item for the translation of the value of the Type of the NamedType.
要素の品目はNamedTypeのTypeの価値に関する翻訳のための同封の要素の品目になります。
For a non-canonical RXER encoding, if the type of the NamedType is not directly or indirectly the Markup type, then PI and comment items MAY be added to the [children] of the element item (before or after any other items). The element item becomes the [parent] for each PI and comment item. These particular PI and comment items in a received RXER encoding MAY be discarded by an application.
その時をNamedTypeのタイプが直接そうでないMarkupが間接的にタイプするならコード化する正典外のRXERに関しては、PIとコメント項目は要素の品目(いかなる他の項目の前または後にも)の[子供]に加えられるかもしれません。 要素の品目はそれぞれのPIとコメント項目のための[親]になります。 容認されたRXERコード化におけるこれらの特定のPIとコメント項目はアプリケーションで捨てられるかもしれません。
Aside: There is no provision for representing comments and PIs in
ASN.1 abstract values of types other than the Markup type. These
items will be lost if the abstract value is re-encoded using a
different set of encoding rules.
傍らに: コメントを表すことへの支給が全くありません、そして、Markup以外のタイプのASN.1の抽象的な値におけるPIsはタイプします。 抽象的な値が異なった符号化規則を使用することで再コード化されると、これらの項目はなくされるでしょう。
For a non-canonical RXER encoding, an attribute item with the [local name] "type" and the [namespace name] "http://www.w3.org/2001/XMLSchema-instance" (i.e., xsi:type [XSD1]) SHOULD be added to the [attributes] of the element item if the corresponding NamedType is subject to a TYPE-AS-VERSION encoding instruction and MAY be added to the [attributes] of the element item if the Type of the corresponding NamedType is a namespace-qualified reference (see Section 5). The [prefix] of this attribute item is determined as specified in Section 6.2.3.1. The [normalized value] of this attribute item is a qualified name for the expanded name of the referenced type, with the namespace prefix determined as specified in Section 6.7.11.1. The element item is the [owner element] for the attribute item.
正典外のRXERに関しては、コード化、[地方名]「タイプ」がある属性項目、および[名前空間名]" http://www.w3.org/2001/XMLSchema-instance "(すなわち、xsi: タイプ[XSD1])は、指示をコード化して、バージョンとしてのタイプにおいて、対応するNamedTypeが受けることがあるなら要素の品目の[属性]に加えられるべきであり、対応するNamedTypeのタイプが名前空間で適切な参照(セクション5を見る)であるなら要素の品目の[属性]に加えられるかもしれません。 この属性項目の[接頭語]はセクション6.2.3で.1に指定されるように断固としています。 この属性項目の[正常にされた値]は.1にセクション6.7.11における指定されると決定している名前空間接頭語をもっている被参照型の拡張名前のための適切な名前です。 要素の品目がそうである、属性項目のための[所有者要素。]
Aside: Where a compatible XML Schema translation of the ASN.1
specification has been provided, the xsi:type attribute indicates
to an XML Schema validator which type definition it should use for
validating the RXER encoding.
傍らに: ASN.1仕様のコンパチブルXML Schema翻訳を提供したところでは、xsi: タイプ属性は、それがRXERコード化を有効にするのにどの型定義を使用するべきであるかをXML Schema validatorに示します。
Aside: An xsi:type attribute is generally not permitted in a CRXER
encoding. Section 6.4 describes some circumstances where it is
required in a CRXER encoding. An xsi:type attribute might also
appear in a CRXER encoding if it is contained in a value of the
Markup type.
傍らに: xsi: 一般に、タイプ属性はCRXERコード化で受入れられません。 セクション6.4はそれがCRXERコード化で必要であるいくつかの事情について説明します。 xsi: また、タイプ属性はそれがMarkupタイプの値に含まれているならコード化するCRXERに現れるかもしれません。
For a non-canonical RXER encoding, if the type of the NamedType is not directly or indirectly the Markup type, then attribute items with the [local name] "schemaLocation" or "noNamespaceSchemaLocation" and the [namespace name] "http://www.w3.org/2001/XMLSchema-instance"
[地方名]の"schemaLocation"か"noNamespaceSchemaLocation"と共に当時の属性項目をNamedTypeのタイプが直接そうでないMarkupが間接的にタイプするならコード化する正典外のRXERと[名前空間名]" http://www.w3.org/2001/XMLSchema-instance "のために
Legg & Prager Experimental [Page 21] RFC 4910 Robust XML Encoding Rules July 2007
強健な[21ページ]RFC4910XML符号化規則2007年7月に実験的なLeggとプラーガー
[XSD1] MAY be added to the [attributes] of the element item. The [prefix] for each of these attribute items is determined as specified in Section 6.2.3.1. The [normalized value] of these attribute items MUST reference a compatible XML Schema translation of the ASN.1 specification. The element item is the [owner element] for the attribute items.
[XSD1]は要素の品目の[属性]に加えられるかもしれません。 それぞれのこれらの属性項目のための[接頭語]はセクション6.2.3で.1に指定されるように断固としています。 これらの属性項目の[正常にされた値]はASN.1仕様のコンパチブルXML Schema翻訳に参照をつけなければなりません。 要素の品目がそうである、属性項目のための[所有者要素。]
6.2.2.1. Namespace Properties for Elements
6.2.2.1. Elementsのための名前空間の特性
This section describes how the [in-scope namespaces] and [namespace attributes] of an element item are constructed when the content and attributes of the element item are not described by a value of the Markup type (otherwise, see Section 6.10).
このセクションがその方法を説明する、要素の品目の内容と属性がMarkupタイプの値によって説明されないとき(さもなければ、セクション6.10を見てください)、要素の品目の[範囲の名前空間]と[名前空間属性]は組み立てられます。
The [in-scope namespaces] property of the element item initially contains only the mandatory namespace item for the "xml" prefix [INFOSET].
要素の品目の[範囲の名前空間]特性は初めは、"xml"接頭語[INFOSET]のための義務的な名前空間項目だけを含みます。
For a CRXER encoding, if the element item is not the [document element] of the document item and the [in-scope namespaces] property of the element item's [parent] contains a namespace item for the default namespace, then a namespace declaration attribute item that undeclares the default namespace (see Section 3) SHALL be added to the element item's [namespace attributes].
ドキュメントの品目の[ドキュメント要素]と要素の品目の[親]の[範囲の名前空間]特性は名前空間項目を含んでいます。要素の品目がコード化しないならコード化するCRXER、次に、デフォルト名前空間、デフォルト名前空間(セクション3を見る)SHALLを非宣言する名前空間宣言属性項目には、品目の要素もの[名前空間属性]に追加されてください。
Definition (default namespace restricted): With respect to an element item, the default namespace is restricted if:
定義(制限されたデフォルト名前空間): 要素の品目に関して、デフォルト名前空間が制限される、:
(1) the [namespace name] of the element item has no value (i.e., the
element's name is not namespace qualified), or
または(1)、要素の品目の[名前空間名]には値が全くない、(すなわち、要素の名前は名前空間適切ではありません)。
(2) the element item is the enclosing element item for a value of the
UNION type where the member attribute will be required (see
Section 6.7.14), or
または(2) 要素の品目がメンバー属性が必要である(セクション6.7.14を見てください)UNIONタイプのa値のための同封の要素の品目である。
(3) the element item is the enclosing element item for a value of the
QName type where the namespace-name component is absent (see
Section 6.7.11). This includes the case where the translation of
the QName value is contained in the [normalized value] of an
attribute item in the [attributes] of the element item.
(3) 要素の品目は名前空間名のコンポーネントが欠けている(セクション6.7.11を見てください)QNameタイプの値のための同封の要素の品目です。 これがQName価値に関する翻訳が含まれている場合を含んでいる、[値を正常にします] 要素の品目の[属性]における属性項目について。
For a non-canonical RXER encoding, if the element item is not the [document element] of the document item and the [in-scope namespaces] property of the element item's [parent] contains a namespace item for the default namespace, then either:
要素の品目がコード化しないならコード化する正典外のRXER、次に、ドキュメントの品目の[ドキュメント要素]と要素の品目の[親]の[範囲の名前空間]特性はデフォルト名前空間のための名前空間項目を含んでいます:
(1) that item is copied to the [in-scope namespaces] of the element
item, or
または(1) その項目がコピーされる、要素の品目の[範囲の名前空間]。
Legg & Prager Experimental [Page 22] RFC 4910 Robust XML Encoding Rules July 2007
強健な[22ページ]RFC4910XML符号化規則2007年7月に実験的なLeggとプラーガー
(2) a namespace declaration attribute item that declares the default
namespace is added to the element item's [namespace attributes]
(the namespace name is the encoder's choice), and an equivalent
namespace item is added to the [in-scope namespaces] of the
element item, or
または(2) デフォルト名前空間を宣言する名前空間宣言属性項目が品目の要素もの[名前空間属性]に追加されて(名前空間名はエンコーダの選択です)、同等な名前空間項目に追加される、要素の品目の[範囲の名前空間]。
(3) a namespace declaration attribute item that undeclares the
default namespace is added to the element item's
[namespace attributes].
(3) デフォルト名前空間を非宣言する名前空間宣言属性項目は品目の要素もの[名前空間属性]に追加されます。
Options (1) and (2) SHALL NOT be used if the default namespace is restricted with respect to the element item.
オプション(1)と(2)SHALL NOT、デフォルト名前空間が要素の品目に関して制限されるなら、使用されてください。
For a CRXER encoding, if the element item is not the [document element] of the document item and the element item is not required to be self-contained, then all the namespace items in the [in-scope namespaces] of the [parent], excluding the namespace item for the "xml" prefix and any namespace item for the default namespace, are copied to the [in-scope namespaces] of the element item.
要素の品目がコード化しないならコード化するCRXER、ドキュメントの品目と要素の品目の[ドキュメント要素]は自己充足的になるのに必要でなく、次に、すべてが中の名前空間項目である、[親]の[範囲の名前空間]、"xml"接頭語のために名前空間項目を除いて、およびデフォルト名前空間のためのどんな名前空間項目もコピーされる、要素の品目の[範囲の名前空間。]
For a non-canonical RXER encoding, if the element item is not the [document element] of the document item and the element item is not required to be self-contained, then any subset (including none or all) of the namespace items in the [in-scope namespaces] of the [parent], excluding certain items, is copied to the [in-scope namespaces] of the element item. The excluded items that MUST NOT be copied are: the namespace item for the "xml" prefix, any namespace item for the default namespace, and any namespace item that matches the [prefix], but not the [namespace name], of a namespace item retained for the re-encoding of an unknown attribute item (see Section 6.8.8) or an unknown alternative of a UNION (see Section 6.7.14).
要素の品目がコード化しないならコード化する正典外のRXER、ドキュメントの品目と要素の品目の[ドキュメント要素]は自己充足的になるのに必要でなく、その時が中の名前空間項目のあらゆる部分集合(なにもかすべてを含んでいる)である、[親]の[範囲の名前空間]が、ある項目を除いてコピーされる、要素の品目の[範囲の名前空間。] コピーしてはいけない除かれた項目は以下の通りです。 "xml"接頭語のための名前空間項目、デフォルト名前空間のためのどんな名前空間項目、および[接頭語]に合っているどんな名前空間項目だけ、も未知の属性項目(セクション6.8.8を見る)かUNIONの未知の代替手段(セクション6.7.14を見る)の再コード化のために保有された名前空間項目で[名前空間名義。]です。
Aside: The descriptive approach used by this document only allows
a namespace prefix to be used by a new namespace item if it is not
currently used by another namespace item in the
[in-scope namespaces]. By not inheriting a namespace item, the
prefix of that namespace is again available for reuse without fear
of breaking an existing dependency on the prefix.
傍らに: それが現在中でもう1つの名前空間項目によって使用されない場合にだけこのドキュメントによって使用される記述的アプローチが、名前空間接頭語が新しい名前空間項目によって使用されるのを許容する、[範囲の名前空間。] 名前空間項目を引き継がないことによって、その名前空間の接頭語は再び、接頭語で既存の依存を壊すことへの恐怖なしで再利用に利用可能です。
Element items that are required to be self-contained inherit none of the namespace items in the [in-scope namespaces] of the [parent].
自己充足的になるのに必要である要素の品目が中で名前空間項目のいずれも引き継がない、[親]の[範囲の名前空間。]
Any namespace item that is retained for the re-encoding of an unknown attribute item (Section 6.8.8) or an unknown alternative of a UNION (Section 6.7.14) and which is not in the [in-scope namespaces] of the element item MUST be added to the [in-scope namespaces]. An
未知の属性項目(セクション6.8.8)かUNIONの未知の代替手段(セクション6.7.14)の再コード化のために保有されて、中にないどんな名前空間項目、も要素の品目の[範囲の名前空間]を加えなければならない、[範囲の名前空間。] 1
Legg & Prager Experimental [Page 23] RFC 4910 Robust XML Encoding Rules July 2007
強健な[23ページ]RFC4910XML符号化規則2007年7月に実験的なLeggとプラーガー
equivalent namespace declaration attribute item MUST be added to the [namespace attributes] of the element item.
同等な名前空間宣言属性項目を加えなければならない、要素の品目の[名前空間属性。]
Definition (unused namespace prefix): A namespace prefix is unused if it does not match the [prefix] of any namespace item in the [in-scope namespaces] of the element item.
定義(未使用の名前空間接頭語): 中でどんな名前空間項目の[接頭語]も合わせないなら名前空間接頭語が未使用である、要素の品目の[範囲の名前空間。]
For a non-canonical RXER encoding, if the type of the NamedType is not directly or indirectly the Markup type, then additional namespace declaration attribute items for currently unused namespace prefixes MAY be added to the [namespace attributes] of the element item. An equivalent namespace item MUST be added to the [in-scope namespaces] of the element item for each additional namespace declaration attribute item.
現在の未使用の名前空間接頭語が追加されるかもしれない当時の追加名前空間宣言属性項目をNamedTypeのタイプが直接そうでないMarkupが間接的にタイプするならコード化する正典外のRXER、要素の品目の[名前空間属性。] 同等な名前空間項目を加えなければならない、それぞれの追加名前空間宣言属性項目のための要素の品目の[範囲の名前空間。]
For a non-canonical RXER encoding, if the type of the NamedType is not directly or indirectly the Markup type, and the [in-scope namespaces] property of the element item does not contain a namespace item for the default namespace, and the default namespace is not restricted with respect to the element item, then a namespace declaration attribute item for the default namespace MAY be added to the [namespace attributes] of the element item, in which case an equivalent namespace item MUST be added to the [in-scope namespaces] of the element item.
NamedTypeのタイプが直接か間接的にコード化しないならコード化する正典外のRXERに関しては、Markupはタイプします、そして、範囲の要素の品目の名前空間の特性はデフォルト名前空間のための名前空間項目を含んでいません、そして、デフォルト名前空間は要素の品目に関して制限されません; 次に、デフォルト名前空間のための名前空間宣言属性項目は要素の品目の名前空間属性に加えられるかもしれません、その場合、範囲の要素の品目の名前空間に同等な名前空間項目を加えなければなりません。
Whenever a namespace declaration attribute item is added to an element item's [namespace attributes], the [owner element] of the attribute item is set to the element item.
名前空間宣言属性項目が品目の要素もの[名前空間属性]に追加されるときはいつも、設定する、属性項目の[所有者要素]は要素の品目に設定されます。
6.2.2.2. Namespace Prefixes for Element Names
6.2.2.2. 要素名のための名前空間接頭語
This section describes how the [prefix] of an element item is determined when the element item has a value for its [namespace name] and the content and attributes of the element item are not described by a value of the Markup type (otherwise, see Section 6.10).
要素の品目の[接頭語]が要素の品目にaがあるとき、それが[名前空間名義]であり、要素の品目の内容と属性がMarkupの値によって説明されないので、値がタイプする(さもなければ、セクション6.10を見る)とどう決心しているかをこのセクションは説明します。
For a CRXER encoding, if the [namespace name] of the element item has a value, then the [prefix] of the element item is any unused non-canonical namespace prefix unless the [in-scope namespaces] property of the element item contains a namespace item with the same [namespace name] as the element item. In that case, the [prefix] of that namespace item SHALL be used as the [prefix] of the element item.
CRXERコード化のために要素の品目の[名前空間名]には、値があって、要素の品目の[範囲の名前空間]特性が要素の品目として同じくらいがある名前空間項目[名前空間名]を含んでいない場合、次に、要素の品目の[接頭語]はあらゆる未使用の正典外の名前空間接頭語です。 その場合、[前に置きます] その名前空間項目SHALLでは、要素の品目の[接頭語]として使用されてください。
Aside: These prefixes will be rewritten to canonical namespace
prefixes during the final step in producing the Infoset
translation (see Section 6.11). Canonical namespace prefixes are
not used here in the first instance because canonicalization
傍らに: 最終的なステップの間、これらの接頭語はInfoset翻訳を作り出す際に正準な名前空間接頭語に書き直されるでしょう(セクション6.11を見てください)。 正準な名前空間接頭語がここでまず使用されない、canonicalization
Legg & Prager Experimental [Page 24] RFC 4910 Robust XML Encoding Rules July 2007
強健な[24ページ]RFC4910XML符号化規則2007年7月に実験的なLeggとプラーガー
depends on knowing the final [namespace attributes] produced by
encoding the abstract value of the type of the NamedType. If an
implementation looks ahead to determine this final set prior to
translating the abstract value, then it can assign the appropriate
canonical namespace prefix in this step and skip the rewriting
step.
NamedTypeのタイプの抽象的な値をコード化することによって起こされた決勝[名前空間属性]を知っているのによります。 実装が抽象的な値を翻訳する前にこのファイナルセットを決定するために前を見るなら、それは、このステップにおける適切な正準な名前空間接頭語を割り当てて、書き直しステップをサボることができます。
For a non-canonical RXER encoding, if the [namespace name] has a value, then the [prefix] of the element item is any unused namespace prefix unless the [in-scope namespaces] property of the element item contains a namespace item with the same [namespace name] as the element item. In that case, the [prefix] of that namespace item MAY be used as the [prefix] of the element item. Note that the [prefix] of a namespace item for the default namespace has no value.
正典外のRXERコード化のために[名前空間名]には、値があって、要素の品目の[範囲の名前空間]特性が要素の品目として同じくらいがある名前空間項目[名前空間名]を含んでいない場合、次に、要素の品目の[接頭語]はあらゆる未使用の名前空間接頭語です。 その場合、その名前空間項目の[接頭語]は要素の品目の[接頭語]として使用されるかもしれません。 デフォルト名前空間のための名前空間項目の[接頭語]には値が全くないことに注意してください。
If the [prefix] of the element item is an unused namespace prefix, then a namespace declaration attribute item associating the namespace prefix with the namespace name MUST be added to the [namespace attributes] of the element item, and a corresponding namespace item MUST be added to the [in-scope namespaces] of the element item.
要素の品目の[接頭語]が未使用の名前空間接頭語であるなら名前空間接頭語を名前空間名に関連づける名前空間宣言属性項目に追加しなければならない、要素の品目、および対応する名前空間項目の[名前空間属性]に加えなければならない、要素の品目の[範囲の名前空間。]
Aside: The [local name] of the namespace declaration attribute
item is the same as the [prefix] of the element item, the
[namespace name] of the attribute item is
"http://www.w3.org/2000/xmlns/", and the [normalized value] of the
attribute item is the same as the [namespace name] of the element
item. The namespace item has the same [prefix] and
[namespace name] as the element item.
傍らに: そして、名前空間宣言属性項目の[地方名]が要素の品目の[接頭語]と同じである、属性項目の[名前空間名]が" http://www.w3.org/2000/xmlns/ "である、属性項目の[正常にされた値]が同じである、要素の品目の[名前空間名。] 名前空間項目には、要素の品目として同じ[接頭語]と[名前空間名]があります。
6.2.3. Attribute Components
6.2.3. 属性コンポーネント
A value of a NamedType subject to an ATTRIBUTE or ATTRIBUTE-REF encoding instruction is translated as an attribute item added to the [attributes] of the enclosing element item (which becomes the [owner element] of the attribute item).
属性項目が同封の要素の品目の[属性]に加えたように指示をコード化するATTRIBUTEかATTRIBUTE-REFを条件としたNamedTypeのA値が翻訳される、(どれがなるか、属性項目の[所有者要素])
The [local name] of the attribute item is the local name of the expanded name of the NamedType (see [RXEREI]).
属性項目の[地方名]はNamedTypeという拡張名前の地方名([RXEREI]を見る)です。
If the namespace name of the expanded name has no value, then the [namespace name] of the attribute item has no value; otherwise, the [namespace name] is the namespace name of the expanded name.
次に、拡張名前の名前空間名で値が全くない、属性項目の[名前空間名]には、値が全くありません。 そうでなければ、[名前空間名]は拡張名前の名前空間名です。
If the [namespace name] has a value, then the [prefix] of the attribute item is determined as specified in Section 6.2.3.1; otherwise, the [prefix] of the attribute item has no value.
[名前空間名]には、a値があります、次に、属性項目の[接頭語]はセクション6.2.3で.1を指定するので、断固としています。 さもなければ、属性項目の[接頭語]には、値が全くありません。
Legg & Prager Experimental [Page 25] RFC 4910 Robust XML Encoding Rules July 2007
強健な[25ページ]RFC4910XML符号化規則2007年7月に実験的なLeggとプラーガー
The [normalized value] of the attribute item is the translation of the value of the Type of the NamedType.
属性項目の[正常にされた値]はNamedTypeのTypeの価値に関する翻訳です。
For completeness, the [specified] property is set to true, the [attribute type] has no value, and the value of the [references] property is set to unknown.
完全性において、[指定される]の特性は本当に設定されて、[属性タイプ]には、値が全くなくて、[参照]属性の価値は未知に設定されます。
6.2.3.1. Namespace Prefixes for Attribute Names
6.2.3.1. 属性名のための名前空間接頭語
This section applies when an attribute item with a value for its [namespace name] is added to the [attributes] of an element item.
それが[名前空間名義]であるので値がある属性項目が要素の品目の[属性]に加えられるとき、このセクションは適用されます。
For a CRXER encoding, the [prefix] of the attribute item is any unused non-canonical namespace prefix unless the [in-scope namespaces] property of the [owner element] contains a namespace item with a value for the [prefix] (i.e., is not a namespace item for the default namespace) and the same [namespace name] as the attribute item. In that case, the [prefix] of that namespace item SHALL be used as the [prefix] of the attribute item.
CRXERに関して、コード化、属性項目の[接頭語]があらゆる未使用の正典外の名前空間接頭語である、[範囲の名前空間]特性、[所有者要素]は属性項目と[接頭語](すなわち、デフォルト名前空間のための名前空間項目でない)と同じくらい[名前空間名]のための値がある名前空間項目を含んでいます。 その場合、[前に置きます] その名前空間項目SHALLでは、属性項目の[接頭語]として使用されてください。
For a non-canonical RXER encoding, the [prefix] of the attribute item is any unused namespace prefix unless the [in-scope namespaces] property of the [owner element] contains a namespace item with a value for the [prefix] and the same [namespace name] as the attribute item. In that case, the [prefix] of that namespace item MAY be used as the [prefix] of the attribute item.
正典外のRXERに関して、コード化、属性項目の[接頭語]があらゆる未使用の名前空間接頭語である、[範囲の名前空間]特性、[所有者要素]は[接頭語]のための値と属性項目と同じくらい[名前空間名]がある名前空間項目を含んでいます。 その場合、その名前空間項目の[接頭語]は属性項目の[接頭語]として使用されるかもしれません。
If the [prefix] of the attribute item is an unused namespace prefix, then a namespace declaration attribute item associating the namespace prefix with the namespace name MUST be added to the [namespace attributes] of the [owner element], and a corresponding namespace item MUST be added to the [in-scope namespaces] of the [owner element].
属性項目の[接頭語]が未使用の名前空間接頭語であるなら名前空間接頭語を名前空間名に関連づける名前空間宣言属性項目に追加しなければならない、[名前空間属性]、[所有者要素]、および対応する名前空間項目がそうであるに違いない、加えられる、[範囲の名前空間]、[所有者要素。]
6.2.4. Unencapsulated Components
6.2.4. コンポーネントをUnencapsulatedしました。
A value of a NamedType subject to a GROUP or SIMPLE-CONTENT encoding instruction is translated as the value of the Type of the NamedType, i.e., without encapsulation in an element item or attribute item. Consequently, the enclosing element item for the translation of the value of the NamedType is also the enclosing element item for the translation of the value of the Type of the NamedType.
指示をコード化するGROUPかSIMPLE-CONTENTを条件としたNamedTypeの値はNamedTypeのTypeの値として翻訳されます、すなわち、要素の品目か属性項目のカプセル化なしで。 その結果、また、NamedTypeの価値に関する翻訳のための同封の要素の品目はNamedTypeのTypeの価値に関する翻訳のための同封の要素の品目です。
Legg & Prager Experimental [Page 26] RFC 4910 Robust XML Encoding Rules July 2007
強健な[26ページ]RFC4910XML符号化規則2007年7月に実験的なLeggとプラーガー
6.2.5. Examples
6.2.5. 例
Consider this type definition:
この型定義を考えてください:
CHOICE {
one [0] BOOLEAN,
two [1] [RXER:ATTRIBUTE] INTEGER,
three [2] [RXER:NAME AS "THREE"] OBJECT IDENTIFIER,
four [3] [RXER:ATTRIBUTE-REF {
namespace-name "http://www.example.com",
local-name "foo" }] UTF8String,
five [4] [RXER:ELEMENT-REF {
namespace-name "http://www.example.com",
local-name "bar" }] Markup,
six [5] [RXER:GROUP] SEQUENCE {
seven [0] [RXER:ATTRIBUTE] INTEGER,
eight [1] INTEGER
}
}
選択ブールある[0]2[1][RXER: ATTRIBUTE]INTEGER、3[2][RXER: NAME AS「3」]オブジェクト識別子、4[3][RXER: 属性審判の名前空間名の" http://www.example.com "の、そして、ローカルの名前の"foo"]UTF8String、5[4][RXER: 要素審判の名前空間名の" http://www.example.com "の、そして、ローカルの名前の「バー」]マーク付け、6[5][RXER: グループ]は7[0][RXER: 属性]整数、8[1]整数を配列します。
The content and attributes of each of the following <value> elements are the RXER encoding of a value of the above type:
それぞれの以下の<値の>要素の内容と属性は上のタイプの価値のRXERコード化です:
<value>
<one>true</one>
</value>
<値の><</1つの1>の本当の></価値の>。
<value two="100"/>
<値twoは「100」/>と等しいです。
<value>
<THREE>2.5.4.3</THREE>
</value>
<値の><3>2.5.4.3</3></値の>。
<value xmlns:ex="http://www.example.com"
ex:foo="a string"/>
<値のxmlns: 例えば、foo=「ストリング」元の=" http://www.example.com "/>。
<value>
<ex:bar xmlns:ex="http://www.example.com">another string</ex:bar>
</value>
<が><を評価して、例えば、バーが=から以下をxmlnsする、「 http://www.example.com 、「>、例えば、別のストリング</バー></価値>、」
<value seven="200">
<eight>300</eight>
</value>
<値sevenが等しい、「200、「><8>300</8></価値の>」
Legg & Prager Experimental [Page 27] RFC 4910 Robust XML Encoding Rules July 2007
強健な[27ページ]RFC4910XML符号化規則2007年7月に実験的なLeggとプラーガー
6.3. Standalone Encodings
6.3. スタンドアロンEncodings
A typical RXER encoding is the encoding of a value of a nominated top-level NamedType. An abstract value MAY be encoded as an XML document without nominating an explicit top-level NamedType by invoking a Standalone RXER Encoding or Standalone CRXER Encoding.
典型的なRXERコード化は指名トップレベルNamedTypeの価値のコード化です。 Standalone RXER EncodingかStandalone CRXER Encodingを呼び出すことによって明白なトップレベルNamedTypeを指名しないで、抽象的な値はXMLドキュメントとしてコード化されるかもしれません。
In a Standalone RXER Encoding or Standalone CRXER Encoding, the abstract value is encoded as the value of a notional NamedType where the identifier of the NamedType is "value" and the Type of the NamedType is the type of the abstract value. The NamedType is assumed to be subject to no encoding instructions.
Standalone RXER EncodingかStandalone CRXER Encodingでは、抽象的な値は、NamedTypeに関する識別子が「値」である概念的なNamedTypeの値とNamedTypeのTypeが抽象的な価値のタイプであるので、コード化されます。 NamedTypeは指示をコード化しないのを受けることがあると思われます。
Aside: Thus, the element item corresponding to the document
element will have the [local name] "value" and no value for the
[namespace name] and [prefix].
傍らに: その結果、[地方名]「値」を持っていますが、ドキュメント要素に対応する要素の品目にはどんな値もない、[名前空間名]と[接頭語。]
If RXER is chosen as the transfer syntax in an EMBEDDED PDV value, then the data-value OCTET STRING SHALL contain a Standalone RXER encoding.
RXERがEMBEDDED PDV値における転送構文として選ばれているなら、データ価値のOCTET STRING SHALLはStandalone RXERコード化を含んでいます。
If CRXER is chosen as the transfer syntax in an EMBEDDED PDV value, then the data-value OCTET STRING SHALL contain a Standalone CRXER encoding.
CRXERがEMBEDDED PDV値における転送構文として選ばれているなら、データ価値のOCTET STRING SHALLはStandalone CRXERコード化を含んでいます。
If RXER is chosen as the transfer syntax in an EXTERNAL value, then the octet-aligned OCTET STRING or arbitrary BIT STRING SHALL contain a Standalone RXER encoding.
RXERがEXTERNAL値における転送構文として選ばれているなら、八重奏で並べられたOCTET STRINGか任意のBIT STRING SHALLがStandalone RXERコード化を含んでいます。
If CRXER is chosen as the transfer syntax in an EXTERNAL value, then the octet-aligned OCTET STRING or arbitrary BIT STRING SHALL contain a Standalone CRXER encoding.
CRXERがEXTERNAL値における転送構文として選ばれているなら、八重奏で並べられたOCTET STRINGか任意のBIT STRING SHALLがStandalone CRXERコード化を含んでいます。
6.4. Embedded ASN.1 Values
6.4. 埋め込まれたASN.1値
The reference encoding instructions [RXEREI] allow XML Schema definitions to be referenced from an ASN.1 specification. It is also possible to reference an ASN.1 type or top-level NamedType from an XML Schema definition or from an information item validated by an XML Schema wildcard. The manner in which an XML Schema definition references an ASN.1 type or top-level NamedType has an effect on the CRXER encoding of a value of the type or top-level NamedType.
参照コード化指示は、XML Schema定義がASN.1仕様から参照をつけられるのを許容します[RXEREI]。 また、それもASN.1がタイプするか、またはXML Schema定義か情報項目からのトップレベルNamedTypeがXML Schemaワイルドカードで有効にした参照に可能です。 XML Schema定義がASN.1タイプかトップレベルNamedTypeに参照をつける方法はタイプか先端平らなNamedTypeの価値のCRXERコード化に影響を与えます。
This section also applies to XML Schema definitions that validate information items that are contained in a value of the Markup type.
また、このセクションはMarkupタイプの値に含まれている情報項目を有効にするXML Schema定義に適用されます。
Legg & Prager Experimental [Page 28] RFC 4910 Robust XML Encoding Rules July 2007
強健な[28ページ]RFC4910XML符号化規則2007年7月に実験的なLeggとプラーガー
Aside: So the document element of an XML document might be
described by an XML Schema definition that at some point
references an ASN.1 definition that uses a reference encoding
instruction to reference another XML Schema definition that then
references another ASN.1 definition, and so on.
傍らに: それで、XMLドキュメントのドキュメント要素は何らかのポイントで次に別のASN.1定義などに参照をつける別のXML Schema定義に参照をつけるために指示をコード化する参照を使用するASN.1定義に参照をつけるXML Schema定義で説明されるかもしれません。
In each of the following cases, an element or attribute item is only permitted to be, or to encapsulate, an RXER Infoset translation of an ASN.1 value if an XML Schema element declaration or ASN.1 NamedType is known for the [parent] element item ([owner element] in the case of an attribute declaration), for the [parent] of the [parent] element item, and so on, to the document element of the XML document. This condition is not satisfied by a NamedType where the Type is directly or indirectly the Markup type and the NamedType is not subject to a reference encoding instruction.
ASN.1価値に関するRXER Infoset翻訳はXML Schema要素宣言かASN.1NamedTypeであるなら[親]要素の品目(属性宣言の場合における[所有者要素])で知られています、[親]要素の品目の[親]などのために、それぞれ項目がカプセルに入れることが許可されるだけである以下の場合、要素または属性ではXMLドキュメントのドキュメント要素に。 間接的に、Markupはタイプします、そして、この状態がTypeが直接そうであるNamedTypeによって満たされていないか、またはNamedTypeは指示をコード化する参照を受けることがありません。
Aside: An element declaration becomes known for an element item
through assessment [XSD1]. A NamedType becomes known for an
element item through decoding.
傍らに: 査定[XSD1]で要素宣言は要素の品目のために知られるようになります。 NamedTypeは要素の品目のために解読で知られるようになります。
Aside: If an XML Schema element declaration or ASN.1 NamedType is
not known for an element item, then the type of the element item
and the type of every nested element item are treated as unknown.
Although an xsi:type attribute definitively identifies the type of
an element item even if an element declaration for the element
item is not known, this attribute is generally optional in an RXER
encoding and so cannot be relied upon when seen in isolation from
an element declaration. Although only top-level NamedType
instances can have namespace-qualified names in the current RXER
specification, a future version may allow nested NamedType
instances to also have namespace-qualified names, in which case it
will not necessarily be possible to distinguish a nested NamedType
from a top-level NamedType without knowledge of the type of the
[parent] element item.
傍らに: XML Schema要素宣言かASN.1NamedTypeが要素の品目で知られていないなら、要素の品目のタイプとあらゆる入れ子にされた要素の品目のタイプは未知として扱われます。 要素の品目のための要素宣言が知られないでも、xsi: タイプ属性は決定的に要素の品目のタイプを特定しますが、分離して要素宣言から見られる場合、RXERコード化で一般に任意であるので、この属性を当てにすることができません。 トップレベルNamedTypeインスタンスだけが現在のRXER仕様に名前空間で適切な名前を持つことができますが、将来のバージョンで、また、入れ子にされたNamedTypeインスタンスは名前空間で適切な名前を持つことができるかもしれません、その場合、必ず、トップレベルNamedTypeと[親]要素の品目のタイプに関する知識なしで入れ子にされたNamedTypeを区別するのは可能であるというわけではないでしょう。
An ASN.1 type with an expanded name (Section 5) MAY be referenced by the type attribute of an XML Schema element declaration. The reference takes the form of a qualified name for the expanded name. An element item validated by such an element declaration encapsulates the Infoset translation of an abstract value of the ASN.1 type. The [namespace name] and [local name] of the element item are determined by the XML Schema element declaration. The remaining properties are determined according to RXER. The element item MUST be self-contained for a CRXER encoding.
拡張名前(セクション5)があるASN.1タイプはXML Schema要素宣言のタイプ属性によって参照をつけられるかもしれません。 参照は適切な名前の形を拡張名前に連れて行きます。 そのような要素宣言で有効にされた要素の品目は、InfosetがASN.1タイプの抽象的な価値に関する翻訳であるとカプセル化します。 要素の品目の[名前空間名義]と[地方名]はXML Schema要素宣言で決定します。 RXERによると、残っている特性は決定しています。 CRXERコード化に、要素の品目は自己充足的であるに違いありません。
Aside: The element item is not required to be self-contained for a
non-canonical RXER encoding.
傍らに: 要素の品目は、正典外のRXERコード化に自己充足的になるのに必要ではありません。
Legg & Prager Experimental [Page 29] RFC 4910 Robust XML Encoding Rules July 2007
強健な[29ページ]RFC4910XML符号化規則2007年7月に実験的なLeggとプラーガー
A top-level NamedType MAY be referenced by the ref attribute of an XML Schema element declaration if the NamedType is not subject to an ATTRIBUTE encoding instruction. The reference takes the form of a qualified name for the expanded name of the top-level NamedType [RXEREI]. An element item validated by such an element declaration is the Infoset translation of a value of the referenced top-level NamedType. All the properties of the element item are determined according to RXER. The element item MUST be self-contained for a CRXER encoding.
NamedTypeは指示をコード化するATTRIBUTEを受けることがないなら、トップレベルNamedTypeがXML Schema要素宣言の審判属性によって参照をつけられるかもしれません。 参照はトップレベルNamedType[RXEREI]という拡張名前に適切な名前の形を連れて行きます。 そのような要素宣言で有効にされた要素の品目は参照をつけられたトップレベルNamedTypeの価値に関するInfoset翻訳です。 RXERによると、要素の品目のすべての特性が決定しています。 CRXERコード化に、要素の品目は自己充足的であるに違いありません。
A top-level NamedType MAY be referenced by the ref attribute of an XML Schema attribute declaration if the NamedType is subject to an ATTRIBUTE encoding instruction and the definition of the type of the NamedType does not depend on the QName type in any way. An attribute item validated by such an attribute declaration is the Infoset translation of a value of the referenced top-level NamedType, except that whatever valid [prefix] is initially chosen for the attribute item MUST be preserved in any re-encoding. The remaining properties of the attribute item are determined according to RXER.
NamedTypeは指示をコード化するATTRIBUTEを受けることがあるなら、トップレベルNamedTypeがXML Schema属性宣言の審判属性によって参照をつけられるかもしれません、そして、NamedTypeのタイプの定義は何らかの方法でQNameタイプに頼っていません。 そのような属性宣言で有効にされた属性項目は参照をつけられたトップレベルNamedTypeの価値に関するInfoset翻訳です、どんな再コード化でも初めは属性項目に選ばれているいかなる有効な[接頭語]も保存しなければならないのを除いて。 RXERによると、属性項目の残っている特性は決定しています。
Aside: The exclusion of the QName type means that the attribute
value is not dependent upon any namespace declarations of its
parent element item.
傍らに: QNameタイプの除外は、属性値に親元素の品目のどんな名前空間宣言にも依存していないことを意味します。
An element item that is validated by an XML Schema element declaration that has the ur-type (i.e., anyType) as its type definition MAY encapsulate the Infoset translation of a value of an ASN.1 type with an expanded name. The [namespace name] and [local name] of the element item are determined by the XML Schema element declaration. The remaining properties of the element item are determined according to RXER. The [attributes] of the element item SHALL contain an attribute item with the [local name] "type" and the [namespace name] "http://www.w3.org/2001/XMLSchema-instance" (i.e., an xsi:type attribute). The [prefix] of this attribute item is determined as specified in Section 6.2.3.1. The [normalized value] of this attribute item is a qualified name for the expanded name of the ASN.1 type, with the namespace prefix determined as specified in Section 6.7.11.1. The element item MUST be self-contained for a CRXER encoding.
型定義としてur-タイプ(すなわち、anyType)があるXML Schema要素宣言で有効にされる要素の品目は、拡張名前でInfosetがASN.1タイプの価値に関する翻訳であるとカプセル化するかもしれません。 要素の品目の[名前空間名義]と[地方名]はXML Schema要素宣言で決定します。 RXERによると、要素の品目の残っている特性は決定しています。 要素の品目SHALLの[属性]は[地方名]「タイプ」と[名前空間名]" http://www.w3.org/2001/XMLSchema-instance "(すなわち、xsi: タイプ属性)がある属性項目を含んでいます。 この属性項目の[接頭語]はセクション6.2.3で.1に指定されるように断固としています。 この属性項目の[正常にされた値]は.1にセクション6.7.11における指定されると決定している名前空間接頭語があるASN.1タイプの拡張名前のための適切な名前です。 CRXERコード化に、要素の品目は自己充足的であるに違いありません。
An element item that is validated by an XML Schema wildcard (i.e., <xs:any/>) MAY be the Infoset translation of a value of a top-level NamedType that is not subject to an ATTRIBUTE encoding instruction and comes from an ASN.1 module with a target namespace [RXEREI] that satisfies the namespace constraint of the wildcard. All the properties of the element item are determined according to RXER. The element item MUST be self-contained for a CRXER encoding.
XML Schemaワイルドカード(すなわち、<xs: どんな/>も)によって有効にされる要素の品目は、指示をコード化するATTRIBUTEを受けることがないトップレベルNamedTypeの価値に関するInfoset翻訳であるかもしれなく、ワイルドカードの名前空間規制を満たす目標名前空間[RXEREI]と共にASN.1モジュールから来ます。 RXERによると、要素の品目のすべての特性が決定しています。 CRXERコード化に、要素の品目は自己充足的であるに違いありません。
Legg & Prager Experimental [Page 30] RFC 4910 Robust XML Encoding Rules July 2007
強健な[30ページ]RFC4910XML符号化規則2007年7月に実験的なLeggとプラーガー
An attribute item that is validated by an XML Schema wildcard (i.e., <xs:anyAttribute/>) MAY be the Infoset translation of a value of a top-level NamedType if the NamedType is subject to an ATTRIBUTE encoding instruction, comes from an ASN.1 module with a target namespace that satisfies the namespace constraint of the wildcard, and has a type that does not depend on the QName type in any way. Whatever valid [prefix] is initially chosen for the attribute item MUST be preserved in any re-encoding. The remaining properties of the attribute item are determined according to RXER.
XML Schemaワイルドカード(すなわち、<xs: anyAttribute/>)によって有効にされる属性項目には、NamedTypeは指示をコード化するATTRIBUTEを受けることがあるならトップレベルNamedTypeの価値に関するInfoset翻訳であるかもしれなく、ワイルドカードの名前空間規制を満たす目標名前空間と共にASN.1モジュールから来て、何らかの方法でQNameタイプに頼らないタイプがあります。 どんな再コード化でも初めは属性項目に選ばれているいかなる有効な[接頭語]も保存しなければなりません。 RXERによると、属性項目の残っている特性は決定しています。
No other mechanisms for referencing an ASN.1 type or top-level NamedType from a different XML schema language are supported in this version of RXER. In particular, this excludes an ASN.1 type being used as the base type in an XML Schema derivation by extension or restriction, as a member type for an XML Schema union type, as an item type for an XML Schema list type, or as the type in an XML Schema attribute declaration.
ASN.1に参照をつけるための他のメカニズムが全くタイプされないか、または異なったXMLスキーマ言語からのトップレベルNamedTypeはRXERのこのバージョンでサポートされます。 特に、これはベースタイプとしてXML Schema派生に拡大か制限で使用されているASN.1タイプを遮断します、XML Schema組合のためのメンバー型がタイプするように、XML Schemaリストタイプか、XML Schema属性宣言におけるタイプとした項目タイプとして。
A fully conformant RXER implementation will understand both ASN.1 and XML Schema and will recognize the transitions between information items controlled by ASN.1 definitions and those controlled by XML Schema definitions. However, a purely XML Schema validator used to assess the validity of an RXER encoding will perceive any reference to an ASN.1 type or top-level NamedType as an unresolved reference. In order to enable such assessment, it is desirable to provide an XML Schema translation of the ASN.1 definitions being referenced from an XML Schema. Although XML Schema and ASN.1 are broadly similar, they each have unique features that cannot be adequately expressed in the other language, so a semantically equivalent translation is not possible in the general case. Fortunately, to simply achieve successful assessment it is sufficient for the XML Schema translation of an ASN.1 specification to be compatible with that ASN.1 specification. That is, the XML Schema translation MUST be constructed such that every correct RXER encoding is assessed as valid. Although not ideal, it is acceptable for the XML Schema to assess some incorrect RXER encodings as also being valid (a conformant RXER decoder will, of course, reject such an encoding).
conformant RXER実装は、完全に、ASN.1とXML Schemaの両方を理解して、.1の定義とものがXML Schema定義で制御したASNによって制御された情報項目の間の変遷を認識するでしょう。 しかしながら、純粋にRXERがコード化する正当性を評価するのに使用されるXML Schema validatorは知覚するでしょう。未定の参照としてASN.1タイプか最高レベルNamedTypeについてのあらゆる言及を知覚してください。 そのような査定を可能にするために、XML Schemaから参照をつけられるASN.1定義に関するXML Schema翻訳を提供するのは望ましいです。 XML SchemaとASN.1が広く同様ですが、それぞれ彼らにはもう片方の言語で適切に言い表すことができないユニークな特徴があるので、意味的に同等な翻訳は一般的な場合で可能ではありません。 幸い、単にうまくいっている査定を達成するために、ASN.1仕様のXML Schema翻訳はそのASN.1仕様と互換性があるのが、十分です。 すなわち、XML Schema翻訳を構成しなければならないので、あらゆる正しいRXERコード化が有効であるとして評価されます。 理想的ではありませんが、XML Schemaがいくつかの不正確なRXER encodingsを評価するのにおいてそれは、また、有効であるので、許容できます(conformant RXERデコーダはもちろんそのようなコード化を拒絶するでしょう)。
The simplest compatible XML Schema translation of an ASN.1 module is one in which every type is equivalent to the XML Schema ur-type. For example, given an ASN.1 type with the reference name MyType, a sufficient compatible XML Schema type definition is:
ASN.1モジュールの最も簡単なコンパチブルXML Schema翻訳はXML Schema ur-タイプに、すべてのタイプが同等であるものです。 例えば、MyTypeという参照名があるASN.1タイプを考えて、十分なコンパチブルXML Schema型定義は以下の通りです。
Legg & Prager Experimental [Page 31] RFC 4910 Robust XML Encoding Rules July 2007
強健な[31ページ]RFC4910XML符号化規則2007年7月に実験的なLeggとプラーガー
<xs:complexType name="MyType" mixed="true">
<xs:sequence>
<xs:any processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute processContents="lax"/>
</xs:complexType>
「<xs: complexType名前="MyType"が=を混ぜた、「本当に、「><xs: ><xs: あらゆるprocessContents=を配列してください」、手緩さ、」、minOccurs=「0インチのmaxOccurs=」限りない、」 /></xs: 系列><はxsされます: anyAttribute processContentsは「手緩い」/></xs: complexType>と等しいです。
OR
OR
<xs:complexType name="MyType">
<xs:complexContent>
<xs:extension base="xs:anyType"/>
</xs:complexContent>
</xs:complexType>
<xs: complexTypeが=を命名する、「MyType、「></xs: complexContent></xs: ><xs: complexContent><xs: 拡大ベース=「xs: anyType」/complexType>」
Aside: Because of the possible presence of an asnx:context
attribute (Section 6.8.8.1), it is easiest to assume that all
ASN.1 types translate into XML Schema complex types.
傍らに: asnx: 文脈属性の可能な存在、(セクション6.8 .8 .1) すべてのASN.1タイプがXML Schema複素数型に翻訳すると仮定するのは最も簡単です。
Given an ASN.1 top-level NamedType that is not subject to an ATTRIBUTE encoding instruction and has the reference name myElement, a sufficient compatible XML Schema element declaration is:
指示をコード化するATTRIBUTEを受けることがなくて、myElementという参照名を持っているASN.1トップレベルNamedTypeを考えて、十分なコンパチブルXML Schema要素宣言は以下の通りです。
<xs:element name="myElement"/>
<xs: 要素名=の"myElement"/>。
Given an ASN.1 top-level NamedType that is subject to an ATTRIBUTE encoding instruction and has the reference name myAttribute, a sufficient compatible XML Schema attribute declaration is:
指示をコード化するATTRIBUTEを受けることがあって、myAttributeという参照名を持っているASN.1トップレベルNamedTypeを考えて、十分なコンパチブルXML Schema属性宣言は以下の通りです。
<xs:attribute name="myAttribute"/>
<xs: 属性名前="myAttribute"/>。
An application specification that mixes ASN.1 and XML Schema is free to provide a stricter translation of its ASN.1 definitions; however, a more thorough treatment for translating an ASN.1 module into an XML Schema is out of scope for this document.
ASN.1とXML Schemaを混ぜるアプリケーション仕様は無料でASN.1定義の、より厳しい翻訳を提供できます。 しかしながら、このドキュメントのための範囲の外にASN.1モジュールをXML Schemaに翻訳することに関する、より徹底的な処理があります。
6.5. Type Referencing Notations
6.5. 記法に参照をつけて、タイプしてください。
A value of a type with a defined type name is translated according to the type definition on the right-hand side of the type assignment for the type name.
型定義に従って、定義された型名があるタイプの値は型名のためのタイプ課題の右側で翻訳されます。
A value of a type denoted by the use of a parameterized type with actual parameters is translated according to the parameterized type with the DummyReferences [X.683] substituted with the actual parameters.
parameterizedタイプに従って、実引数でparameterizedタイプの使用で指示されたタイプの値は実引数でDummyReferences[X.683]を代入している状態で翻訳されます。
Legg & Prager Experimental [Page 32] RFC 4910 Robust XML Encoding Rules July 2007
強健な[32ページ]RFC4910XML符号化規則2007年7月に実験的なLeggとプラーガー
A value of a constrained type is translated as a value of the type without the constraint. See X.680 [X.680] and X.682 [X.682] for the details of ASN.1 constraint notation.
制約つきタイプの値はタイプの値として規制なしで翻訳されます。 ASN.1規制記法の詳細に関してX.680[X.680]とX.682[X.682]を見てください。
A prefixed type [X.680-1] associates an encoding instruction with a type. A value of a prefixed type is translated as a value of the type without the prefix.
前に置かれたタイプ[X.680-1]はコード化指示をタイプに関連づけます。 前に置かれたタイプの値はタイプの値として接頭語なしで翻訳されます。
Aside: This does not mean that RXER encoding instructions are
ignored. It is simply easier to describe their effects in
relation to specific built-in types, rather than as the
translation of a value of a prefixed type.
傍らに: これは、指示をコード化するRXERが無視されることを意味しません。 特定の内蔵型と関連してそれらの効果について説明するのは単に簡単です、むしろ前に置かれたタイプの価値に関する翻訳より。
A tagged type is a special case of a prefixed type. A value of a tagged type is translated as a value of the type without the tag. ASN.1 tags do not appear in the XML encodings defined by this document.
タグ付けをされたタイプは前に置かれたタイプの特別なケースです。 タグ付けをされたタイプの値はタイプの値としてタグなしで翻訳されます。 ASN.1タグはこのドキュメントによって定義されたXML encodingsに現れません。
A value of a fixed type denoted by an ObjectClassFieldType is translated according to that fixed type (see Section 6.9 for the case of an ObjectClassFieldType denoting an open type).
そのフィクスト・タイプに従って、ObjectClassFieldTypeによって指示されたフィクスト・タイプの値は翻訳されます(開放型を指示するObjectClassFieldTypeのケースに関してセクション6.9を見てください)。
A value of a selection type is translated according to the type referenced by the selection type. Note that component encoding instructions are not inherited by the type referenced by a selection type [RXEREI].
選択タイプによって参照をつけられたタイプに従って、選択タイプの値は翻訳されます。 コンポーネントコード化指示が選択タイプ[RXEREI]によって参照をつけられたタイプによって引き継がれないことに注意してください。
A value of a type described by TypeFromObject notation [X.681] is translated according to the denoted type.
指示されたタイプに従って、TypeFromObject記法[X.681]で説明されたタイプの値は翻訳されます。
A value of a type described by ValueSetFromObjects notation [X.681] is translated according to the governing type.
支配的なタイプに従って、ValueSetFromObjects記法[X.681]で説明されたタイプの値は翻訳されます。
6.6. TypeWithConstraint, SEQUENCE OF Type, and SET OF Type
6.6. TypeWithConstraint、タイプ、およびタイプのセットの系列
For the purposes of this document, a TypeWithConstraint is treated as if it were the parent type [X.680] (either a SEQUENCE OF or SET OF type).
このドキュメントの目的のために、TypeWithConstraintはまるでそれが親タイプ[X.680]であるかのように扱われます(SEQUENCE OFかSET OFのどちらかがタイプします)。
For example,
例えば
SEQUENCE SIZE(1..MAX) OF SomeType
SomeTypeの系列サイズ(1..MAX)
is treated like
扱われます。
SEQUENCE OF SomeType
SomeTypeの系列
Legg & Prager Experimental [Page 33] RFC 4910 Robust XML Encoding Rules July 2007
強健な[33ページ]RFC4910XML符号化規則2007年7月に実験的なLeggとプラーガー
Additionally, a "SEQUENCE OF Type" (including the case where it is the parent type for a TypeWithConstraint) is treated as if it were a "SEQUENCE OF NamedType", where the identifier of the NamedType is assumed to be "item". Similarly, a "SET OF Type" (including the case where it is the parent type for a TypeWithConstraint) is treated as if it were a "SET OF NamedType", where the identifier of the NamedType is assumed to be "item".
さらに、「タイプの系列」(それがTypeWithConstraintのための親タイプであるケースを含んでいる)はまるでそれが「NamedTypeの系列」であるかのように扱われます。そこでは、NamedTypeに関する識別子が「項目」であると思われます。 同様に、「タイプのセット」(それがTypeWithConstraintのための親タイプであるケースを含んでいる)はまるでそれが「NamedTypeのセット」であるかのように扱われます。そこでは、NamedTypeに関する識別子が「項目」であると思われます。
For example,
例えば
SEQUENCE SIZE(1..MAX) OF SomeType
SomeTypeの系列サイズ(1..MAX)
is ultimately treated like
結局、扱われます。
SEQUENCE OF item SomeType
SEQUENCE OFの品目SomeType
6.7. Character Data Translations
6.7. キャラクターデータ変換
For the majority of ASN.1 built-in types, encodings of values of those types never have element content. The encoding of a value of an ASN.1 combining type (except a UNION or LIST type) typically has element content.
ASN.1内蔵型の大部分のために、そういったタイプの人の値のencodingsには、要素含有量が決してありません。 タイプ(UNIONかLISTタイプを除いた)を結合するASN.1の価値のコード化には、要素含有量が通常あります。
For those types that do not produce element content, the translation of an abstract value is described as a character string of ISO 10646 characters [UCS]. This character data translation will be destined to become either part of the [normalized value] of an attribute item, or a series of character items in the [children] of an element item (which becomes the [parent] for the character items). The case that applies is determined in accordance with Section 6.2.
要素含有量を生産しないそういったタイプの人にとって、抽象的な価値に関する翻訳はISO10646キャラクタ[UCS]の文字列として記述されています。 このキャラクタデータ変換が部分になるように運命づけられる、[値を正常にします] 属性項目、または要素の品目(キャラクタ項目のための[親]になる)の[子供]の一連のキャラクタ項目について。 セクション6.2によると、適用されるケースは決定しています。
For a non-canonical RXER encoding, if the type of the abstract value is not directly or indirectly a restricted character string type, the NULL type, or a UNION type, then leading and/or trailing white space characters MAY be added to the character data translation.
その時を抽象的な価値のタイプが直接そうでない制限された文字列タイプ、NULLタイプ、またはUNIONが間接的にタイプするならコード化する正典外のRXERに関しては、主な、そして/または、引きずっている余白キャラクタはキャラクタデータ変換に追加されるかもしれません。
Aside: White space characters are significant in the encoding of a
value of a restricted character string type, and a restricted
character string type can be a member type of a UNION type. The
encoding of a NULL value produces no character data.
傍らに: 余白キャラクタは制限された文字列タイプの価値のコード化で重要です、そして、制限された文字列タイプはUNIONタイプのメンバー型であるかもしれません。 NULL価値のコード化はキャラクタデータを全く作り出しません。
Aside: Optional white space characters are not permitted in a
CRXER encoding.
傍らに: 任意の余白キャラクタはCRXERコード化で受入れられません。
For a non-canonical RXER encoding, if the type of the abstract value is directly or indirectly the AnyURI, NCName, or Name type, then leading and trailing white space characters MAY be added to the character data translation.
その時を抽象的な価値のタイプが直接そうかAnyURI、NCName、またはNameが間接的にタイプするならコード化する正典外のRXERに関しては、主で引きずっている余白キャラクタはキャラクタデータ変換に追加されるかもしれません。
Legg & Prager Experimental [Page 34] RFC 4910 Robust XML Encoding Rules July 2007
強健な[34ページ]RFC4910XML符号化規則2007年7月に実験的なLeggとプラーガー
Aside: These types are indirectly a restricted character string
type (UTF8String); however, their definitions exclude white space
characters, so any white space characters appearing in an encoding
are not part of the abstract value and can be safely ignored.
This exception does not apply to other subtypes of a restricted
character string type that happen to exclude white space
characters.
傍らに: これらのタイプは間接的に、制限された文字列が(UTF8String)をタイプするということです。 しかしながら、彼らの定義が余白キャラクタを除くので、コード化に現れるどんな余白キャラクタも、抽象的な価値の一部でなく、安全に無視できます。 この例外は、余白キャラクタを除くのに起こる制限された文字列タイプの他の血液型亜型に申し込みません。
6.7.1. Restricted Character String Types
6.7.1. 制限された文字列タイプ
The character data translation of a value of a restricted character string type is the sequence of characters in the string.
制限された文字列タイプの価値に関するキャラクタデータ変換はストリングのキャラクタの系列です。
Depending on the ASN.1 string type, and an application's internal representation of that string type, a character may need to be translated to or from the equivalent ISO 10646 character code [UCS]. The NumericString, PrintableString, IA5String, VisibleString (ISO646String), BMPString, UniversalString, and UTF8String character encodings use the same character codes as ISO 10646. For the remaining string types (GeneralString, GraphicString, TeletexString, T61String, and VideotexString), see X.680 [X.680].
ASN.1ストリングタイプに頼って、アプリケーションのそのストリングタイプの内部の表現、キャラクタはコードか同等なISO10646キャラクタコード[UCS]から翻訳される必要があるかもしれません。 NumericString、PrintableString、IA5String、VisibleString(ISO646String)、BMPString、UniversalString、およびUTF8String文字符号化はISO10646と同じキャラクタコードを使用します。 残っているストリングタイプ(GeneralString、GraphicString、TeletexString、T61String、およびVideotexString)に関しては、X.680[X.680]を見てください。
The null character (U+0000) is not a legal character for XML. It is omitted from the character data translation of a string value.
ヌル文字(U+0000)はXMLのための法的なキャラクタではありません。 それはストリング価値に関するキャラクタデータ変換から省略されます。
Certain other control characters are legal for XML version 1.1, but not for version 1.0. If any string value contains these characters, then the RXER encoding must use XML version 1.1 (see Section 6.12).
他のある制御文字は、XMLバージョン1.1に法的ですが、バージョン1.0のために法的であるというわけではありません。 何かストリング値がこれらのキャラクタを含んでいるなら、RXERコード化はXMLバージョン1.1を使用しなければなりません(セクション6.12を見てください)。
All white space characters in the RXER encoding of a value of a restricted character string type (excluding the AnyURI, NCName, and Name subtypes) are significant, i.e., part of the abstract value.
制限された文字列タイプ(AnyURI、NCName、およびName血液型亜型を除いた)の価値のRXERコード化におけるすべての余白キャラクタが重要です、すなわち、抽象的な価値の一部。
Examples
例
The content of each of the following <value> elements is the RXER
encoding of an IA5String value:
それぞれの以下の<値の>要素の内容はIA5String価値のRXERコード化です:
<value> Don't run with scissors! </value>
はさみによる走行ではなく、<値の>ドン! </値の>。
<value>Markup (e.g., <value>) has to be escaped.</value>
<値の>Markup(例えば、<値の>)逃げられなければなりません。</は>を評価します。
<value>Markup (e.g., <![CDATA[<value>]]>)
has to be escaped. </value>
<値の>Markup(例えば、<[CDATA[<値の>]]!>)逃げられなければなりません。 </値の>。
Legg & Prager Experimental [Page 35] RFC 4910 Robust XML Encoding Rules July 2007
強健な[35ページ]RFC4910XML符号化規則2007年7月に実験的なLeggとプラーガー
6.7.2. BIT STRING
6.7.2. ビット列
The character data translation of a value of the BIT STRING type is either a binary digit string, a hexadecimal digit string, or a list of bit names.
BIT STRINGタイプの価値に関するキャラクタデータ変換は、バイナリー・ディジットストリング、16進数字ストリング、または噛み付いている名前のリストです。
A binary digit string is a sequence of zero, one, or more of the binary digit characters '0' and '1' (i.e., U+0030 and U+0031). Each bit in the BIT STRING value is encoded as a binary digit in order from the first bit to the last bit.
バイナリー・ディジットストリングはゼロの系列です、2進数文字'0'と'1'(すなわち、U+0030とU+0031)のより多くのひとり。 BIT STRING値における各ビットは最初のビットから最後のビットまで整然としているバイナリー・ディジットとしてコード化されます。
For a non-canonical RXER encoding, if the BIT STRING type has a NamedBitList, then trailing zero bits MAY be omitted from a binary digit string.
正典外のRXERに関しては、次に引きずっているゼロ・ビットをBIT STRINGタイプがNamedBitListを持っているならコード化するのはバイナリー・ディジットストリングから省略されるかもしれません。
A hexadecimal digit string is permitted if and only if the number of bits in the BIT STRING value is zero or a multiple of eight and the character data translation is destined for the [children] of an element item.
そして、16進数字ストリングが受入れられる、BIT STRING値における、ビットの数が8のゼロかそれとも倍数であるにすぎないか、そして、キャラクタデータ変換は要素の品目の[子供]のために運命づけられています。
A hexadecimal digit string is a sequence of zero, one, or more pairs of the hexadecimal digit characters '0'-'9', 'A'-'F', and 'a'-'f' (i.e., U+0030-U+0039, U+0041-U+0046 and U+0061-U+0066). Each group of eight bits in the BIT STRING value is encoded as a pair of hexadecimal digits where the first bit is the most significant. An odd number of hexadecimal digits is not permitted. The characters 'a'-'f' (i.e., U+0061-U+0066) SHALL NOT be used in the CRXER encoding of a BIT STRING value. If a hexadecimal digit string is used, then the enclosing element's [attributes] MUST contain an attribute item with the [local name] "format", the [namespace name] "urn:ietf:params:xml:ns:asnx", and the [normalized value] "hex" (i.e., asnx:format="hex"). The [prefix] of the attribute item is determined as specified in Section 6.2.3.1.
16進数字ストリングは、1組以上のゼロの系列と、16進数字キャラクタ'0'--'9'、''--'F'と'a'です--'f'(すなわち、U+0030U+0039、U+0041U+0046、およびU+0061U+0066)。 BIT STRING値における8ビットの各グループは最初のビットが最も重要である1組の16進数字としてコード化されます。 16進数字の奇数は受入れられません。 キャラクタ'a'--'f'(すなわち、U+0061u+0066)SHALL NOT、BIT STRING価値のCRXERコード化では、使用されてください。 16進数字ストリングが使用されているなら、同封要素の[属性]は[地方名]「形式」、[名前空間名]「つぼ:ietf:params:xml:ナノ秒: asnx」、および[値を正常にします]「十六進法」(すなわち、asnx: 形式=「十六進法」)がある属性項目を含まなければなりません。 属性項目の[接頭語]はセクション6.2.3で.1に指定されるように断固としています。
Aside: The hexadecimal digit string is intended to conform to the
lexical representation of the XML Schema [XSD2] hexBinary data
type.
傍らに: 16進数字ストリングがXML Schema[XSD2]hexBinaryデータ型の語彙表示に従うことを意図します。
For a non-canonical RXER encoding, if the preconditions for using a hexadecimal digit string are satisfied, then a hexadecimal digit string MAY be used.
その時を16進数字ストリングを使用するための前提条件が満たされているならコード化する正典外のRXERのために、16進数字ストリングは使用されるかもしれません。
A list of bit names is permitted if and only if the BIT STRING type has a NamedBitList and each '1' bit in the BIT STRING value has a corresponding identifier in the NamedBitList.
そして、噛み付いている名前のリストが受入れられる、BIT STRINGタイプがBIT STRINGにNamedBitListと各'1'ビットを持っている場合にだけ、値はNamedBitListに対応する識別子を持っています。
Aside: ASN.1 does not require that an identifier be assigned for
every bit.
傍らに: ASN.1は、識別子があらゆるビットのために割り当てられるのを必要としません。
Legg & Prager Experimental [Page 36] RFC 4910 Robust XML Encoding Rules July 2007
強健な[36ページ]RFC4910XML符号化規則2007年7月に実験的なLeggとプラーガー
A list of bit names is a sequence of names for the '1' bits in the BIT STRING value, in any order, each separated from the next by at least one white space character. If the BitStringType is not subject to a VALUES encoding instruction, then each '1' bit in the BIT STRING value is represented by its corresponding identifier from the NamedBitList. If the BitStringType is subject to a VALUES encoding instruction, then each '1' bit in the BIT STRING value is represented by the replacement name [RXEREI] for its corresponding identifier.
噛み付いている名前のリストはBIT STRING値における'1'ビットで名前の系列です、順不同に、少なくとも1つの余白キャラクタによって次と切り離されたそれぞれ。 BitStringTypeは指示をコード化するVALUESを受けることがないなら、BIT STRING値における各'1'ビットは対応する識別子によってNamedBitListから表されます。 BitStringTypeは指示をコード化するVALUESを受けることがあるなら、交換名[RXEREI]によってBIT STRING値における各'1'ビットは対応する識別子のために表されます。
For a CRXER encoding, if the BIT STRING type has a NamedBitList, then a binary digit string MUST be used, and trailing zero bits MUST be omitted from the binary digit string; else if the number of bits in the BIT STRING value is greater than or equal to 64, and the preconditions for using a hexadecimal digit string are satisfied, then a hexadecimal digit string MUST be used; otherwise, a binary digit string MUST be used.
その時をBIT STRINGタイプがNamedBitListを持っているならコード化するCRXERのために、バイナリー・ディジットストリングを使用しなければなりません、そして、バイナリー・ディジットストリングから引きずっているゼロ・ビットを省略しなければなりません。 ほかに、BIT STRING値における、ビットの数が64以上であり、16進数字ストリングを使用するための前提条件が満たされているなら、16進数字ストリングを使用しなければなりません。 さもなければ、バイナリー・ディジットストリングを使用しなければなりません。
Aside: Because the asnx:format attribute adds an overhead to a
hexadecimal encoding (including a namespace declaration for the
"asnx" prefix), a bit string of less than 64 bits is more
compactly encoded as a binary digit string.
傍らに: asnx: 形式属性が16進コード化("asnx"接頭語のための名前空間宣言を含んでいる)にオーバーヘッドを加えるので、少し、64ビット未満のストリングはバイナリー・ディジットストリングとして、よりコンパクトにコード化されます。
Examples
例
Consider this type definition:
この型定義を考えてください:
BIT STRING { black(0), red(1), orange(2), yellow(3),
green(4), blue(5), indigo(6), violet(7) }
ビット列黒(0)、赤(1)、オレンジ(2)、黄色(3)、緑色(4)、青(5)、藍(6)、すみれ(7)
The content and attributes of each of the following <value>
elements are an RXER encoding of the same abstract value:
それぞれの以下の<値の>要素の内容と属性は同じ抽象的な価値をコード化するRXERです:
<value> green violet orange</value>
<値の>の緑色のすみれ色のオレンジの</価値の>。
<value> 001<!--Orange-->01001 </value>
<値の>001<!--オレンジ-->01001</値の>。
<value xmlns:asnx="urn:ietf:params:xml:ns:asnx"
asnx:format="hex">
29
</value>
<値のxmlns: asnxは「つぼ:ietf:params:xml:ナノ秒: asnx」asnxと等しいです: =をフォーマットしてください、「「>29</値の>」に魔法をかけてください。
<value>00101001</value>
<値の>00101001</値の>。
The final case contains the CRXER encoding of the abstract value.
最終的なケースは抽象的な価値のCRXERコード化を含んでいます。
Legg & Prager Experimental [Page 37] RFC 4910 Robust XML Encoding Rules July 2007
強健な[37ページ]RFC4910XML符号化規則2007年7月に実験的なLeggとプラーガー
6.7.3. BOOLEAN
6.7.3. 論理演算子
For a non-canonical RXER encoding, the character data translation of the BOOLEAN value TRUE is the string "true" or "1", at the encoder's discretion. For a CRXER encoding, the character data translation of the BOOLEAN value TRUE is the string "true".
正典外のRXERコード化かストリングが「本当である」というブール値のTRUEに関するキャラクタデータ変換か「エンコーダの裁量における1インチ」で。 CRXERコード化のために、ブール値のTRUEに関するキャラクタデータ変換は「本当に」ストリングです。
For a non-canonical RXER encoding, the character data translation of the BOOLEAN value FALSE is the string "false" or "0", at the encoder's discretion. For a CRXER encoding, the character data translation of the BOOLEAN value FALSE is the string "false".
正典外のRXERコード化かストリングが「誤っている」というブール値のFALSEに関するキャラクタデータ変換か「エンコーダの裁量における0インチ」で。 CRXERコード化のために、ブール値のFALSEに関するキャラクタデータ変換は「虚偽」ストリングです。
Aside: The RXER encoding of BOOLEAN values is intended to conform
to the lexical representation of the XML Schema [XSD2] boolean
data type.
傍らに: ブール値のRXERコード化がXML Schema[XSD2]論理演算子データ型の語彙表示に従うことを意図します。
Examples
例
The content of each of the following <value> elements is the RXER
encoding of a BOOLEAN value:
それぞれの以下の<値の>要素の内容はブール価値のRXERコード化です:
<value>1</value>
<の値の>の1つの</値の>。
<value>
false
</value>
<値の>の誤った</価値の>。
<value> fal<!-- a pesky comment -->se </value>
<値の>fal<!--やっかいなコメント-->se</価値の>。
6.7.4. ENUMERATED
6.7.4. 列挙されます。
The character data translation of a value of an ENUMERATED type where the EnumeratedType is not subject to a VALUES encoding instruction is the identifier corresponding to the actual value.
EnumeratedTypeは指示をコード化するVALUESを受けることがないENUMERATEDタイプの価値に関するキャラクタデータ変換が実価に対応する識別子です。
Examples
例
Consider this type definition:
この型定義を考えてください:
ENUMERATED { sunday, monday, tuesday,
wednesday, thursday, friday, saturday }
列挙されます。sunday、monday、tuesday、wednesday、thursday、friday、saturday
The content of both of the following <value> elements is the RXER
encoding of a value of the above type:
以下の<値の>要素の両方の内容は上のタイプの価値のRXERコード化です:
Legg & Prager Experimental [Page 38] RFC 4910 Robust XML Encoding Rules July 2007
強健な[38ページ]RFC4910XML符号化規則2007年7月に実験的なLeggとプラーガー
<value>monday</value>
<値の>monday</価値の>。
<value>
thursday
</value>
<値の>thursday</価値の>。
The character data translation of a value of an ENUMERATED type where the EnumeratedType is subject to a VALUES encoding instruction is the replacement name [RXEREI] for the identifier corresponding to the actual value.
EnumeratedTypeは指示をコード化するVALUESを受けることがあるENUMERATEDタイプの価値に関するキャラクタデータ変換が実価に対応する識別子のための交換名[RXEREI]です。
Examples
例
Consider this type definition:
この型定義を考えてください:
[RXER:VALUES ALL CAPITALIZED,
sunday AS "SUNDAY", saturday AS "SATURDAY"]
ENUMERATED { sunday, monday, tuesday,
wednesday, thursday, friday, saturday }
[RXER: VALUES、すべてのCAPITALIZED、「日曜日」、土曜日の「土曜日」としてのsunday AS]、列挙sunday、monday、tuesday、wednesday、thursday、friday、saturday
The content of each of the following <value> elements is the RXER
encoding of a value of the above type:
それぞれの以下の<値の>要素の内容は上のタイプの価値のRXERコード化です:
<value>SUNDAY</value>
<値の>日曜日の</価値の>。
<value>
Monday
</value>
<値の>月曜日の</価値の>。
<value> Tuesday </value>
<値の>火曜日の</価値の>。
6.7.5. GeneralizedTime
6.7.5. GeneralizedTime
The character data translation of a value of the GeneralizedTime type is a date, the letter 'T' (U+0054), a time of day, optional fractional seconds, and an optional time zone.
GeneralizedTimeタイプの価値に関するキャラクタデータ変換は、日付と、文字'T'(U+0054)と、時刻と、任意の断片的な秒と、任意の時間帯です。
The date is two decimal digits representing the century, followed by
two decimal digits representing the year, a hyphen ('-', U+002D), two
decimal digits representing the month, a hyphen ('-', U+002D), and
two decimal digits representing the day.
日付は1日を表す1年を表す2つの10進数字、ハイフン('--'、U+002D)、月を表す2つの10進数字、ハイフン('--'、U+002D)、および2つの10進数字があとに続いた世紀を表す2つの10進数字です。
The time of day is two decimal digits representing the hour, followed
by a colon (':', U+003A), two decimal digits representing the
minutes, a colon (':', U+003A), and two decimal digits representing
the seconds.
時刻がコロンがあとに続いた時間を表す2つの10進数字である、(':'、U+003A) 2つの10進数字が議事録を表すコロン、(':'、U+003A)、そして、秒を表す2つの10進数字。
Note that the hours value "24" is disallowed [X.680].
数時間が評価する注意、「24インチは禁じ[X.680]にされます」。
Legg & Prager Experimental [Page 39] RFC 4910 Robust XML Encoding Rules July 2007
強健な[39ページ]RFC4910XML符号化規則2007年7月に実験的なLeggとプラーガー
A GeneralizedTime value with fractional hours or minutes is first converted to the equivalent time with whole minutes and seconds and, if necessary, fractional seconds.
断片的な時間か数分があるGeneralizedTime値は最初に、全体の分、秒、および必要なら断片的な秒で同等な時間まで変換されます。
The minutes are encoded as "00" if the GeneralizedTime value omits minutes. The seconds are encoded as "00" if the GeneralizedTime value omits seconds.
「値はGeneralizedTimeであるなら数分を何0インチも省略する」とき、議事録がコード化されます。 「値はGeneralizedTimeであるなら秒を何0インチも省略する」とき、秒はコード化されます。
The fractional seconds part is a full stop ('.', U+002E) followed by
zero, one, or more decimal digits (U+0030-U+0039). For a CRXER
encoding, trailing zero digits (U+0030) in the fractional seconds
SHALL be omitted, and the full stop SHALL be omitted if there are no
following digits.
断片的な秒部分が終止符である、('、'、ゼロ、1つ以上の10進数字(U+0030U+0039)でU+002E)は続きました。 断片的な秒SHALLでケタ(U+0030)を全く引きずらないで、コード化するCRXERに関する省略されていて終止符SHALLになってください。次のケタが全くなければ、省略されます。
The time zone, if present, is either the letter 'Z' (U+005A) to
indicate Coordinated Universal Time, a plus sign ('+', U+002B)
followed by a time zone differential, or a minus sign ('-', U+002D)
followed by a time zone differential.
時間帯、存在しているなら、プラスサイン('+'、U+002B)は時間帯のデフ装置を文字'Z'(U+005A)が協定世界時を示すことになってい続けたか、またはマイナス記号('--'、U+002D)は時間帯のデフ装置で従いました。
A time zone differential indicates the difference between local time (the time specified by the preceding date and time of day) and Coordinated Universal Time. Coordinated Universal Time can be calculated from the local time by subtracting the differential.
時間帯のデフ装置は現地時間の違い(前の期日と時刻によって指定された時間)と協定世界時を示します。 現地時間からデフ装置を引き算することによって、協定世界時について計算できます。
For a CRXER encoding, a GeneralizedTime value with a time zone differential SHALL be encoded as the equivalent Coordinated Universal Time, i.e., the time zone will be "Z".
CRXERのために、コード化しています、時間帯の特異なSHALLが同等な協定世界時としてコード化されているGeneralizedTime値、すなわち、時間帯は「Z」でしょう。
A local time GeneralizedTime value is not converted to Coordinated Universal Time for a CRXER encoding. Other canonical ASN.1 encoding rules specify that local times must be encoded as Coordinated Universal Time but do not specify a method to convert a local time to a Coordinated Universal Time. Consequently, canonicalization of local time values is unreliable and applications SHOULD NOT use local time.
現地時間の1時はCRXERコード化のために協定世界時まで変換されませんGeneralizedTimeが、評価する。 他の正準なASN.1符号化規則は、協定世界時として現地時間をコード化しなければならないと指定しますが、協定世界時まで現地時間の1時を変換するメソッドは指定しません。 その結果、現地時間の値のcanonicalizationは頼り無いです、そして、アプリケーションSHOULD NOTは現地時間を使用します。
A time zone differential is encoded as two decimal digits
representing hours, a colon (':', U+003A), and two decimal digits
representing minutes. The minutes are encoded as "00" if the
GeneralizedTime value omits minutes from the time zone differential.
時間帯のデフ装置は何時間も表す2つの10進数字としてコード化されます、コロン、(':'、U+003A)、そして、数分を表す2つの10進数字。 「値はGeneralizedTimeであるなら分間時間帯のデフ装置を何0インチも抜かす」とき、議事録がコード化されます。
Aside: The RXER encoding of GeneralizedTime values is intended to
conform to the lexical representation of the XML Schema [XSD2]
dateTime data type.
傍らに: GeneralizedTime値のRXERコード化がXML Schema[XSD2]dateTimeデータ型の語彙表示に従うことを意図します。
Legg & Prager Experimental [Page 40] RFC 4910 Robust XML Encoding Rules July 2007
強健な[40ページ]RFC4910XML符号化規則2007年7月に実験的なLeggとプラーガー
Examples
例
The content of each of the following <value> elements is the RXER
encoding of a GeneralizedTime value:
それぞれの以下の<値の>要素の内容はGeneralizedTime価値のRXERコード化です:
<value>2004-06-15T12:00:00Z</value>
<値の>2004-06-15T12:00:00Z</価値の>。
<value> 2004-06-15T02:00:00+10:00 </value>
<値の>2004-06-15T02: 00:00+10:00</値の>。
<value>
2004-06-15T12:00:00.5
</value>
<値の>2004-06-15T12: 00:00.5</値の>。
6.7.6. INTEGER
6.7.6. 整数
For a CRXER encoding, the character data translation of a value of an IntegerType is a canonical number string representing the integer value.
CRXERのために、コード化しています、IntegerTypeの価値に関するキャラクタデータ変換は整数値を表す正準な数のストリングです。
A canonical number string is either the digit character '0' (U+0030),
or an optional minus sign ('-', U+002D) followed by a non-zero
decimal digit character (U+0031-U+0039) followed by zero, one, or
more of the decimal digit characters '0' to '9' (U+0030-U+0039).
正準な数のストリングは、ゼロ('9'(U+0030U+0039)への10進数字キャラクタ'0'のより多くのひとり)があとに続いた非ゼロ10進数字キャラクタ(U+0031U+0039)によっていうことになられたケタキャラクタ'0'(U+0030)か任意のマイナス記号('--'、U+002D)のどちらかです。
For a non-canonical RXER encoding, the character data translation of a value of the IntegerType without a NamedNumberList is a number string representing the integer value.
正典外のRXERのために、コード化しています、NamedNumberListのないIntegerTypeの価値に関するキャラクタデータ変換は整数値を表す数のストリングです。
A number string is a sequence of one or more of the decimal digit characters '0' to '9' (U+0030-U+0039), with an optional leading sign, either '+' (U+002B) or '-' (U+002D). Leading zero digits are permitted in a number string for a non-canonical RXER encoding.
数のストリングは'9'(U+0030U+0039)への10進数字キャラクタ'0'のより多くのひとりの系列です、任意の主なサイン'+'(U+002B)か('--'(U+002D)のどちらか)で。 先行ゼロケタは正典外のRXERコード化のために数のストリングで受入れられます。
Aside: The RXER encoding of values of the IntegerType without a
NamedNumberList is intended to conform to the lexical
representation of the XML Schema [XSD2] integer data type.
傍らに: NamedNumberListのないIntegerTypeの値のRXERコード化がXML Schema[XSD2]整数データ型の語彙表示に従うことを意図します。
For a non-canonical RXER encoding, if the IntegerType has a NamedNumberList, and the NamedNumberList defines an identifier for the actual value, and the IntegerType is not subject to a VALUES encoding instruction, then the character data translation of the value is either a number string or the identifier.
その時をIntegerTypeにはNamedNumberListがあって、NamedNumberListが実価のための識別子を定義して、IntegerTypeは指示をコード化するVALUESを受けることがないならコード化する正典外のRXERに関しては、価値に関するキャラクタデータ変換が、数のストリングか識別子のどちらかです。
Examples
例
Consider this type definition:
この型定義を考えてください:
INTEGER { zero(0), one(1) }
整数(0)がない、1つ(1)
Legg & Prager Experimental [Page 41] RFC 4910 Robust XML Encoding Rules July 2007
強健な[41ページ]RFC4910XML符号化規則2007年7月に実験的なLeggとプラーガー
The content of each of the following <value> elements is the RXER
encoding of a value of the above type:
それぞれの以下の<値の>要素の内容は上のタイプの価値のRXERコード化です:
<value>0</value>
<値の>0</値の>。
<value> zero </value>
<値の>ゼロ</値の>。
<value> 2 <!-- This number doesn't have a name. --> </value>
<値の>2<!--この数には、名前がありません。 --></価値の>。
<value>00167</value>
<値の>00167</値の>。
For a non-canonical RXER encoding, if the IntegerType is subject to a VALUES encoding instruction (it necessarily must have a NamedNumberList) and the NamedNumberList defines an identifier for the actual value, then the character data translation of the value is either a number string or the replacement name [RXEREI] for the identifier.
その時をIntegerTypeは指示をコード化するVALUESを受けることがあって(それは必ずNamedNumberListを持たなければなりません)、NamedNumberListが実価のための識別子を定義するならコード化する正典外のRXERに関しては、価値に関するキャラクタデータ変換は、識別子のための数のストリングか交換名[RXEREI]のどちらかです。
Examples
例
Consider this type definition:
この型定義を考えてください:
[RXER:VALUES ALL UPPERCASED] INTEGER { zero(0), one(1) }
[RXER: すべて大文字された値] 整数(0)がない、1つ(1)
The content of both of the following <value> elements is the RXER
encoding of a value of the above type:
以下の<値の>要素の両方の内容は上のタイプの価値のRXERコード化です:
<value>0</value>
<値の>0</値の>。
<value> ZERO </value>
<値の>ゼロ</値の>。
6.7.7. NULL
6.7.7. ヌル
The character data translation of a value of the NULL type is an empty character string.
NULLタイプの価値に関するキャラクタデータ変換は空の文字列です。
Examples
例
<value/>
<値/>。
<value><!-- Comments don't matter. --></value>
<値の><!--コメントは重要ではありません。 --></価値の>。
<value></value>
<値の></価値の>。
The final case is the CRXER encoding.
最終的なケースはCRXERコード化です。
Legg & Prager Experimental [Page 42] RFC 4910 Robust XML Encoding Rules July 2007
強健な[42ページ]RFC4910XML符号化規則2007年7月に実験的なLeggとプラーガー
6.7.8. ObjectDescriptor
6.7.8. ObjectDescriptor
A value of the ObjectDescriptor type is translated according to the GraphicString type.
GraphicStringタイプに従って、ObjectDescriptorタイプの値は翻訳されます。
6.7.9. OBJECT IDENTIFIER and RELATIVE-OID
6.7.9. オブジェクト識別子と親類-OID
The character data translation of a value of the OBJECT IDENTIFIER or
RELATIVE-OID type is a full stop ('.', U+002E) separated list of the
object identifier components of the value.
OBJECT IDENTIFIERかRELATIVE-OIDタイプの価値に関するキャラクタデータ変換が終止符である、('、'、U+002E)は価値のオブジェクト識別子の部品のリストを切り離しました。
Each object identifier component is translated as a non-negative number string. A non-negative number string is either the digit character '0' (U+0030), or a non-zero decimal digit character (U+0031-U+0039) followed by zero, one, or more of the decimal digit characters '0' to '9' (U+0030-U+0039).
それぞれのオブジェクト識別子の部品は非負数ストリングとして翻訳されます。 非負数ストリングは、ゼロ('9'(U+0030U+0039)への10進数字キャラクタ'0'のより多くのひとり)がいうことになったケタキャラクタ'0'(U+0030)か非ゼロ10進数字キャラクタ(U+0031U+0039)のどちらかです。
Examples
例
The content of each of the following <value> elements is the RXER
encoding of an OBJECT IDENTIFIER value:
それぞれの以下の<値の>要素の内容はOBJECT IDENTIFIER価値のRXERコード化です:
<value>2.5.6.0</value>
<価値>2.5.6の.0</値の>。
<value>
2.5.4.10
</value>
<価値>2.5.4の.10</値の>。
<value> 2.5.4.3 <!-- commonName --> </value>
<価値>2.5.4の.3<!--commonName--></価値の>。
6.7.10. OCTET STRING
6.7.10. 八重奏ストリング
The character data translation of a value of the OCTET STRING type is the hexadecimal digit string representation of the octets.
OCTET STRINGタイプの価値に関するキャラクタデータ変換は八重奏の16進数字ストリング表現です。
The octets are encoded in order from the first octet to the last octet. Each octet is encoded as a pair of the hexadecimal digit characters '0'-'9', 'A'-'F', and 'a'-'f' (i.e., U+0030-U+0039, U+0041-U+0046, and U+0061-U+0066) where the first digit in the pair corresponds to the four most significant bits of the octet. An odd number of hexadecimal digits is not permitted. The characters 'a'- 'f' (i.e., U+0061-U+0066) SHALL NOT be used in the CRXER encoding of an OCTET STRING value.
八重奏は最初の八重奏から最後の八重奏まで整然とした状態でコード化されます。 各八重奏は16進数字キャラクタの'0'--'9'、''--'F'、および'a'の1組としてコード化されます--組における最初のケタが八重奏の4つの最上位ビットに対応する'f'(すなわち、U+0030U+0039、U+0041U+0046、およびU+0061U+0066)。 16進数字の奇数は受入れられません。 キャラクタ'a'--'f'(すなわち、U+0061u+0066)SHALL NOT、OCTET STRING価値のCRXERコード化では、使用されてください。
Aside: The RXER encoding of OCTET STRING values is intended to
conform to the lexical representation of the XML Schema [XSD2]
hexBinary data type.
傍らに: OCTET STRING値のRXERコード化がXML Schema[XSD2]hexBinaryデータ型の語彙表示に従うことを意図します。
Legg & Prager Experimental [Page 43] RFC 4910 Robust XML Encoding Rules July 2007
強健な[43ページ]RFC4910XML符号化規則2007年7月に実験的なLeggとプラーガー
Examples
例
The content of each of the following <value> elements is the RXER
encoding of an OCTET STRING value:
それぞれの以下の<値の>要素の内容はOCTET STRING価値のRXERコード化です:
<value>27F69A0300</value>
<値の>27F69A0300</価値の>。
<value>
efA03bFF
</value>
<値の>efA03bFF</価値の>。
6.7.11. QName
6.7.11. QName
The character data translation of a value of the QName type (Section 4.5) is a qualified name conforming to the QName production of Namespaces in XML 1.0 [XMLNS10].
QNameタイプ(セクション4.5)の価値に関するキャラクタデータ変換はXML1.0[XMLNS10]でのNamespacesのQName生産に従う適切な名前です。
The local part (i.e., LocalPart) of the qualified name SHALL be the value of the local-name component of the QName value.
適切の地方の部分(すなわち、LocalPart)はSHALLを命名します。QName価値の地方名コンポーネントの値になってください。
If the namespace-name component of the QName value is absent, then the namespace prefix (i.e., Prefix) of the qualified name SHALL be absent; otherwise, the namespace prefix is determined as specified in Section 6.7.11.1 using the value of the namespace-name component of the QName value as the namespace name.
QName価値の名前空間名のコンポーネントが欠けるなら、名前空間は休んだ状態で存在という適切な名前SHALLの(すなわち、Prefix)を前に置きます。 さもなければ、名前空間接頭語は、名前空間名としてセクション6.7.11.1使用における、QName価値の名前空間名のコンポーネントの値を指定するので、決定しています。
6.7.11.1. Namespace Prefixes for Qualified Names
6.7.11.1. 適切な名前のための名前空間接頭語
This section describes how the namespace prefix of a qualified name is determined given the namespace name to which the namespace prefix must map.
このセクションは名前空間接頭語が写像されなければならない名前空間名を考えて、適切な名前の名前空間接頭語がどう決定しているかを説明します。
For a CRXER encoding, the namespace prefix of the qualified name is any unused non-canonical namespace prefix unless the [in-scope namespaces] property of the enclosing element item contains a namespace item with a [namespace name] that matches the namespace name. In that case, the [prefix] of that namespace item SHALL be used as the namespace prefix of the qualified name.
CRXERのために、コード化しています、同封の要素の品目の[範囲の名前空間]特性が名前空間が命名するその[名前空間名]マッチがある名前空間項目を含んでいない場合、適切な名前の名前空間接頭語はあらゆる未使用の正典外の名前空間接頭語です。 その場合、[前に置きます] その名前空間項目SHALLでは、適切な名前の名前空間接頭語として使用されてください。
Aside: If the qualified name appears in the [normalized value] of
an attribute item, then the enclosing element item is the
[owner element] for that attribute item.
傍らに: 適切な名前が中に現れる、属性項目の[正常にされた値]、次に、同封の要素の品目がそう、[所有者要素] それに関しては、項目を結果と考えてください。
For a non-canonical RXER encoding, the namespace prefix of the qualified name is any unused namespace prefix unless the [in-scope namespaces] property of the enclosing element item contains a namespace item with the same [namespace name] as the element item. In that case, the [prefix] of that namespace item MAY be used as the
正典外のRXERのために、コード化しています、同封の要素の品目の[範囲の名前空間]特性が要素の品目として同じくらいがある名前空間項目[名前空間名]を含んでいない場合、適切な名前の名前空間接頭語はあらゆる未使用の名前空間接頭語です。 その場合、その名前空間項目の[接頭語]は使用されるかもしれません。
Legg & Prager Experimental [Page 44] RFC 4910 Robust XML Encoding Rules July 2007
強健な[44ページ]RFC4910XML符号化規則2007年7月に実験的なLeggとプラーガー
namespace prefix of the qualified name. Note that the [prefix] of a namespace item for the default namespace has no value.
適切な名前の名前空間接頭語。 デフォルト名前空間のための名前空間項目の[接頭語]には値が全くないことに注意してください。
If the namespace prefix of the qualified name is an unused namespace prefix, then a namespace declaration attribute item associating the namespace prefix with the namespace name MUST be added to the [namespace attributes] of the enclosing element item, and a corresponding namespace item MUST be added to the [in-scope namespaces] of the enclosing element item.
適切な名前の名前空間接頭語が未使用の名前空間接頭語であるなら名前空間接頭語を名前空間名に関連づける名前空間宣言属性項目に追加しなければならない、同封の要素の品目、およびa対応する名前空間項目の[名前空間属性]に加えなければならない、同封の要素の品目の[範囲の名前空間。]
6.7.12. REAL
6.7.12. 本当
The character data translation of a value of the REAL type is the character string "0" if the value is positive zero, the character string "-0" if the value is negative zero, the character string "INF" if the value is positive infinity, the character string "-INF" if the value is negative infinity, the character string "NaN" if the value is not a number, or a real number otherwise.
陽のゼロ、キャラクタは値であるならストリングです。レアルタイプの価値に関するキャラクタデータ変換が文字列である、「0インチ、「-値が負のゼロ、キャラクタが値であるなら陽の無限、文字列が値であるなら値が負の無限、文字列であるなら「INF」であるという「INF」「ナン」を結ぶということであるなら、そうでなければ、0インチは、数でなくて、また実数でもありません」。
A real number is the mantissa followed by either the character 'E' (U+0045) or 'e' (U+0065) and the exponent. The character 'e' SHALL NOT be used for a CRXER encoding. If the exponent is zero, then the 'E' or 'e' and exponent MAY be omitted for a non-canonical RXER encoding.
実数は、キャラクタ'E'(U+0045)か'e'(U+0065)のどちらかがあとに続いた仮数と解説者です。 キャラクタ'e'SHALL NOT、CRXERコード化には、使用されてください。 解説者がゼロであるなら、'E'か'e'と解説者が正典外のRXERコード化のために省略されるかもしれません。
The mantissa is a decimal number with an optional leading sign,
either '+' (U+002B) or '-' (U+002D). A decimal number is a sequence
of one or more of the decimal digit characters '0' to '9'
(U+0030-U+0039) optionally partitioned by a single full stop
character ('.', U+002E) representing the decimal point. Multiple
leading zero digits are permitted for a non-canonical RXER encoding.
仮数は任意の主なサイン'+'(U+002B)か('--'(U+002D)のどちらか)がある10進数です。 10進数が単独の終止符キャラクタによって任意に仕切られた'9'(U+0030U+0039)への10進数字キャラクタ'0'のより多くのひとりの系列である、('、'、U+002E) 小数点を表します。 複数の先行ゼロケタが正典外のRXERコード化のために受入れられます。
The exponent is encoded as a number string (see Section 6.7.6).
解説者は数のストリングとしてコード化されます(セクション6.7.6を見てください)。
Aside: The RXER encoding of REAL values is intended to be
compatible with the lexical representation of the XML Schema
[XSD2] double data type, but allows real values outside the set
permitted by double.
傍らに: レアル値のRXERコード化は、XML Schema[XSD2]の二重データ型の語彙表示と互換性があることを意図しますが、二重に受入れられたセットの外に実価を許容します。
For a CRXER encoding:
CRXERコード化のために:
(1) The real number MUST be normalized so that the mantissa has a
single non-zero digit immediately to the left of the decimal
point.
(1) 実数を正常にしなければならないので、仮数には、1非ゼロケタがすぐ小数点の左まであります。
(2) Leading zero digits SHALL NOT be used.
(2) 先行ゼロケタSHALL NOT、使用されてください。
Legg & Prager Experimental [Page 45] RFC 4910 Robust XML Encoding Rules July 2007
強健な[45ページ]RFC4910XML符号化規則2007年7月に実験的なLeggとプラーガー
(3) A leading plus sign SHALL NOT be used in the mantissa or the
exponent.
(3) 主なプラスは中古のコネが仮数か解説者であったならSHALL NOTに署名します。
(4) The fractional part of the mantissa (i.e., that part following
the decimal point) MUST have at least one digit (which may be
'0') and MUST NOT have any trailing zeroes after the first digit.
(4) 仮数(すなわち、小数点に従うその部分)の断片的な部分は、少なくとも1ケタ('0'であるかもしれない)を持たなければならなくて、最初のケタの後に少しの末尾のゼロも持ってはいけません。
(5) The exponent SHALL be present and SHALL be a canonical number
string (see Section 6.7.6).
(5) 解説者SHALL、正準な数がストリングであったならプレゼントとSHALL(セクション6.7.6を見る)になってください。
Examples
例
The content of each of the following <value> elements is the RXER
encoding of a REAL value:
それぞれの以下の<値の>要素の内容はレアル価値のRXERコード化です:
<value>3.14159<!-- pi --></value>
>3.14159<!--パイ--<価値の></価値の>。
<value> 1.0e6 </value>
<値の>1.0e6</価値の>。
<value> INF </value>
<値の>INF</価値の>。
<value>
-01e-06
</value>
<値の>-01e-06</価値の>。
6.7.13. UTCTime
6.7.13. UTCTime
The character data translation of a value of the UTCTime type is a date, the letter 'T' (U+0054), a time of day, and a time zone.
UTCTimeタイプの価値に関するキャラクタデータ変換は、日付と、文字'T'(U+0054)と、時刻と、時間帯です。
The date is two decimal digits representing the year (no century), a
hyphen ('-', U+002D), two decimal digits representing the month, a
hyphen ('-', U+002D), and two decimal digits representing the day.
日付は年(世紀がない)、ハイフン('--'、U+002D)、月を表す2つの10進数字、ハイフン('--'、U+002D)、および1日を表す2つの10進数字を表す2つの10進数字です。
The time of day is two decimal digits representing the hour, followed
by a colon (':', U+003A), two decimal digits representing the
minutes, a colon (':', U+003A), and two decimal digits representing
the seconds.
時刻がコロンがあとに続いた時間を表す2つの10進数字である、(':'、U+003A) 2つの10進数字が議事録を表すコロン、(':'、U+003A)、そして、秒を表す2つの10進数字。
Note that the hours value "24" is disallowed [X.680].
数時間が評価する注意、「24インチは禁じ[X.680]にされます」。
The seconds are encoded as "00" if the UTCTime value omits seconds.
「値はUTCTimeであるなら秒を何0インチも省略する」とき、秒はコード化されます。
The time zone is either the letter 'Z' (U+005A) to indicate
Coordinated Universal Time, a plus sign ('+', U+002B) followed by a
time zone differential, or a minus sign ('-', U+002D) followed by a
time zone differential.
時間帯は協定世界時を示す文字'Z'です(U+005A)、とプラスサイン('+'、U+002B)は時間帯のデフ装置を続けたか、またはマイナス記号('--'、U+002D)は時間帯のデフ装置で従いました。
Legg & Prager Experimental [Page 46] RFC 4910 Robust XML Encoding Rules July 2007
強健な[46ページ]RFC4910XML符号化規則2007年7月に実験的なLeggとプラーガー
A time zone differential indicates the difference between local time (the time specified by the preceding date and time of day) and Coordinated Universal Time. Coordinated Universal Time can be calculated from the local time by subtracting the differential.
時間帯のデフ装置は現地時間の違い(前の期日と時刻によって指定された時間)と協定世界時を示します。 現地時間からデフ装置を引き算することによって、協定世界時について計算できます。
For a CRXER encoding, a UTCTime value with a time zone differential SHALL be encoded as the equivalent Coordinated Universal Time, i.e., the time zone will be "Z".
CRXERのために、コード化しています、時間帯の特異なSHALLが同等な協定世界時としてコード化されているUTCTime値、すなわち、時間帯は「Z」でしょう。
A time zone differential is encoded as two decimal digits
representing hours, a colon (':', U+003A), and two decimal digits
representing minutes.
時間帯のデフ装置は何時間も表す2つの10進数字としてコード化されます、コロン、(':'、U+003A)、そして、数分を表す2つの10進数字。
6.7.14. CHOICE as UNION
6.7.14. 組合としての選択
The chosen alternative of a value of a UNION type corresponds to some NamedType in the UNION type definition (a ChoiceType).
UNIONタイプの価値の選ばれた代替手段はUNION型定義(ChoiceType)でいくらかのNamedTypeに対応しています。
The character data translation of a value of a UNION type is the character data translation of the value of the type of the chosen alternative, i.e., without any kind of encapsulation.
UNIONタイプの価値に関するキャラクタデータ変換は選ばれた代替手段のタイプの価値に関するキャラクタデータ変換です、すなわち、どんな種類のカプセル化なしでも。
Leading and trailing white space characters are not permitted to be added to the character data translation of a value of a UNION type (see Section 6.7); however, this does not preclude such white space being added to the character data translation of the value of the chosen alternative.
主で引きずっている余白キャラクタによってUNIONタイプの価値に関するキャラクタデータ変換に追加されることは許可されていません(セクション6.7を見てください)。 しかしながら、これは選ばれた代替手段の価値に関するキャラクタデータ変換に追加されるそのような余白を排除しません。
The character data translation of a value of a UNION type is necessarily destined for the [children] of an enclosing element item.
UNIONタイプの価値に関するキャラクタデータ変換は同封の要素の品目の[子供]のために必ず運命づけられています。
Aside: This is because the ATTRIBUTE encoding instruction cannot
be applied to a NamedType with a type that is a UNION type.
傍らに: これはUNIONタイプであるタイプで指示をコード化するATTRIBUTEをNamedTypeに適用できないからです。
The chosen alternative can be identified by a member attribute item, i.e., an attribute item with the [local name] "member" and [namespace name] "urn:ietf:params:xml:ns:asnx", added to the [attributes] of the enclosing element item. The [prefix] of this attribute item is determined as specified in Section 6.2.3.1. The [normalized value] of the attribute item is a qualified name for the expanded name of the NamedType (see [RXEREI]) corresponding to the chosen alternative.
すなわち、メンバー属性項目、[地方名]「メンバー」と同封の要素の品目の[属性]に加えられた[名前空間名]「つぼ:ietf:params:xml:ナノ秒: asnx」がある属性項目は選ばれた代替手段を特定できます。 この属性項目の[接頭語]はセクション6.2.3で.1に指定されるように断固としています。 属性項目の[正常にされた値]は選ばれた代替手段に対応するNamedType([RXEREI]を見る)という拡張名前のための適切な名前です。
Aside: It is not possible to associate a namespace name with a
NamedType in a UNION type using the current specification for RXER
encoding instructions. Consequently, the [normalized value] of
the member attribute item will always contain a qualified name
without a namespace prefix.
傍らに: UNIONタイプの指示をコード化するRXERに現在の仕様を使用するNamedTypeの名前空間名を関連づけるのは可能ではありません。 その結果、メンバー属性項目の[正常にされた値]はいつも名前空間接頭語のない適切な名前を含むでしょう。
Legg & Prager Experimental [Page 47] RFC 4910 Robust XML Encoding Rules July 2007
強健な[47ページ]RFC4910XML符号化規則2007年7月に実験的なLeggとプラーガー
For a CRXER encoding, the member attribute item MUST be used, and the [normalized value] of the attribute item MUST be the CRXER translation of the QName value equal to the expanded name.
そして、CRXERのために、コード化しています、メンバー属性項目を使用しなければならない、属性項目の[正常にされた値]は拡張名前と等しいQName価値に関するCRXER翻訳であるに違いありません。
In the absence of a member attribute item, an RXER decoder MUST determine the chosen alternative by considering the alternatives of the choice in the order prescribed below and accepting the first alternative for which the encoding is valid.
メンバー属性項目がないとき、RXERデコーダは、コード化が有効である最初の代替手段を下に定められて、受け入れて、オーダーにおける、選択の代替手段を考えることによって、選ばれた代替手段を決定しなければなりません。
If the UNION encoding instruction has a PrecedenceList, then the alternatives of the ChoiceType referenced by the PrecedenceList are considered in the order identified by that PrecedenceList, then the remaining alternatives are considered in the order of their definition in the ChoiceType. If the UNION encoding instruction does not have a PrecedenceList, then all the alternatives of the ChoiceType are considered in the order of their definition in the ChoiceType.
指示をコード化するUNIONがPrecedenceListを持っているなら、PrecedenceListによって参照をつけられたChoiceTypeの代替手段はそのPrecedenceListによって特定されたオーダーで考えられて、次に、残っている代替手段はChoiceTypeでの彼らの定義の注文で考えられます。 指示をコード化するUNIONがPrecedenceListを持っていないなら、ChoiceTypeのすべての選択肢がChoiceTypeでの彼らの定義の注文で考えられます。
A non-canonical RXER encoder MUST use the member attribute item if an RXER decoder would determine the chosen alternative to be something other than the actual chosen alternative of the CHOICE value being translated; otherwise, the member attribute item MAY be used.
RXERデコーダが、選ばれた代替手段が翻訳されるCHOICE価値の実際の選ばれた代替手段以外の何かであることを決定するなら、正典外のRXERエンコーダはメンバー属性項目を使用しなければなりません。 さもなければ、メンバー属性項目は使用されるかもしれません。
Examples
例
Consider this type definition:
この型定義を考えてください:
[RXER:UNION PRECEDENCE serialNumber] CHOICE {
name [0] IA5String,
serialNumber [1] INTEGER
}
[RXER: 組合先行serialNumber] 選択名前[0]IA5String、serialNumber[1]INTEGER
In the absence of a member attribute, an RXER decoder would first
consider whether the received encoding was a valid serialNumber
(an INTEGER) before considering whether it was a valid name (an
IA5String).
メンバー属性がないとき、RXERデコーダは、最初に、それが妥当な名前(IA5String)であったかどうか考える前に容認されたコード化が有効なserialNumber(INTEGER)であったかどうか考えるでしょう。
The content and attributes of each of the following <value>
elements are the RXER encoding of a value of the above type:
それぞれの以下の<値の>要素の内容と属性は上のタイプの価値のRXERコード化です:
<value>Bob</value>
<値の>ボブ</価値の>。
<value xmlns:asnx="urn:ietf:params:xml:ns:asnx"
asnx:member="name">Alice</value>
<値のxmlns: asnxが「つぼ:ietf:params:xml:ナノ秒: asnx」asnx: メンバー=と等しい、「「>アリス</価値の>」を命名してください。
<value>
<!-- Don't have a name for this one! --> 344
</value>
<値の><!--これのための名前を持たないでください! -->344</値の>。
Legg & Prager Experimental [Page 48] RFC 4910 Robust XML Encoding Rules July 2007
強健な[48ページ]RFC4910XML符号化規則2007年7月に実験的なLeggとプラーガー
<value xmlns:asnx="urn:ietf:params:xml:ns:asnx"
asnx:member="name"><!-- A strange name. -->100</value>
<値のxmlns: asnxが「つぼ:ietf:params:xml:ナノ秒: asnx」asnx: メンバー=と等しい、「名前、「><!--奇妙な名前、」 -->100</値の>。
The member attribute is required in the final case to prevent the
value being interpreted as a serialNumber.
メンバー属性が、値がserialNumberとして解釈されるのを防ぐのに最終的な場合で必要です。
If the UNION (i.e., CHOICE) type is extensible [X.680], then an application MUST accept and be prepared to re-encode (using the same encoding rules) any unknown extension in received encoded values of the type. An unknown extension in a value of a UNION type (an unknown alternative) takes the form of an unknown name in the [normalized value] of the member attribute and/or character data in the [children] of the enclosing element item that do not conform to any of the known alternatives.
UNION(すなわち、CHOICE)タイプが広げることができるなら[X.680]、アプリケーションは受け入れて、タイプの容認されたコード化された値におけるあらゆる未知の拡大を再コード化するように(同じ符号化規則を使用します)準備しなければなりません。 UNIONタイプ(未知の代替手段)の値における未知の拡大が未知の名前のフォームを見て取る、[値を正常にします] 知られている代替手段のいずれにも従わない同封の要素の品目の[子供]のメンバー属性、そして/または、キャラクタデータについて。
To enable re-encoding of an unknown alternative, it is necessary to retain the [normalized value] of the member attribute, if present, and the [children] property of the enclosing element item.
未知の代替手段の再コード化を可能にするなら、保有するのに必要である、メンバー属性の[正常にされた値。]プレゼントと、同封の要素の品目の[子供]の特性であるなら
The character data for an unknown alternative may contain qualified names that depend on the [in-scope namespaces] of the enclosing element item for their interpretation. Therefore, semantically faithful re-encoding of an unknown alternative may require reproduction of at least some part of the [in-scope namespaces] of the enclosing element item. The problem is deciding which of the namespace items are actually needed. In the absence of type information, it is not possible to discern whether anything that syntactically resembles a qualified name in the character data of the enclosing element item actually is a qualified name. The simplest approach is to retain all the namespace items from the [in-scope namespaces] of the enclosing element item and output them as namespace declaration attribute items in the [namespace attributes] of the enclosing element item when re-encoding the unknown alternative. At best, an application can omit the namespace items that do not define the namespace prefix of any potential qualified name.
未知の代替手段のためのキャラクタデータがよる適切な名前を含むかもしれない、彼らの解釈のための同封の要素の品目の[範囲の名前空間。] 未知の代替手段のしたがって、意味的に忠実な再コード化が少なくとも何らかの部分の再現に要求するかもしれない、同封の要素の品目の[範囲の名前空間。] 問題は、名前空間項目のどれが実際に必要であるかを決めています。 タイプ情報がないとき、シンタクス上同封の要素の品目に関するキャラクタデータの適切な名前に類似している何かも実際に適切な名前であるかどうかも明察するのは可能ではありません。 最も簡単なアプローチがすべての名前空間項目を保有することになっている、同封の要素の品目と出力の[範囲の名前空間]、中の名前空間宣言属性項目としてのそれら、同封の要素の品目の[名前空間属性]、未知の代替手段を再コード化するとき。 せいぜい、アプリケーションはどんな潜在的適切な名前の名前空間接頭語も定義しない名前空間項目を省略できます。
An application MUST retain the namespace items in the [in-scope namespaces] of the enclosing element item that define the namespace prefixes of all the potential qualified names in the [children] of the enclosing element item. Other namespace items in the [in-scope namespaces] of the enclosing element item MAY be retained. The effect of these retained namespace items on the [namespace attributes] and [in-scope namespaces] of the enclosing element item when re-encoding is considered in Section 6.2.2.1.
アプリケーションが名前空間項目を保有しなければならない、すべての可能性の接頭語が資格を与えた名前空間を定義する同封の要素の品目の[範囲の名前空間]が中で同封の要素の品目の[子供]を命名します。 中の他の名前空間項目、[範囲の名前空間] 同封では、要素の品目は保有されるかもしれません。 これらの効果が名前空間項目を保有した、再コード化がセクション6.2.2で.1に考えられる同封の要素の品目の[名前空間属性]と[範囲の名前空間]
Legg & Prager Experimental [Page 49] RFC 4910 Robust XML Encoding Rules July 2007
強健な[49ページ]RFC4910XML符号化規則2007年7月に実験的なLeggとプラーガー
Aside: The context attribute (Section 6.8.8) is not added to the
[attributes] of the enclosing element item when re-encoding an
unknown alternative since the type of a NamedType in a UNION type
cannot be the Markup type.
傍らに: UNIONのNamedTypeのタイプがタイプするので未知の代替手段を再コード化するのが、Markupタイプであるはずがないときに、文脈属性(セクション6.8.8)は同封の要素の品目の[属性]に加えられません。
6.7.15. SEQUENCE OF as LIST
6.7.15. 系列、リスト
The character data translation of a value of a LIST type (a SEQUENCE OF NamedType) is the concatenation of the character data translations of the component values, i.e., the abstract values of the type of the NamedType, each separated from the next by at least one white space character. For a CRXER encoding, separating white space MUST be exactly one space character (U+0020).
LISTタイプ(SEQUENCE OF NamedType)の価値に関するキャラクタデータ変換は成分値に関するキャラクタデータ変換の連結、すなわち、NamedType(少なくとも1つの余白キャラクタによって次と切り離されたそれぞれ)のタイプの抽象的な値です。 CRXERに関しては、コード化していて、分離している余白はまさに1つの間隔文字であるに違いありません(U+0020)。
Example
例
Consider this type definition:
この型定義を考えてください:
[LIST] SEQUENCE OF timeStamp GeneralizedTime
タイムスタンプGeneralizedTimeの[リスト]系列
The content of the following <value> element is the RXER encoding
of a value of the above type:
以下の<値の>要素の内容は上のタイプの価値のRXERコード化です:
<value>
2004-06-15T12:14:56Z
2004-06-15T12:18:13Z
2004-06-15T01:00:25Z
</value>
<値の>2004-06-15T12:14:56Z2004-06-15T12:18:13Z2004-06-15T01:00:25Z</価値の>。
6.8. Combining Types
6.8. タイプを結合します。
The encoding of a value of an ASN.1 combining type (except a UNION or LIST type) typically has element content.
タイプ(UNIONかLISTタイプを除いた)を結合するASN.1の価値のコード化には、要素含有量が通常あります。
The Infoset translation of a value of a specific ASN.1 combining type (excluding a UNION or LIST type) contains zero or more attribute items to be added to the [attributes] of the enclosing element item and zero or more element items to be added to the [children] of the enclosing element item. These translations are described in Sections 6.8.1 to 6.8.7.
タイプ(UNIONを除くか、LISTがタイプする)を結合する特定のASN.1の価値に関するInfoset翻訳がゼロを含んでいるか、または以上は、同封の要素の品目の[子供]に加えられるために同封の要素の品目とゼロか、より多くの要素の品目の[属性]に加えられるために項目を結果と考えます。 これらの翻訳はセクション6.8で.1〜6.8に.7に説明されます。
For a non-canonical RXER encoding, white space character items MAY be added to the [children] of the enclosing element item (before or after any other items).
正典外のRXERに関しては、コード化していて、白い間隔文字項目は同封の要素の品目(いかなる他の項目の前または後にも)の[子供]に加えられるかもしれません。
Legg & Prager Experimental [Page 50] RFC 4910 Robust XML Encoding Rules July 2007
強健な[50ページ]RFC4910XML符号化規則2007年7月に実験的なLeggとプラーガー
For a CRXER encoding, a character item with the [character code] U+000A (a line feed) MUST be inserted immediately before each element item in the [children] of the enclosing element item. No other white space character items are permitted to be added to the [children] of the enclosing element item.
CRXERのために、コード化しています、それぞれの要素の品目の直前同封の要素の品目の[子供]で[キャラクタコード]U+000A(改行)があるキャラクタ商品を挿入しなければなりません。 他の余白キャラクタ項目によって全く同封の要素の品目の[子供]に加えられることは許可されていません。
Aside: Without the single line feed character before each child
element, a typical CRXER encoding would be a single, very long
line.
傍らに: それぞれの子供要素の前のただ一つの改行文字がなければ、典型的なCRXERコード化は単一の、そして、非常に長い系列でしょう。
6.8.1. CHARACTER STRING
6.8.1. 文字列
A value of the unrestricted CHARACTER STRING type is translated according to the corresponding SEQUENCE type defined in Clause 40.5 of X.680 [X.680].
X.680[X.680]のClause40.5で定義された対応するSEQUENCEタイプに従って、無制限なCHARACTER STRINGタイプの値は翻訳されます。
6.8.2. CHOICE
6.8.2. 選択
The chosen alternative of a value of a CHOICE type corresponds to, and is a value of (see Section 6), some NamedType in the CHOICE type definition.
タイプが相当するCHOICEの価値の代替手段を選んで、値である、(セクション6)(CHOICE型定義におけるいくらかのNamedType)を見てください。
The translation of a value of a CHOICE type other than the Markup type or a UNION type (see Section 6.7.14) is the translation of the value of the NamedType corresponding to the actual chosen alternative.
Markupタイプ以外のCHOICEタイプかUNIONタイプ(セクション6.7.14を見る)の価値に関する翻訳は実際の選ばれた代替手段に対応するNamedTypeの価値に関する翻訳です。
Examples
例
Consider this type definition:
この型定義を考えてください:
CHOICE {
name [0] IA5String,
serialNumber [1] INTEGER
}
選択名前[0]IA5String、serialNumber[1]INTEGER
The content of each of the following <value> elements is the RXER
encoding of a value of the above type:
それぞれの以下の<値の>要素の内容は上のタイプの価値のRXERコード化です:
<value><name>Bob</name></value>
<値の><名前>ボブ</名の></価値の>。
<value>
<name>Alice</name>
</value>
<値の><名前>アリス</名の></価値の>。
Legg & Prager Experimental [Page 51] RFC 4910 Robust XML Encoding Rules July 2007
強健な[51ページ]RFC4910XML符号化規則2007年7月に実験的なLeggとプラーガー
<value>
<!-- Don't have a name for this one! -->
<serialNumber>
344
</serialNumber>
</value>
<値の><!--これのための名前を持たないでください! --><serialNumber>344</serialNumber></価値の>。
<value>
<!-- A strange name. -->
<name>100</name>
</value>
<値の><!--奇妙な名前。 --><名前>100</名前></価値の>。
If the CHOICE type is extensible [X.680], then an application MUST accept, and be prepared to re-encode (in RXER), any attribute item or child element item with a name that is not recognized (see Section 6.8.8).
CHOICEタイプが広げることができるなら[X.680]、アプリケーションは受け入れて、認識されない名前でどんな再エンコード(RXERの)や、属性項目やまたは子供要素の品目にも準備しなければなりません(セクション6.8.8を見てください)。
6.8.3. EMBEDDED PDV
6.8.3. 埋め込まれたPDV
A value of the EMBEDDED PDV type is translated according to the corresponding SEQUENCE type defined in Clause 33.5 of X.680 [X.680].
X.680[X.680]のClause33.5で定義された対応するSEQUENCEタイプに従って、EMBEDDED PDVタイプの値は翻訳されます。
6.8.4. EXTERNAL
6.8.4. 外部
A value of the EXTERNAL type is translated according to the corresponding SEQUENCE type defined in Clause 8.18.1 of X.690 [X.690].
Clauseで定義された対応するSEQUENCEタイプに従ってEXTERNALタイプの値が翻訳される、8.18、.1、X.690[X.690]について。
6.8.5. INSTANCE OF
6.8.5. インスタンス
A value of the INSTANCE OF type is translated according to the corresponding SEQUENCE type defined in Annex C of X.681 [X.681].
X.681[X.681]のAnnex Cで定義された対応するSEQUENCEタイプに従って、INSTANCE OFタイプの値は翻訳されます。
6.8.6. SEQUENCE and SET
6.8.6. 系列とセット
Each component value of a value of a SEQUENCE or SET type corresponds to, and is a value of (see Section 6), some NamedType in the SEQUENCE or SET type definition.
タイプが相当するSEQUENCEかSETの価値のそれぞれの成分値、値である、(セクション6)(SEQUENCEかSET型定義におけるいくらかのNamedType)を見てください。
A value of a SEQUENCE or SET type, other than the QName type (Section 4.5), is translated by translating in turn each component value actually present in the SEQUENCE or SET value and adding the resulting attribute items and/or element items to the [attributes] and/or [children] of the enclosing element item. Attribute items may be added to the [attributes] of the enclosing element item in any order. Element items resulting from the translation of component
SEQUENCEの値かQNameタイプ以外のSETタイプ(セクション4.5)が、順番に実際にSEQUENCEの現在のそれぞれの成分値かSET値を翻訳して、同封の要素の品目の[属性]、そして/または、[子供]に結果として起こる属性項目、そして/または、要素の品目を加えることによって、翻訳されます。 属性項目は順不同な同封の要素の品目の[属性]に加えられるかもしれません。 コンポーネントに関する翻訳から生じる要素の品目
Legg & Prager Experimental [Page 52] RFC 4910 Robust XML Encoding Rules July 2007
強健な[52ページ]RFC4910XML符号化規則2007年7月に実験的なLeggとプラーガー
values MUST be appended to the [children] of the enclosing element item in the order of the component values' corresponding NamedType definitions in the SEQUENCE or SET type definition.
SEQUENCEかSET型定義における、成分値の対応するNamedType定義の注文で同封の要素の品目の[子供]に値を追加しなければなりません。
Aside: In the case of the SET type, this is a deliberate departure
from BER [X.690], where the components of a SET can be encoded in
any order.
傍らに: SETタイプの場合では、これはBER[X.690]からの慎重な出発です。そこでは、順不同にSETの部品をコード化できます。
If a DEFAULT value is defined for a NamedType and the value of the NamedType is the same as the DEFAULT value, then the translation of the value of the NamedType SHALL be omitted for a CRXER encoding and MAY be omitted for a non-canonical RXER encoding.
DEFAULT値がNamedTypeのために定義されて、NamedTypeの値がDEFAULTが評価するのと同じであるなら、NamedType SHALLの価値に関する翻訳は、CRXERコード化のために省略されて、正典外のRXERコード化のために省略されるかもしれません。
Examples
例
Consider this type definition:
この型定義を考えてください:
SEQUENCE {
name [0] IA5String OPTIONAL,
partNumber [1] INTEGER,
quantity [2] INTEGER DEFAULT 0
}
系列[0]IA5String OPTIONAL、partNumber[1]INTEGERを量[2]INTEGER DEFAULT0と命名してください。
The content of each of the following <value> elements is the RXER
encoding of a value of the above type:
それぞれの以下の<値の>要素の内容は上のタイプの価値のRXERコード化です:
<value>
<partNumber>23</partNumber>
<!-- The quantity defaults to zero. -->
</value>
<値の><partNumber>23</partNumber><!--量はゼロをデフォルトとします。 --></価値の>。
<value>
<name>chisel</name>
<partNumber> 37 </partNumber>
<quantity> 0 </quantity>
</value>
<値の><名前>のみの</名の><partNumber>37</partNumber><量>0の</量の></価値の>。
<value>
<!-- The name component is optional. -->
<partNumber>1543</partNumber>
<quantity>29</quantity>
</value>
<値の><!--名前コンポーネントは任意です。 --1543年の><partNumber></partNumber><量>29の</量の></価値の>。
If the SEQUENCE or SET type is extensible [X.680], then an application MUST accept, and be prepared to re-encode (in RXER), any attribute item or child element item with a name that is not recognized (see Section 6.8.8).
SEQUENCEかSETタイプが広げることができるなら[X.680]、アプリケーションは受け入れて、認識されない名前でどんな再エンコード(RXERの)や、属性項目やまたは子供要素の品目にも準備しなければなりません(セクション6.8.8を見てください)。
Legg & Prager Experimental [Page 53] RFC 4910 Robust XML Encoding Rules July 2007
強健な[53ページ]RFC4910XML符号化規則2007年7月に実験的なLeggとプラーガー
6.8.7. SEQUENCE OF and SET OF
6.8.7. 系列、セットされます。
Each component value of a value of a type that is a SET OF NamedType or a SEQUENCE OF NamedType corresponds to, and is a value of (see Section 6), the NamedType in the type definition.
SET OF NamedTypeであるタイプかSEQUENCE OF NamedTypeの価値の値が相当する各コンポーネント、値である、(セクション6)(型定義におけるNamedType)を見てください。
A value of a type that is a SET OF NamedType, or a SEQUENCE OF NamedType other than a LIST type (see Section 6.7.15), is translated by adding the translation of each value of the NamedType to the [children] of the enclosing element item.
SET OF NamedTypeであるタイプの値、またはLISTタイプ(セクション6.7.15を見る)以外のSEQUENCE OF NamedTypeが、同封の要素の品目の[子供]にNamedTypeのそれぞれの価値に関する翻訳を加えることによって、翻訳されます。
Aside: An ATTRIBUTE encoding instruction cannot appear in the
component type for a SEQUENCE OF or SET OF type, so there are no
attribute items to add to the [attributes] of the enclosing
element item.
傍らに: 指示をコード化するATTRIBUTEがSEQUENCE OFに関してコンポーネント型に現れることができないので、SET OFはタイプして、同封の要素の品目の[属性]に加える属性項目が全くありません。
If the type is a SEQUENCE OF NamedType, then the values of the NamedType are translated in the order in which they appear in the value of the type.
タイプがSEQUENCE OF NamedTypeであるなら、NamedTypeの値はそれらがタイプの値に現れるオーダーで翻訳されます。
For a non-canonical RXER encoding, if the type is a SET OF NamedType, then the values of the NamedType may be translated in any order.
その時をタイプがSET OF NamedTypeであるならコード化する正典外のRXERに関しては、NamedTypeの値は順不同に翻訳されるかもしれません。
For a CRXER encoding, if the type is a SET OF NamedType, then the values of the NamedType MUST be translated in ascending order where the order is determined by comparing the octets of their CRXER encodings (which will be UTF-8 encoded character strings; see Section 6.12.2). A shorter encoding is ordered before a longer encoding that is identical up to the length of the shorter encoding.
その時をタイプがSET OF NamedTypeであるならコード化するCRXERに関しては、昇順に順番がそれらのCRXER encodingsの八重奏を比較することによって決定する(どれがUTF-8になるかが文字列をコード化しました; セクション6.12.2を見てください)ところでNamedTypeの値を翻訳しなければなりません。 より短いコード化は、より短いコード化の長さまで同じより長いコード化の前に命令されます。
Examples
例
Consider this type definition:
この型定義を考えてください:
SEQUENCE OF timeStamp GeneralizedTime
タイムスタンプGeneralizedTimeの系列
The content of the following <value> element is the RXER encoding
of a value of the above type:
以下の<値の>要素の内容は上のタイプの価値のRXERコード化です:
<value>
<timeStamp>2004-06-15T12:14:56Z</timeStamp>
<timeStamp>2004-06-15T12:18:13Z</timeStamp>
<timeStamp>
2004-06-15T01:00:25Z
</timeStamp>
</value>
<値の><タイムスタンプ>2004-06-15T12:14:56Z</タイムスタンプ><タイムスタンプ>2004-06-15T12:18:13Z</タイムスタンプ><タイムスタンプ>2004-06-15T01:00:25Z</タイムスタンプ></価値の>。
Legg & Prager Experimental [Page 54] RFC 4910 Robust XML Encoding Rules July 2007
強健な[54ページ]RFC4910XML符号化規則2007年7月に実験的なLeggとプラーガー
Consider this type definition (also see Section 6.6):
この型定義を考えてください(また、セクション6.6を見てください):
SEQUENCE OF INTEGER
整数の系列
The content of the following <value> element is the RXER encoding
of a value of the above type:
以下の<値の>要素の内容は上のタイプの価値のRXERコード化です:
<value>
<item>12</item>
<item>
9
</item>
<item> 7 <!-- A prime number. --></item>
</value>
<値の><項目>12</項目><項目>9</項目><項目>7<!--素数。 -->の</品目></価値の>。
6.8.8. Extensible Combining Types
6.8.8. 広げることができる結合はタイプします。
An application must accept and be prepared to re-encode (using the same encoding rules) any unknown extension appearing in the encoding of a value of an extensible CHOICE, SEQUENCE, or SET type. An unknown extension in a value of an extensible combining type (except UNION types) takes the form of unknown element and/or attribute items. Section 6.8.8.1 describes the processing of unknown element items and Section 6.8.8.2 describes the processing of unknown attribute items.
アプリケーションは受け入れて、広げることができるCHOICE、SEQUENCE、またはSETタイプの価値のコード化に現れるあらゆる未知の拡大を再コード化するように(同じ符号化規則を使用します)準備しなければなりません。 広げることができる結合タイプ(UNIONタイプを除いた)の値における未知の拡大は未知の要素、そして/または、属性項目 .1が処理について説明するセクション6.8.8の形を取ります。未知の要素の品目とセクション6.8 .8 .2 未知の属性項目の処理について説明します。
An application cannot produce a canonical encoding if an abstract value contains unknown extensions. However, the method for re-encoding unknown extensions does not prevent a receiving application with knowledge of the extension from producing the correct canonical encoding.
抽象的な値が未知の拡大を含んでいるなら、アプリケーションは正準なコード化を生産できません。 しかしながら、未知の拡大を再コード化するためのメソッドは、拡大に関する知識による受信アプリケーションが正しい正準なコード化を生産するのを防ぎません。
6.8.8.1. Unknown Elements in Extensions
6.8.8.1. 拡大での未知のElements
To enable re-encoding of an unknown element item it is necessary to retain the [prefix], [local name], [attributes], [namespace attributes], and [children] properties of the element item.
未知の要素の品目の再コード化を可能にするために、要素の品目の[接頭語]、[地方名]、[属性]、[名前空間属性]、および[子供]の特性を保有するのが必要です。
Definition (inherited namespace item): An inherited namespace item is a namespace item in the [in-scope namespaces] of an element item for which there is no corresponding namespace declaration attribute item in the [namespace attributes] of the element item.
定義(名前空間項目を引き継ぎます): 引き継いでいる名前空間項目が中の名前空間項目である、中にどんな対応する名前空間宣言属性項目もない要素の品目の[範囲の名前空間]、要素の品目の[名前空間属性。]
The content and attributes of an unknown element item may contain qualified names whose interpretation depends on inherited namespace items. Semantically faithful re-encoding of the unknown item may require reproduction of at least some of the inherited namespace
未知の要素の品目の内容と属性は解釈が引き継いでいる名前空間項目による適切な名前を含むかもしれません。未知の項目の意味的に忠実な再コード化は少なくとも引き継いでいる名前空間のいくつかの再現を必要とするかもしれません。
Legg & Prager Experimental [Page 55] RFC 4910 Robust XML Encoding Rules July 2007
強健な[55ページ]RFC4910XML符号化規則2007年7月に実験的なLeggとプラーガー
items. The problem is deciding which of the inherited namespace items are actually needed. Qualified names as the names of elements and attributes are easily recognized, but in the absence of type information it is not possible to discern whether anything that syntactically resembles a qualified name in the value of an attribute or the character data of an element actually is a qualified name.
項目 問題は、引き継いでいる名前空間項目のどれが実際に必要であるかを決めています。 要素と属性の名前としての適切な名前は容易に認識されますが、タイプ情報がないとき、シンタクス上属性の値か要素に関するキャラクタデータの適切な名前に類似している何かも実際に適切な名前であるかどうかも明察するのは可能ではありません。
The simplest approach is to retain all the inherited namespace items and output corresponding namespace declaration attribute items in the [namespace attributes] of the unknown element item when re-encoding the element item. At best, an application can omit the inherited namespace items that do not define the namespace prefix of any definite or potential qualified name, though this requires examining the content and attributes of the unknown extension.
最も簡単なアプローチがすべての引き継いでいる名前空間項目を保有して、対応する名前空間宣言属性項目を出力することになっている、未知の要素の品目の[名前空間属性]、要素の品目を再コード化するとき。 せいぜい、アプリケーションはどんな明確であるか潜在的の適切な名前の名前空間接頭語も定義しない引き継いでいる名前空間項目を省略できます、これが、内容と属性を調べるのを未知の拡大を要求しますが。
Regardless of how clever an implementation tries to be, adding any namespace declaration attribute items to an unknown element item is harmful to canonicalization if the ASN.1 type for the element item turns out to be the Markup type. To counter this problem, a special attribute is used to identify the namespace declaration attribute items added to an unknown element item so that they can be removed later, if it proves necessary.
実装がどれくらい賢明であるかなろうとすることにかかわらず、要素の品目のためのASN.1タイプが、Markupタイプであると判明するなら、どんな名前空間宣言属性項目も未知の要素の品目に追加するのはcanonicalizationに有害です。 特別な属性は後でそれらを取り除くことができるように未知の要素の品目に追加された名前空間宣言属性項目を特定するのに使用されます、この問題を打ち返すなら必要であると判明するなら。
If the outermost element item in an unknown extension does not have an attribute item with the [local name] "context" and [namespace name] "urn:ietf:params:xml:ns:asnx" in its [attributes], then namespace declaration attribute items corresponding to the inherited namespace items that define the namespace prefixes of all the definite and potential qualified names in the content and attributes of the element item MUST be added to the retained [namespace attributes]. Other inherited namespace items MAY be added to the retained [namespace attributes].
未知の拡大における一番はずれの要素の品目が[属性]で[地方名]「文脈」と[名前空間名]「つぼ:ietf:params:xml:ナノ秒: asnx」がある属性項目を持っていないなら、要素の品目の内容と属性ですべての明確で潜在的の適切な名前の名前空間接頭語を定義する引き継いでいる名前空間項目に対応する名前空間宣言属性項目を保有に加えなければなりません[名前空間属性]。 他の引き継いでいる名前空間項目は保有に加えられるかもしれません[名前空間属性]。
If there are one or more of these added namespace declaration attribute items, then an attribute item with the [local name] "context" and [namespace name] "urn:ietf:params:xml:ns:asnx" MUST be added to the retained [attributes].
これらの加えられた名前空間宣言属性項目が1かまだあれば、[地方名]「文脈」と[名前空間名]「つぼ:ietf:params:xml:ナノ秒: asnx」がある属性項目を保有に加えなければなりません[属性]。
The [prefix] of the context attribute item is any namespace prefix that does not match the [local name] of any namespace declaration attribute item in the [namespace attributes] unless the [namespace attributes] property contains a namespace declaration attribute item with a non-empty [prefix] and a [normalized value] of "urn:ietf:params:xml:ns:asnx". In that case, the [local name] of that namespace declaration attribute item MAY be used as the [prefix] of the context attribute item.
文脈属性項目の[接頭語]が中でどんな名前空間宣言属性項目の[地方名]にも合っていないあらゆる名前空間接頭語である、[名前空間属性] [名前空間属性]特性が名前空間宣言を含まない場合、「つぼ:ietf:params:xml:ナノ秒: asnx」の非空の[接頭語]とa[値を正常にする]がある項目を結果と考えてください。 その場合、その名前空間宣言属性項目の[地方名]は文脈属性項目の[接頭語]として使用されるかもしれません。
Legg & Prager Experimental [Page 56] RFC 4910 Robust XML Encoding Rules July 2007
強健な[56ページ]RFC4910XML符号化規則2007年7月に実験的なLeggとプラーガー
If the [prefix] of the context attribute item does not match the [local name] of any namespace declaration attribute item, then an attribute item with the [prefix] "xmlns", [namespace name] "urn:ietf:params:xml:ns:asnx", and [local name] equal to the [prefix] of the context attribute item MUST be added to the retained [namespace attributes] of the element item.
文脈属性項目の[接頭語]がどんな名前空間宣言属性項目の[地方名]にも合っていないなら、要素の品目について"xmlns"、[名前空間名]「つぼ:ietf:params:xml:ナノ秒: asnx」、および[地方名]が文脈属性項目の[接頭語]と等しい[接頭語]がある属性項目を保有に加えなければなりません[名前空間属性]。
The [normalized value] of the context attribute is the white-space- separated unordered list of the [local names] of the added namespace declaration attribute items (i.e., a list of the namespace prefixes), including any namespace declaration attribute item added to define the [prefix] of the context attribute. Note that the [local name] for a namespace declaration attribute item declaring the default namespace is "xmlns".
文脈属性の[正常にされた値]は加えられた名前空間宣言属性項目(すなわち、名前空間接頭語のリスト)の[地方名]の白いスペースで切り離された順不同のリストです、文脈属性の[接頭語]を定義するために加えられたどんな名前空間宣言属性項目も含んでいて。 デフォルト名前空間を宣言する名前空間宣言属性項目のための[地方名]が"xmlns"であると述べてください。
Aside: A receiver that knows about the extension will use the
context attribute to strip out the added namespace declaration
attributes if the type of the associated NamedType is the Markup
type (Section 6.10), and will discard the context attribute
otherwise. A receiver that does not know about the extension will
re-encode the extension as is.
傍らに: 関連NamedTypeのタイプがMarkupタイプ(セクション6.10)であるなら加えられた名前空間宣言属性を取り除くのに文脈属性を使用するでしょう。そうでなければ、それが拡大に関して知っている受信機は、文脈属性を捨てるでしょう。 それが拡大に関して知らない受信機はそのままで拡大を再コード化するでしょう。
Adding the required namespace declaration attribute items to an element item effectively makes the element item self-contained. A received encoding has an encoding error if it contains an element item that is not self-contained but has a context attribute item in its [attributes].
有効に必要な名前空間宣言属性項目を要素の品目に追加するのに、要素の品目は自己充足的になります。 容認されたコード化には、[属性]に自己充足的ではありませんが、文脈属性項目を持っている要素の品目を含んでいるなら、コード化誤りがあります。
An RXER encoder MUST NOT add the context attribute item to an element item corresponding to a NamedType that is known to it.
RXERエンコーダはそれに知られているNamedTypeに対応する要素の品目に文脈属性項目を追加してはいけません。
An RXER decoder MUST accept the context attribute item on an element item corresponding to a NamedType that does not appear to be an extension.
RXERデコーダは、現れないNamedTypeに対応する要素の品目の文脈属性項目が拡大であると受け入れなければなりません。
Aside: It is not uncommon for extension markers to be neglected in
specifications traditionally using only BER, since extension
markers do not alter BER encodings. Consequently, it is not
immediately obvious in later versions of the specification which
instances of NamedType belong to extensions of the original base
specification.
傍らに: 拡大マーカーがBERだけを伝統的に使用する仕様で無視されるのは、珍しくはありません、拡大マーカーがBER encodingsを変更しないので。 その結果、それはすぐに、NamedTypeのそれのインスタンスが当初の基礎仕様の拡大に属す仕様の後のバージョンで明白ではありません。
Example
例
Suppose there are three applications, A, B, and C. Suppose that
Application A uses the first edition of an ASN.1 specification
containing the following type definition:
3つの利用があると仮定してください、A、B、C.SupposeはそのApplicationをBです。以下の型定義を含んでいて、AはASN.1仕様の初版を使用します:
Legg & Prager Experimental [Page 57] RFC 4910 Robust XML Encoding Rules July 2007
強健な[57ページ]RFC4910XML符号化規則2007年7月に実験的なLeggとプラーガー
MyType ::= SEQUENCE {
field1 INTEGER, -- present in first edition
...
}
MyType:、:= 系列最初の版の現在のfield1 INTEGER
Suppose that Application B uses the second edition of the ASN.1
specification:
Application BがASN.1仕様の第2版を使用すると仮定してください:
MyType ::= SEQUENCE {
field1 INTEGER, -- present in first edition
...,
field2 QName -- added in second edition
}
MyType:、:= 系列field1 INTEGER(最初の版、…field2 QNameでは、存在している)は第2版を加えました。
Suppose that Application C uses the third edition of the ASN.1
specification:
Application CがASN.1仕様の3番目の版を使用すると仮定してください:
MyType ::= SEQUENCE {
field1 INTEGER, -- present in first edition
...,
field2 QName, -- added in second edition
field3 Markup -- added in third edition
}
MyType:、:= 系列最初の版の現在のfield1 INTEGER(field2 QName(第2版field3 Markupでは、加えられる))は3番目の版を加えました。
Application C produces the following RXER encoding and sends it to
Application B:
アプリケーションCは、以下のRXERコード化を生産して、それをApplication Bに送ります:
<value xmlns:p2="http://example.com/ns2">
<field1> 100 </field1>
<field2> p2:foobar </field2>
<field3 xmlns:p1="http://example.com/ns1"> p1:foobar </field3>
</value>
<値のxmlns: p2が等しい、「 http://example.com/ns2 、「><field1>100</field1><field2>p2: foobar</field2><field3 xmlns: p1が等しい、「 http://example.com/ns1 、「>p1: foobar</field3></価値の>」
Application B doesn't know about <field3>, so it adds the
asnx:context attribute to <field3> when it re-encodes the abstract
value to send to Application A:
アプリケーションBが<field3>に関して知らないので、Application A:に発信するために抽象的な値を再コード化するとき、それはasnx: 文脈属性を<field3>に加えます。
Legg & Prager Experimental [Page 58] RFC 4910 Robust XML Encoding Rules July 2007
強健な[58ページ]RFC4910XML符号化規則2007年7月に実験的なLeggとプラーガー
<value xmlns:p1="http://example.com/ns2">
<!-- Application B knows the white space in field1 and
field2 is optional and discards it. -->
<field1>100</field1>
<field2>p1:foobar</field2>
<!-- Application B doesn't know about field3
so it leaves the character data alone. -->
<field3 asnx:context="asnx p2"
xmlns:asnx="urn:ietf:params:xml:ns:asnx"
xmlns:p1="http://example.com/ns1"
xmlns:p2="http://example.com/ns2"> p1:foobar </field3>
</value>
<値のxmlns: p1が等しい、「 http://example.com/ns2 、「><!--アプリケーションBがfield1で余白を知っていて、field2が任意であり、それを捨てる、」 --><field1>100</field1><field2>p1: foobar</field2><!--アプリケーションBがfield3に関して知らないので、それはキャラクタデータを放っておきます。 --「><field3 asnx: 文脈=「asnx p2" xmlns: asnx=」つぼ: ietf:params:xml:ナノ秒:asnx」xmlns: p1が" http://example.com/ns1 "xmlns: p2=と等しい、「 http://example.com/ns2 、「>p1: foobar</field3></価値の>」
Application A doesn't know about <field2> and <field3>, so it adds
the asnx:context attribute to <field2> and leaves <field3> alone
when it re-encodes the abstract value:
アプリケーションAが<field2>と<field3>に関して知らないので、抽象的な値を再コード化するとき、asnx: 文脈属性を<field2>に加えて、field3>だけに<を残します:
<value>
<!-- Application A knows about field1 and chooses
to add some white space. -->
<field1> 100 </field1>
<!-- Application A doesn't know about field2 or field3
so it leaves the character data alone. -->
<field2 asnx:context="asnx p1"
xmlns:asnx="urn:ietf:params:xml:ns:asnx"
xmlns:p1="http://example.com/ns2">p1:foobar</field2>
<field3 asnx:context="asnx p2"
xmlns:asnx="urn:ietf:params:xml:ns:asnx"
xmlns:p1="http://example.com/ns1"
xmlns:p2="http://example.com/ns2"> p1:foobar </field3>
</value>
<値の><!--アプリケーションAは、field1に関して知って、いくらかの余白を加えるのを選びます。 --><field1>100</field1><!--アプリケーションAがfield2かfield3に関して知らないので、それはキャラクタデータを放っておきます。 --「><field2 asnx: 文脈=「asnx p1" xmlns: asnx=」つぼ: ietf:params:xml:ナノ秒:asnx」xmlns: p1が等しい、「 http://example.com/ns2 「>p1: foobar</field2><field3 asnx: 文脈=「asnx p2" xmlns: asnx=」つぼ: ietf:params:xml:ナノ秒:asnx」xmlns: p1が" http://example.com/ns1 "xmlns: p2=と等しい、「 http://example.com/ns2 、「>p1: foobar</field3></価値の>」
If Application C receives this final encoding, it has sufficient
information to discard the asnx:context, xmlns:asnx, and xmlns:p2
attributes from the received Markup value of <field3> to recover
the original value. Application C knows about <field2>, so it
uses the namespace declaration for p1 when decoding the QName
value and ignores the other declarations.
Application Cがこの最終的なコード化を受けるなら、それには、asnx: 文脈を捨てることができるくらいの情報があります、xmlns: xmlns: asnx、および元の値を回復する<field3>の容認されたMarkup値からのp2属性。 アプリケーションCが<field2>に関して知っているので、それは、QName値を解読するとき、p1に名前空間宣言を使用して、他の宣言を無視します。
6.8.8.2. Unknown Attributes in Extensions
6.8.8.2. 拡大における未知の属性
To enable re-encoding of an unknown attribute item it is necessary to retain at least the [local name], [namespace name], and [normalized value] properties of the attribute item.
未知の属性項目の再コード化を可能にするために、属性項目の少なくとも[地方名]、[名前空間名]、および[値を正常にします]特性を保有するのが必要です。
The [normalized value] of an unknown attribute item may contain qualified names whose interpretation depends on the [in-scope namespaces] of the [owner element]. Semantically faithful
未知の属性項目の[正常にされた値]が解釈がよる適切な名前を含むかもしれない、[範囲の名前空間]、[所有者要素。] 意味的に忠実です。
Legg & Prager Experimental [Page 59] RFC 4910 Robust XML Encoding Rules July 2007
強健な[59ページ]RFC4910XML符号化規則2007年7月に実験的なLeggとプラーガー
re-encoding of the unknown attribute item may require reproduction of at least some part of the [in-scope namespaces]. In the absence of type information, it is not possible to discern whether anything that syntactically resembles a qualified name in the [normalized value] of an unknown attribute item actually is a qualified name.
未知の属性項目の再コード化が少なくとも何らかの部分の再現に要求するかもしれない、[範囲の名前空間。] タイプ情報がないときそれが裁量するのにおいて可能でない、シンタクス上適切な名前に似ている何、でも未知の属性項目の[正常にされた値]は実際に適切な名前です。
The simplest approach is to retain all the namespace items of the [in-scope namespaces] and output corresponding namespace declaration attribute items in the [namespace attributes] of the [owner element] when re-encoding the extension. At best, an application can omit the namespace items that do not define the namespace prefix of any potential qualified name in the [normalized value].
最も簡単なアプローチが[範囲の名前空間]の、そして、出力対応する名前空間宣言の項目が項目を結果と考えるすべての名前空間を保有することである、[名前空間属性]、[所有者要素] 拡大を再コード化するとき。 せいぜい、アプリケーションが可能性が名前に資格を与えたいずれの名前空間接頭語を定義しない名前空間項目を省略できる、[値を正常にします。]
An application MUST retain the namespace items in the [in-scope namespaces] of the [owner element] that define the namespace prefixes of all the potential qualified names in the [normalized value] of the unknown attribute item. Other namespace items in the [in-scope namespaces] of the [owner element] MAY be retained.
アプリケーションが名前空間項目を保有しなければならない、[範囲の名前空間]、すべての可能性の名前空間接頭語を定義する[所有者要素]が名前に中の資格を与えた、[値を正常にします] 未知の属性項目について。 中の他の名前空間項目、[範囲の名前空間] [所有者要素]5月では、保有されてください。
Aside: If the enclosing element item has more than one unknown
attribute item, then it is sufficient to save the union of the
retained namespace items with the element item, rather than saving
the retained namespace items with each unknown attribute item.
傍らに: 同封の要素の品目に1つ以上の未知の属性項目があるなら、それぞれの未知の属性項目で保有された名前空間項目を保存するより要素の品目でむしろ保有された名前空間項目の組合を保存するのは十分です。
When the unknown attribute item is re-encoded, the retained namespace items affect the [namespace attributes] and [in-scope namespaces] of the enclosing element item as specified in Section 6.2.2.1, and the [prefix] of the attribute item is determined as specified in Section 6.2.3.1.
そして、保有された名前空間項目が、未知の属性項目がいつ再コード化されるかに影響する、[名前空間属性]、[範囲の名前空間] セクション6.2.2における指定されるとしての同封の要素の品目では、.1、および属性項目の[接頭語]は、セクション6.2.3で.1を指定するので、決定しています。
Aside: The context attribute is not added to the [attributes] of
the [owner element] when re-encoding an unknown attribute item
because the type of a NamedType subject to an ATTRIBUTE or
ATTRIBUTE-REF encoding instruction cannot be the Markup type.
傍らに: 文脈属性が[属性]に加えられない、[所有者要素] 指示をコード化するATTRIBUTEかATTRIBUTE-REFを条件としたNamedTypeのタイプがMarkupであるはずがないので未知の属性項目を再コード化するときには、タイプしてください。
6.9. Open Type
6.9. 開放型
A value of an open type denoted by an ObjectClassFieldType [X.681] is translated according to the specific Type of the value.
価値の特定のTypeに従って、ObjectClassFieldType[X.681]によって指示された開放型の値は翻訳されます。
If the specific Type of the value is directly or indirectly the Markup type, then the enclosing element item MUST be self-contained.
価値の特定のTypeが直接そうかMarkupが間接的にタイプするなら、同封の要素の品目は独立であるに違いありません。
For a non-canonical RXER encoding, if the translation of the value does not generate an attribute item with the [local name] "type" and the [namespace name] "http://www.w3.org/2001/XMLSchema-instance" (i.e., xsi:type) and the specific Type of the value is a
a正典外のRXERコード化のために、価値に関する翻訳が、[地方名]がある属性項目が「タイプ」と[名前空間名]" http://www.w3.org/2001/XMLSchema-instance "(すなわち、xsi: タイプ)であると生成しないか、そして、価値の特定のタイプはaです。
Legg & Prager Experimental [Page 60] RFC 4910 Robust XML Encoding Rules July 2007
強健な[60ページ]RFC4910XML符号化規則2007年7月に実験的なLeggとプラーガー
namespace-qualified reference (Section 5), then an attribute item with the [local name] "type" and the [namespace name] "http://www.w3.org/2001/XMLSchema-instance" (i.e., xsi:type) MAY be added to the [attributes] of the enclosing element item. The [normalized value] of this attribute item is a qualified name for the expanded name of the referenced type, with the namespace prefix determined as specified in Section 6.7.11.1.
名前空間で適切な参照(セクション5)、そして、[地方名]「タイプ」と[名前空間名]" http://www.w3.org/2001/XMLSchema-instance "(すなわち、xsi: タイプ)がある属性項目は同封の要素の品目の[属性]に加えられるかもしれません。 この属性項目の[正常にされた値]は.1にセクション6.7.11における指定されると決定している名前空間接頭語をもっている被参照型の拡張名前のための適切な名前です。
Aside: The xsi:type attribute is added by RXER encoders for the
benefit of XML Schema validators. This attribute tells an
XML Schema validator which type definition in a compatible
XML Schema translation of the ASN.1 specification it should use
for validating the content and attributes of the enclosing
element. For an RXER decoder, the actual type in an open type
value is generally determined by an associated component relation
constraint [X.682], so the xsi:type attribute can be ignored.
傍らに: xsi: タイプ属性はXML Schema validatorsの利益のためにRXERエンコーダによって加えられます。 この属性は、それが同封要素の内容と属性を有効にするのにASN.1仕様のコンパチブルXML Schema翻訳へのどの型定義を使用するべきであるかをXML Schema validatorに言います。 RXERデコーダに関しては、関連コンポーネント関係規制[X.682]で開放型値における実際のタイプが一般に決定するので、xsi: タイプ属性を無視できます。
Example
例
The content and attributes of the following <value> element are
the RXER encoding of an open type value containing a BOOLEAN
value:
以下の<値の>要素の内容と属性はブール値を含む開放型価値のRXERコード化です:
<value xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:asnx="urn:ietf:params:xml:ns:asnx"
xsi:type="asnx:BOOLEAN"> true </value>
<値のxmlns: xsiは" http://www.w3.org/2001/XMLSchema-instance "xmlnsと等しいです: asnxは「つぼ:ietf:params:xml:ナノ秒: asnx」xsiと等しいです: =をタイプしてください、「asnx: ブール「>の本当の</価値の>」
If the ObjectClassFieldType denoting an open type is not constrained by a TableConstraint, or is constrained by a TableConstraint where the constraining object set is extensible, then an application MUST accept and be prepared to re-encode (using the same encoding rules) any value of the open type where the specific Type of the value is unknown. In such cases, the enclosing element item is treated like an unknown element item in the value of an extensible combining ASN.1 type (see Section 6.8.8.1).
開放型を指示するObjectClassFieldTypeがTableConstraintによって抑制されないか、または設定された抑制オブジェクトが広げることができるTableConstraintによって抑制されるなら、アプリケーションは受け入れて、価値の特定のTypeが未知である開放型のあらゆる値を再コード化するように(同じ符号化規則を使用します)準備しなければなりません。 セクション6.8を見てください。そのような場合では、同封の要素の品目が広げることができる結合ASN.1タイプの値における未知の要素の品目のように扱われる、(.8 .1)。
6.10. Markup
6.10. マークアップ
Conceptually, a value of the Markup type holds the [prefix], [attributes], [namespace attributes], and [children] of an element item. The Infoset translation of a value of the Markup type initially simply sets the [prefix], [attributes], [namespace attributes], and [children] of the enclosing element item to the corresponding properties represented by the Markup value.
概念的に、Markupタイプの値は要素の品目の[接頭語]、[属性]、[名前空間属性]、および[子供]を保持します。 Markupタイプの価値に関するInfoset翻訳は初めは、単に同封の要素の品目の[接頭語]、[属性]、[名前空間属性]、および[子供]をMarkup値によって表された対応する特性に設定します。
Recall that the enclosing element item for the translation of a Markup value is required to be self-contained (Section 4.1.1).
Markup価値に関する翻訳のための同封の要素の品目が自己充足的に(セクション4.1.1)なるのに必要であったと思い出してください。
Legg & Prager Experimental [Page 61] RFC 4910 Robust XML Encoding Rules July 2007
強健な[61ページ]RFC4910XML符号化規則2007年7月に実験的なLeggとプラーガー
If the enclosing element item is not the [document element] of the document item, and the [in-scope namespaces] property of the enclosing element item's [parent] contains a namespace item for the default namespace, and the [namespace attributes] property represented by the Markup value does not contain a namespace item declaring or undeclaring the default namespace, then a namespace declaration attribute item that undeclares the default namespace SHALL be added to the enclosing element item's [namespace attributes].
同封の要素の品目がドキュメントの品目のドキュメント要素でなく、また範囲の同封の要素の品目の親の名前空間の特性がデフォルト名前空間のための名前空間項目を含んでいて、Markup値によって表された名前空間属性の特性がデフォルト名前空間を宣言するか、または非宣言する名前空間項目を含んでいないなら; 次に、名前空間宣言はデフォルト名前空間SHALLを非宣言する項目を結果と考えます。同封の要素の品目の名前空間属性に加えられます。
It is not necessary to populate the [in-scope namespaces] of the enclosing element item for encoding purposes (though it may be warranted for other purposes).
それは居住するのに必要でない、目的(それは他の目的のために保証されるかもしれませんが)をコード化するための同封の要素の品目の[範囲の名前空間。]
An element item nested in the [children] is potentially the Infoset translation of a value of a top-level NamedType (as allowed by Section 6.4), and the entire Markup value can represent the content and attributes of an element item that is the translation of a value of a top-level NamedType.
[子供]で入れ子にされた要素の品目は潜在的にトップレベルNamedTypeの価値に関するInfoset翻訳(セクション6.4によって許容されているように)です、そして、全体のMarkup値はトップレベルNamedTypeの価値に関する翻訳である要素の品目の内容と属性を表すことができます。
Aside: The latter case arises when an ELEMENT-REF encoding
instruction references a top-level NamedType.
傍らに: 指示をコード化するELEMENT-REFがトップレベルNamedTypeに参照をつけるとき、後者のケースは起こります。
The content and attributes of an element item nested in the [children] of a Markup value are potentially the Infoset translation of an abstract value of an ASN.1 type (as allowed by Section 6.4), and the entire Markup value can represent the translation of a single abstract value.
Markup価値の[子供]で入れ子にされた要素の品目の内容と属性は潜在的にASN.1タイプの抽象的な価値に関するInfoset翻訳(セクション6.4によって許容されているように)です、そして、全体のMarkup値はただ一つの抽象的な価値に関する翻訳を表すことができます。
Aside: The latter case arises when a TYPE-REF encoding instruction
references an ASN.1 type.
傍らに: ASN.1がタイプする指示参照をコード化するTYPE-REFであるときに、後者のケースは起こります。
For a non-canonical RXER encoding, any element item, at any level of nesting (including the enclosing element item itself), that corresponds to the value of a top-level NamedType MAY be replaced with any valid translation of that value.
正典外のRXERコード化、どんなレベルの巣篭もりにおけるトップレベルの値に対応するどんな要素の品目(同封の要素の品目自体を含んでいる)においても、NamedTypeをその価値のどんな有効な翻訳にも取り替えるかもしれません。
For a non-canonical RXER encoding, any element item, at any level of nesting (including the enclosing element item itself), with content and attributes that correspond to an abstract value of an ASN.1 type MAY have that content and those attributes replaced with any valid translation of that abstract value. If the content and attributes are replaced, then the [prefix], [in-scope namespaces], and [namespace attributes] of the element item are constructed as specified in Sections 6.2.2.1 and 6.2.2.2. The enclosing element item for the Markup value is still required to be self-contained.
正典外のRXERに関しては、コード化、どんなレベルの巣篭もりにおけるASN.1タイプの抽象的な値に対応する内容と属性があるどんな要素の品目(同封の要素の品目自体を含んでいる)でも、その内容とそれらの属性をその抽象的な価値のどんな有効な翻訳にも取り替えるかもしれません。 内容と属性を取り替えるなら、セクション6.2.2で.1と6.2を指定するとき、[接頭語]、[範囲の名前空間]、および要素の品目の[名前空間属性]を組み立てます。.2 .2。 Markup値のための同封の要素の品目が、自己充足的になるのにまだ必要です。
Legg & Prager Experimental [Page 62] RFC 4910 Robust XML Encoding Rules July 2007
強健な[62ページ]RFC4910XML符号化規則2007年7月に実験的なLeggとプラーガー
Aside: Insofar as a Markup value represents ASN.1 abstract values,
it is sufficient for the RXER encoding of the Markup value to
preserve the abstract values rather than preserve the exact
Infoset representation.
傍らに: Markup値がASNの.1の抽象的な値を表す限り、正確なInfoset表現を保存するよりむしろ抽象的な価値を守るのはMarkup価値のRXERコード化に十分です。
For a CRXER encoding, any element item, at any level of nesting (including the enclosing element item itself), that corresponds to a value of a top-level NamedType MUST be replaced with the CRXER translation of that value.
CRXERコード化、どんなレベルの巣篭もりにおけるトップレベルの値に対応するどんな要素の品目(同封の要素の品目自体を含んでいる)においても、NamedTypeをその価値に関するCRXER翻訳に取り替えなければなりません。
For a CRXER encoding, any element item, at any level of nesting (including the enclosing element item itself), with content and attributes that correspond to an abstract value of an ASN.1 type MUST have that content and those attributes replaced with the CRXER translation of that abstract value. The [prefix], [in-scope namespaces], and [namespace attributes] of the element item are constructed as specified in Sections 6.2.2.1 and 6.2.2.2.
CRXERに関しては、コード化、どんなレベルの巣篭もりにおけるASN.1タイプの抽象的な値に対応する内容と属性があるどんな要素の品目(同封の要素の品目自体を含んでいる)でも、その内容とそれらの属性をその抽象的な価値に関するCRXER翻訳に取り替えなければなりません。 セクション6.2.2で.1と6.2を指定するとき、[接頭語]、[範囲の名前空間]、および要素の品目の[名前空間属性]は組み立てられます。.2 .2。
If the [attributes] property of the enclosing element item from a received RXER encoding contains an attribute item with the [local name] "context" and [namespace name] "urn:ietf:params:xml:ns:asnx" (i.e., asnx:context), then this attribute item MUST be omitted from the [attributes] represented by the Markup value, and each namespace declaration attribute item with a [local name] matching an NCName in the [normalized value] of the attribute item MUST be omitted from the [namespace attributes] represented by the Markup value.
容認されたRXERからの同封の要素の品目の属性の特性であるなら、コード化は「つぼ:ietf:params:xml:ナノ秒: asnx」(すなわち、asnx: 文脈)という地方名「文脈」と名前空間名がある属性項目を含んでいます; 次に、Markup値によって表された属性からこの属性項目を省略しなければなりません、そして、Markup値によって表された名前空間属性から地方名が属性項目の正常にされた値でNCNameに合っているそれぞれの名前空間宣言属性項目を省略しなければなりません。
6.11. Namespace Prefixes for CRXER
6.11. CRXERのための名前空間接頭語
The final step in translating the value of a top-level NamedType for a CRXER encoding, or an abstract value for a Standalone CRXER Encoding, is the replacement of the arbitrarily chosen namespace prefixes with algorithmically determined canonical namespace prefixes. This procedure for prefix replacement applies to each element item where the [namespace attributes] have been constructed according to Section 6.2.2.1. This includes any element item corresponding to a value of a top-level NamedType, or with content and attributes that correspond to an abstract value of an ASN.1 type, that is nested in a value of the Markup type.
CRXERコード化のためのトップレベルNamedTypeの値、またはStandalone CRXER Encodingのための抽象的な値を翻訳することにおける最終的なステップはalgorithmicallyに決定している正準な名前空間接頭語への任意に選ばれた名前空間接頭語の交換です。 接頭語交換のためのこの手順がそれぞれの要素の品目にどこを当てはまるか、セクション6.2.2に従って、[名前空間属性]は.1に組み立てられました。 これはASN.1タイプの抽象的な値に対応するトップレベルNamedTypeか、内容と属性があるMarkupタイプの値で入れ子にされる値に対応するどんな要素の品目も含んでいます。
For each element item where prefix replacement applies, the following sequence of steps is repeated until there are no more eligible attribute items to select in step (1):
接頭語交換が適用されるそれぞれの要素の品目において、ステップ(1)で選択するそれ以上の適任の属性項目がないまで、ステップの以下の系列は繰り返されます:
Legg & Prager Experimental [Page 63] RFC 4910 Robust XML Encoding Rules July 2007
強健な[63ページ]RFC4910XML符号化規則2007年7月に実験的なLeggとプラーガー
(1) Select the attribute item with the least [normalized value] from
amongst the attribute items of the [namespace attributes] that
have a [local name] that is not a canonical namespace prefix
(i.e., select from the namespace declaration attribute items that
have not already been processed). A [normalized value] is less
than another [normalized value] if the former appears before the
latter in an ordering of the values determined by comparing the
ISO 10646 code points [UCS] of their characters, from first to
last. A shorter string of characters is ordered before a longer
string of characters that is identical up to the length of the
shorter string.
(1)が属性項目からの最少[値を正常にする]がある属性項目を選択する、正準な名前空間接頭語(すなわち、既に処理されていない名前空間宣言属性商品から選び抜く)でない[地方名]を持っている[名前空間属性。] 値の注文における後者がISO10646コードを比較しながら自決する前に前者が現れるなら別のもの[値を正常にする]が彼らの性格の[UCS]を指すよりそれほど、そして、最初から最後までA[値を正常にする]はそうです。 キャラクタの、より脆いストリングの長さまで同じより長いストリングの前でキャラクタの、より脆いストリングを注文します。
Aside: Note that when a namespace declaration (other than for
the default namespace) is represented as an attribute item in
the [namespace attributes], the attribute's [prefix] is
"xmlns", its [local name] is the namespace prefix, and its
[normalized value] is the namespace name.
傍らに: そして、名前空間宣言(デフォルト名前空間を除いた)が属性項目として中に表されたらそれに注意してください、[名前空間属性]、属性の[接頭語]が"xmlns"、[地方名]が名前空間接頭語であるということである、それ、[正常にされた値]は名前空間名です。
(2) A canonical namespace prefix is unused if it is not currently the
[prefix] of any namespace item in the [in-scope namespaces] of
the element item. Replace the [local name] of the selected
attribute item with the unused canonical namespace prefix that
has the non-negative number string with the least integer value
(e.g., n2 is less than n10).
(2) 正準な名前空間接頭語が現在それが中のどんな名前空間項目の[接頭語]でないなら未使用である、も要素の品目の[範囲の名前空間。] 選択された属性項目の[地方名]を最少の整数値がある非負数ストリングを持っている未使用の正準な名前空間接頭語に取り替えてください(例えば、n2はn10以下です)。
(3) The selected attribute item has a corresponding namespace item in
the [in-scope namespaces] of the element. Replace the [prefix]
of this corresponding namespace item with the canonical namespace
prefix determined in step (2).
(3) 選択された属性項目には対応する名前空間項目がある、要素の[範囲の名前空間。] 正準な名前空間接頭語が決定していた状態で、ステップ(2)でこの対応する名前空間項目の[接頭語]を取り替えてください。
(4) The element item and its [attributes] property, and descendent
element items and their [attributes] properties, may depend on
the selected attribute item to determine the binding between
their [prefix] and [namespace name]. Replace the [prefix] of any
such dependent element items and attribute items with the
canonical namespace prefix determined in step (2).
(4) 要素の品目、[属性]の特性、下降の要素の品目、および彼らの[属性]の特性は、それらの[接頭語]と[名前空間名]の間の結合を決定するために選択された属性項目に依存するかもしれません。 正準な名前空間接頭語が決定していた状態で、ステップ(2)でどんなそのような依存要素の品目と属性項目の[接頭語]も取り替えてください。
Note that a namespace prefix can be redeclared (reused).
Replacement of the prefix does not apply to an element item
wherein the prefix is redeclared, or to the descendants of such
an element item.
名前空間接頭語を再宣言できることに(再利用されます)注意してください。 接頭語の交換は接頭語が再宣言される要素の品目、または、そのような要素の品目の子孫に適用されません。
(5) The character data translations for values of the QName ASN.1
type may depend on the selected attribute item to determine the
binding between their namespace prefix and namespace name.
Replace the namespace prefix of any such dependent character data
translation with the canonical namespace prefix determined in
step (2).
(5) QName ASN.1タイプの値のためのキャラクタデータ変換は、それらの名前空間接頭語と名前空間名の間の結合を決定するために選択された属性項目によるかもしれません。 正準な名前空間接頭語が決定していた状態で、ステップ(2)でそのようなどんな依存するキャラクタデータ変換の名前空間接頭語も取り替えてください。
Legg & Prager Experimental [Page 64] RFC 4910 Robust XML Encoding Rules July 2007
強健な[64ページ]RFC4910XML符号化規則2007年7月に実験的なLeggとプラーガー
Note that a character data translation can appear in the
[normalized value] of an attribute item, or as a sequence of
character items in the [children] of an element item.
キャラクタデータ変換が現れることができる注意、[値を正常にします] 属性項目か、要素の品目の[子供]のキャラクタ項目のa系列として。
6.12. Serialization
6.12. 連載
The final RXER encoding is produced by serializing the Infoset translation as an XML document. An implementation MUST serialize the Infoset translation as an XML document in such a way that the Infoset of the resulting XML document matches the Infoset translation, after ignoring the following properties:
最終的なRXERコード化は、XMLドキュメントとしてInfoset翻訳を連載することによって、生産されます。 実装はXMLドキュメントとして結果として起こるXMLドキュメントのInfosetがInfoset翻訳に合っているような方法でInfoset翻訳を連載しなければなりません、以下の特性を無視した後に:
(1) all properties of the document item except the
[document element],
(1) ドキュメントの品目のすべての特性が除かれる、[ドキュメント要素]
(2) the [base URI] of any item,
(2)、どんな項目の[ベースURI]
(3) the [element content whitespace] of character items,
(3)、キャラクタ項目の[要素内容空白]
(4) the [notation] of processing instruction items,
(4) 処理命令項目の[記法]
(5) the [in-scope namespaces] of element items.
(5)、要素の品目の[範囲の名前空間。]
Aside: The [in-scope namespaces] of a parent element item are only
selectively inherited by its child element items in the Infoset
translations of ASN.1 values. This means that the Infoset
reconstructed by parsing the XML document serialization of the
original Infoset will generally have more namespace items in its
[in-scope namespaces], but these extra namespace items will not be
significant.
傍らに: 親元素の品目の[範囲の名前空間]はASN.1値に関するInfoset翻訳で子供要素の品目によって選択的に引き継がれるだけです。 Infosetが一般に、オリジナルのInfosetのXMLドキュメント連載が、より多くの名前空間項目を持っている構文解析で再建したこの手段、それ、[範囲の名前空間]、これらの付加的な名前空間項目だけが重要にならないでしょう。
Aside: A consequence of case (1) is that comments and PIs before
and after the document element are permitted.
傍らに: ケース(1)の結果はドキュメント要素の前後にコメントとPIsが受入れられるということです。
In general, there is more than one possible serialization for any given Infoset translation. Section 6.12.1 highlights some important considerations in producing a correct serialization and discusses some of the serialization options.
一般に、Infoset翻訳を考えて、いずれのための1つ以上の可能な連載があります。 セクション6.12 .1 正しい連載を起こす際にいくつかの重要な問題を強調して、連載オプションのいくつかについて議論します。
Section 6.12.2 applies to CRXER encodings and limits the serialization options so that each distinct Infoset has only one possible serialization.
セクション6.12 .2 それぞれの異なったInfosetには1つの可能な連載しかないように、連載オプションをCRXER encodingsと限界に適用します。
6.12.1. Non-Canonical Serialization
6.12.1. 正典外の連載
This section discusses aspects of Infoset serialization for non-canonical RXER encodings, but is not an exhaustive list of the options for non-canonical serialization.
このセクションは、正典外のRXER encodingsのためにInfoset連載の局面について議論しますが、正典外の連載のためのオプションに関する完全なりストではありません。
Legg & Prager Experimental [Page 65] RFC 4910 Robust XML Encoding Rules July 2007
強健な[65ページ]RFC4910XML符号化規則2007年7月に実験的なLeggとプラーガー
If one or more character items have a [character code] in the range U+0001 to U+0008, U+000B to U+000C, or U+000E to U+001F, or one or more characters in any attribute's [normalized value] are in the range U+0001 to U+0008, U+000B to U+000C, or U+000E to U+001F, then the Infoset translation MUST be serialized as an XML version 1.1 document; otherwise, the Infoset translation is serialized as either an XML version 1.0 or version 1.1 document.
1つ以上のキャラクタ項目が範囲Uに+0001に、a[キャラクタコード]をU+0008に持っています、U+000CへのU+000B、または属性のどんなもの[値を正常にする]にも、U+000EからU+0001からU+0008、U+000CへのU+000B、またはU+001Fが範囲にU+001F、または1つ以上のキャラクタへのU+000Eあるなら、XMLバージョン1.1ドキュメントとしてInfoset翻訳を連載しなければなりません。 さもなければ、XMLバージョン1.0かバージョン1.1のどちらかが記録するようにInfoset翻訳は連載されます。
A non-canonical RXER encoding may use any of the allowed character encoding schemes for XML. RXER encoders and decoders MUST support the UTF-8 character encoding.
正典外のRXERコード化はXMLに許容文字符号化体系のいずれも使用するかもしれません。 RXERエンコーダとデコーダはUTF-8文字符号化をサポートしなければなりません。
An element item may be serialized as an empty-element tag if it has no items in its [children].
[子供]に項目を全く持っていないなら、要素の品目は空要素タグとして連載されるかもしれません。
Attributes of an element can appear in any order since the [attributes] and [namespace attributes] of an element item are unordered.
[属性]以来要素の属性は順不同に現れることができます、そして、要素の品目の[名前空間属性]は順不同のです。
Ampersand ('&', U+0026) and open angle bracket ('<', U+003C)
characters in the [normalized value] of an attribute item must be
escaped appropriately [XML10][XML11] (with a character reference or a
predefined entity reference). Double quote (U+0022) and single quote
(U+0027) characters in an attribute item's [normalized value] may
also need to be escaped. Character items with the [character code]
U+0026 (ampersand, '&') or U+003C (open angle bracket, '<') must be
escaped appropriately (with a character reference, a predefined
entity reference or a CDATA section).
アンパーサンド('&'、U+0026)と戸外がブラケット('<'、U+003C)キャラクタを傾ける、適切[XML10][XML11](文字参照か定義済み実体参照で)に属性項目の[正常にされた値]から逃げなければなりません。 また、項目の属性もの[値を正常にする]の二重引用文(U+0022)とただ一つの引用文(U+0027)のキャラクタは、逃げられる必要があるかもしれません。 適切(文字参照、定義済み実体参照またはCDATA部で)に[キャラクタコード]U+0026(アンパーサンド、'&')かU+003C(開いている角ブラケット、'<')があるキャラクター商品から逃げなければなりません。
Line break normalization by XML processors allows some freedom in how a character item for a line feed character (U+000A) is serialized:
XMLプロセッサによるラインブレイク正常化は改行文字(U+000A)のためのキャラクタ項目がどう連載されるかの何らかの自由を許容します:
(1) If XML version 1.0 is selected, then a character item with the
[character code] U+000A (line feed) is serialized as either a
line feed character (U+000A), a carriage return character
(U+000D) followed by a line feed character (U+000A), or just a
carriage return character (U+000D) provided the next item is not
a character item that is serialized as a line feed character
(U+000A).
(1) XMLバージョン1.0が選択されるなら、[キャラクタコード]U+000A(改行)があるキャラクタ項目は改行文字(U+000A)として連載されます、と改行文字(U+000A)、またはまさしく復帰文字(U+000D)で復帰文字(U+000D)は次の項目が改行文字(U+000A)として連載されるキャラクタ項目でないなら続きました。
(2) If XML version 1.1 is selected, then a character item with the
[character code] U+000A (line feed) is serialized as either a
line feed character (U+000A), a next line character (U+0085), a
line separator character (U+2028), a carriage return character
(U+000D) followed by a line feed character (U+000A), a carriage
return character (U+000D) followed by a next line character
(2) XMLバージョン1.1が選択されるなら、[キャラクタコード]U+000A(改行)があるキャラクタ項目は改行文字(U+000A)として連載されています、次の系列キャラクタ(U+0085)、ラインセパレータキャラクタ(U+2028)、改行文字(U+000A)で復帰文字(U+000D)は従いました、と復帰文字(U+000D)が次の系列キャラクタで続いたということです。
Legg & Prager Experimental [Page 66] RFC 4910 Robust XML Encoding Rules July 2007
強健な[66ページ]RFC4910XML符号化規則2007年7月に実験的なLeggとプラーガー
(U+0085), or just a carriage return character (U+000D) provided
the next item is not a character item that is serialized as a
line feed (U+000A) or next line (U+0085) character.
(U+0085)、またはまさしく次の商品が提供された復帰文字(U+000D)がそうです。改行(U+000A)として連載されるキャラクタ項目でない次の系列(U+0085)キャラクタでない。
Aside: All these sequences will be normalized to a line feed
character (U+000A) during decoding.
傍らに: これらのすべての系列が解読の間、改行文字(U+000A)に正常にされるでしょう。
A character item with the [character code] U+000D (carriage return), U+0085 (next line), or U+2028 (line separator) must be serialized as a character reference to protect the character from line break normalization during decoding.
解読の間、ラインブレイク正常化からキャラクタを保護するために文字参照として[キャラクタコード]U+000D(復帰)、U+0085(次の系列)、またはU+2028(ラインセパレータ)があるキャラクタ項目を連載しなければなりません。
The attribute value normalization performed by XML processors allows some freedom in how a space character (U+0020) is serialized:
XMLプロセッサによって実行された属性値正常化は間隔文字(U+0020)がどう連載されるかの何らかの自由を許容します:
(1) If XML version 1.0 is selected, then a space character (U+0020)
in an attribute item's [normalized value] is serialized as either
a space character (U+0020), a tab character (U+0009), a carriage
return character (U+000D), a line feed character (U+000A), a
carriage return character (U+000D) followed by a line feed
character (U+000A), or just a carriage return character (U+000D)
provided the next character in the [normalized value] is not
serialized as a line feed character (U+000A).
(1) XMLバージョン1.0が選択されるなら間隔文字(U+0020)、タブキャラクタ(U+0009)、復帰文字(U+000D)、改行文字(U+000A)、改行文字(U+000A)があとに続いた復帰文字(U+000D)、またはまさしく復帰文字(U+000D)が次のキャラクタを提供したように項目の属性もの[値を正常にする]の間隔文字(U+0020)が連載される、[正常にされた値]は改行文字(U+000A)として連載されません。
(2) If XML version 1.1 is selected, then a space character (U+0020)
in an attribute item's [normalized value] is serialized as either
a space character (U+0020), a tab character (U+0009), a carriage
return character (U+000D), a line feed character (U+000A), a next
line character (U+0085), a line separator character (U+2028), a
carriage return character (U+000D) followed by a line feed
character (U+000A), a carriage return character (U+000D) followed
by a next line character (U+0085), or just a carriage return
character (U+000D) provided the next character in the
[normalized value] is not serialized as a line feed (U+000A) or
next line (U+0085) character.
(2) XMLバージョン1.1が選択されるなら; 次に、属性項目の正常にされた値における間隔文字(U+0020)は間隔文字(U+0020)、タブキャラクタ(U+0009)、復帰文字(U+000D)、改行文字(U+000A)、次の系列キャラクタ(U+0085)として連載されます、ラインセパレータキャラクタ(U+2028); 改行文字(U+000A)で復帰文字(U+000D)は従いました、と次の系列キャラクタ(U+0085)を復帰文字(U+000D)は続けたか、またはまさしく正常にされた値で次のキャラクタに提供された復帰文字(U+000D)は改行(U+000A)か次の系列(U+0085)キャラクタとして連載されません。
Aside: All these sequences will be normalized to a space
character (U+0020) during decoding, through a combination of
line break normalization and attribute value normalization.
傍らに: これらのすべての系列がラインブレイク正常化と属性値正常化の組み合わせで解読している間、間隔文字(U+0020)に正常にされるでしょう。
Each tab (U+0009), line feed (U+000A), or carriage return (U+000D) character in an attribute item's [normalized value] must be serialized as a character reference to protect the character from attribute value normalization during decoding. In addition, if XML version 1.1 is selected, then each next line (U+0085) or line separator (U+2028) character must be serialized as a character reference.
解読の間、属性値正常化からキャラクタを保護するために文字参照として項目の属性もの[値を正常にする]のそれぞれのタブ(U+0009)、改行(U+000A)、または復帰(U+000D)キャラクタを連載しなければなりません。 さらに、XMLバージョン1.1が選択されるなら、文字参照としてそれぞれの次の系列(U+0085)かラインセパレータ(U+2028)キャラクタを連載しなければなりません。
Legg & Prager Experimental [Page 67] RFC 4910 Robust XML Encoding Rules July 2007
強健な[67ページ]RFC4910XML符号化規則2007年7月に実験的なLeggとプラーガー
Parsed entity references may be used (unless the environment in which the RXER encoding is used disallows entity references). If entity references to other than the predefined entities are used, then the XML document containing the RXER encoding must necessarily contain a document type declaration, and the internal or external subset of the document type definition must contain entity declarations for those entities.
解析対象実体参照は使用されるかもしれません(RXERコード化が使用されている環境が実体参照を禁じない場合)。 次に、使用される定義済み実体、XMLドキュメント含有を除いたRXERコード化の実体参照が必ずドキュメント型の宣言を含まなければならなくて、ドキュメント型定義の内部の、または、外部の部分集合がそれらの実体のための実体宣言を含まなければならないなら。
6.12.2. Canonical Serialization
6.12.2. 正準な連載
This section discusses Infoset serialization for CRXER encodings. The serialization of an Infoset for a CRXER encoding is restricted so that each distinct Infoset has only one possible serialization as an XML document.
このセクションはCRXER encodingsのためにInfoset連載について論じます。 CRXERコード化のためのInfosetの連載が制限されるので、それぞれの異なったInfosetには、XMLドキュメントとして1つの可能な連載しかありません。
Aside: These restrictions have been chosen so as to be consistent
with Canonical XML [CXML], where possible.
傍らに: これらの制限は、可能であるところでCanonical XML[CXML]と一致しているように選ばれました。
The document SHALL be encoded in UTF-8 without a leading Byte Order Mark [UCS].
コード化されたコネが主なByte Orderマーク[UCS]がいなければUTF-8であったならSHALLを記録してください。
The XMLDecl of the document SHALL be <?xml version="1.1"?>.
XMLDecl、ドキュメントSHALLでは、<になってください--「1.1インチ?>」というxmlバージョン=。
A document type declaration (doctypedecl) SHALL NOT be used.
ドキュメントは宣言(doctypedecl)SHALL NOTをタイプします。使用されます。
Aside: This has the effect of excluding entity references, except
those for the predefined entities (e.g., &).
傍らに: これには、定義済み実体(例えば、&)のためのそれらを除いて、実体参照を除くという効果があります。
A single line feed character (U+000A) MUST be inserted immediately before the document element.
ドキュメント要素の直前ただ一つの改行文字(U+000A)を挿入しなければなりません。
No other white space characters are permitted before or after the document element.
他の余白キャラクタは全くドキュメント要素の前または後に受入れられません。
There SHALL NOT be any PIs or comments before or after the document element.
そこでは、SHALL NOTはどんなPIsであるか以前か後にドキュメント要素について論評します。
An element item MUST NOT be serialized as an empty-element tag.
空要素タグとして要素の品目を連載してはいけません。
Aside: If an element item has no items in its [children], then it
is serialized as a start-tag followed by an end-tag.
傍らに: 要素の品目が[子供]に項目を全く持っていないなら、開始タグが終了タグで従って、それは連載されます。
There SHALL NOT be any white space characters immediately before the closing '>' of an element's start-tag and end-tag. The white space preceding each attribute SHALL be exactly one space character (U+0020). There SHALL NOT be any white space characters immediately before or after the equals sign (U+003D) in an attribute.
そこでは、SHALL NOTがいくらかそうです。要素の開始タグと終了タグについて閉鎖の直前'>'という間隔文字を空白にしてください。 まさに1つの間隔文字が(U+0020)であったならそれぞれの属性SHALLに先行する余白。 そこ、SHALL NOT、直前か同輩が属性で(U+003D)に署名した後にどんな余白キャラクタになってください。
Legg & Prager Experimental [Page 68] RFC 4910 Robust XML Encoding Rules July 2007
強健な[68ページ]RFC4910XML符号化規則2007年7月に実験的なLeggとプラーガー
The delimiter for attribute values SHALL be the double quote character (U+0022).
属性のためのデリミタは二重引用文字が(U+0022)であったならSHALLを評価します。
Namespace declaration attributes MUST appear before any other attributes of an element. A namespace declaration for the default namespace, if present, MUST appear as the first attribute. The remaining namespace declaration attributes MUST appear in lexicographic order based on [local name].
名前空間宣言属性は要素のいかなる他の属性の前にも現れなければなりません。 存在しているなら、デフォルト名前空間のための名前空間宣言は最初の属性として現れなければなりません。 残っている名前空間宣言属性は[地方名]に基づく辞書式順序に現れなければなりません。
Aside: In particular, this means that xmlns:n10 comes before
xmlns:n2.
傍らに: 特に、これはそのxmlnsを意味します: n10はxmlnsに優先します: n2。
The attributes that are not namespace declarations MUST be lexicographically ordered on [namespace name] as the primary key and [local name] as the secondary key.
セカンダリキーとしての主キーと[地方名]として[名前空間名]で辞書編集に名前空間宣言でない属性を命令しなければなりません。
CDATA sections SHALL NOT be used.
CDATAはSHALL NOTを区分します。使用されます。
Each ampersand character ('&', U+0026) in an attribute item's
[normalized value] MUST be serialized as the entity reference &.
Each open angle bracket character ('<', U+003C) in an attribute
item's [normalized value] MUST be serialized as the entity reference
<. Each double quote character (U+0022) in an attribute item's
[normalized value] MUST be serialized as the entity reference ".
Each character in the range U+0001 to U+001F or U+007F to U+009F in
an attribute item's [normalized value] MUST be serialized as a
character reference. No other character in a [normalized value] is
permitted to be serialized as an entity reference or character
reference.
実体参照&として属性項目の正常にされた値におけるそれぞれのアンパーサンドキャラクタ('&'、U+0026)を連載しなければなりません。実体参照<として属性項目の正常にされた値におけるそれぞれのオープンな角ブラケット性格('<'、U+003C)を連載しなければなりません; 実体参照"として属性項目の正常にされた値におけるそれぞれの二重引用文字(U+0022)を連載しなければなりません。文字参照として項目の属性ところでU+007FからU+001FかU+009F正常にされることへのU+0001が評価する範囲の各キャラクタを連載しなければなりません。 実体参照か文字参照としてa[値を正常にする]の他のキャラクタが全く連載されることが許可されていません。
Each character item with the [character code] U+0026 (the ampersand character) MUST be serialized as the entity reference &. Each character item with the [character code] U+003C (the open angle bracket character) MUST be serialized as the entity reference <. Each character item with the [character code] U+003E (the closing angle bracket character) MUST be serialized as the entity reference >. Each character item with a [character code] in the range U+0001 to U+0008, U+000B to U+001F, or U+007F to U+009F MUST be serialized as a character reference. No other character item is permitted to be serialized as an entity reference or character reference.
キャラクタコードUがあるそれぞれのキャラクタ項目は+0026(アンパーサンドキャラクタ)に連載しなければなりません。実体参照&として連載されてください。実体参照<としてキャラクタコードU+003C(オープンな角ブラケット性格)があるそれぞれのキャラクタ項目を連載しなければなりません; 実体が範囲Uでキャラクタコードで+0001に>それぞれのキャラクタ項目に参照をつけるのでU+003E(終わりの角ブラケットキャラクタ)がそうしなければならないキャラクタコードがあるそれぞれのキャラクタ項目がU+0008に連載されて、文字参照としてU+007FからU+001FへのU+000B、またはU+009Fを連載しなければなりません。 実体参照か文字参照として他のキャラクタ項目が全く連載されることが許可されていません。
Character references, where they are permitted, SHALL use uppercase hexadecimal with no leading zeroes. For example, the carriage return character is represented as 
.
キャラクター参照であり、SHALLは主なゼロなしで大文字している16進を使用します。そこでは、それらが受入れられます。 例えば、復帰文字が表される、#xD。
A space character (U+0020) in an attribute item's [normalized value] MUST be serialized as a single U+0020 character.
単独のU+0020キャラクタとして項目の属性もの[値を正常にする]の間隔文字(U+0020)を連載しなければなりません。
Legg & Prager Experimental [Page 69] RFC 4910 Robust XML Encoding Rules July 2007
強健な[69ページ]RFC4910XML符号化規則2007年7月に実験的なLeggとプラーガー
A character item with the [character code] U+000A MUST be serialized as a single U+000A character.
独身のU+000Aキャラクタとして+ [キャラクタコード]U000Aがあるキャラクタ項目を連載しなければなりません。
The white space separating the [target] and [content] in the serialization of a processing instruction item SHALL be exactly one space character (U+0020).
まさに1つの間隔文字が(U+0020)であったなら処理命令項目SHALLの連載における[目標]と[内容]を切り離す余白。
Aside: A processing instruction or comment can only appear in a
CRXER encoding if it is embedded in a Markup value.
傍らに: 処理命令かコメントがそれがMarkup値に埋め込まれるならコード化するCRXERに現れることができるだけです。
6.12.3. Unicode Normalization in XML Version 1.1
6.12.3. XMLバージョン1.1におけるユニコード正常化
XML Version 1.1 recommends, but does not absolutely require, that text be normalized according to Unicode Normalization Form C [UNICODE]. ASN.1 has no similar requirement on abstract values of string types, and ASN.1 canonical encoding rules depend on the code points of characters being preserved.
推薦しますが、XMLバージョン1.1は、ユニコードNormalization Form C[ユニコード]によると、テキストが正常にされるのを絶対に必要としません。 ASN.1には、ストリングタイプの抽象的な値に関するどんな同様の要件もありません、そして、ASN.1の正準な符号化規則は保持されるキャラクタのコード・ポイントに依存します。
To accommodate both requirements, applications SHOULD normalize abstract values of ASN.1 character string types according to Unicode Normalization Form C at the time the values are created, but MUST NOT normalize a previously decoded abstract value of an ASN.1 character string type prior to re-encoding it. An application may, of course, normalize a decoded abstract value for other purposes, such as display to a user.
両方の要件を収容するために、それを再コード化する値が作成されますが、ASN.1文字列タイプの以前に解読された抽象的な値を正常にしてはいけないのを除いたC前に、ユニコードNormalization Formによると、アプリケーションSHOULDはASN.1文字列タイプの抽象的な値を正常にします。 アプリケーションはユーザへのディスプレイなどの他の目的のためにもちろん解読された抽象的な値を正常にするかもしれません。
6.13. Syntax-Based Canonicalization
6.13. 構文ベースのCanonicalization
ASN.1 encoding rules are designed to preserve abstract values, but not to preserve every detail of each transfer syntax that is used. In the case of RXER, this means that the Infoset representation of an abstract value is not necessarily preserved when the abstract value is decoded and re-encoded (regardless of the encoding rules used). However, syntax-based canonicalization for XML documents (e.g., Canonical XML [CXML]) depends on the Infoset of an XML document being preserved. The Infoset representation of an XML document containing the RXER encoding of an ASN.1 abstract value potentially changes if that value is decoded and re-encoded, disrupting the Canonical XML representation. Extra normalization is required if RXER is to be usefully deployed in environments where syntax-based canonicalization is used.
ASN.1符号化規則は、それぞれの使用された転送構文のあらゆる詳細を保存するのではなく、抽象的な価値を守るように設計されています。 RXERの場合では、これは、抽象的な価値のInfoset表現が抽象的な値が解読されるとき、必ず保存されて、再コード化されないことを(規則が使用したコード化にかかわらず)意味します。 しかしながら、XMLドキュメント(例えば、Canonical XML[CXML])のための構文ベースのcanonicalizationは保存されるXMLドキュメントのInfosetによります。 ASN.1の抽象的な価値のRXERコード化を含むXMLドキュメントのInfoset表現は、その値が解読されて、再コード化されるかどうかを潜在的に変えます、Canonical XML表現を中断して。 RXERが構文ベースのcanonicalizationが使用されている環境で有効に配布されるつもりであるなら、付加的な正常化が必要です。
Prior to applying syntax-based canonicalization to an XML document, any element items in the Infoset representation of the document that correspond to the value of an ASN.1 top-level NamedType or have content and attributes that correspond to an ASN.1 abstract value MUST be replaced by the translation of the value according to CRXER.
構文ベースのcanonicalizationをXMLドキュメントに適用する前に、CRXERに応じて、ドキュメントのInfoset表現におけるASN.1トップレベルNamedTypeの値に対応しているか、またはASNの.1の抽象的な価値に対応する内容と属性を持っているどんな要素の品目も価値に関する翻訳に取り替えなければなりません。
Legg & Prager Experimental [Page 70] RFC 4910 Robust XML Encoding Rules July 2007
強健な[70ページ]RFC4910XML符号化規則2007年7月に実験的なLeggとプラーガー
If an application uses Canonical XML but has no knowledge of RXER, then it will not know to normalize RXER encodings. If RXER is deployed into an environment containing such applications, then the Infoset translation for CRXER SHOULD be used for all RXER encodings.
アプリケーションでは、Canonical XMLを使用しますが、RXERに関する知識が全くないと、それはRXER encodingsを正常にするのを知らないでしょう。 RXERが配布されるなら、CRXER SHOULDのためにそのようなアプリケーション、次にInfoset翻訳を含む環境にすべてのRXER encodingsに使用されてください。
7. Transfer Syntax Identifiers
7. 転送構文識別子
7.1. RXER Transfer Syntax
7.1. RXER転送構文
The following OBJECT IDENTIFIER has been assigned by xmled.org to identify the Robust XML Encoding Rules, under an arc assigned to xmled.org by the Internet Assigned Numbers Authority (IANA):
以下のOBJECT IDENTIFIERはRobust XML Encoding Rulesを特定するためにxmled.orgによって割り当てられました、インターネットAssigned民数記Authority(IANA)によってxmled.orgに割り当てられたアークの下で:
{ iso(1) identified-organization(3) dod(6)
internet(1) private(4) enterprise(1)
xmled(21472) asnx(1) encoding(1) rxer(0) }
(1) rxer(0)をコード化するiso(1)の特定された組織(3)dod(6)インターネット(1)個人的な(4)企業(1)xmled(21472) asnx(1)
This OBJECT IDENTIFIER would be used, for example, to describe the transfer syntax for an RXER encoded data-value in an EMBEDDED PDV value.
このOBJECT IDENTIFIERは使用されたでしょう、例えば、RXERのために転送構文を説明するのがEMBEDDED PDV値におけるデータ値をコード化しました。
7.2. CRXER Transfer Syntax
7.2. CRXER転送構文
The following OBJECT IDENTIFIER has been assigned by xmled.org to identify the Canonical Robust XML Encoding Rules, under an arc assigned to xmled.org by the IANA:
以下のOBJECT IDENTIFIERはCanonical Robust XML Encoding Rulesを特定するためにxmled.orgによって割り当てられました、IANAによってxmled.orgに割り当てられたアークの下で:
{ iso(1) identified-organization(3) dod(6)
internet(1) private(4) enterprise(1)
xmled(21472) asnx(1) encoding(1) crxer(1) }
(1) crxer(1)をコード化するiso(1)の特定された組織(3)dod(6)インターネット(1)個人的な(4)企業(1)xmled(21472) asnx(1)
This OBJECT IDENTIFIER would be used, for example, to describe the transfer syntax for a CRXER encoded data-value in an EMBEDDED PDV value.
このOBJECT IDENTIFIERは使用されたでしょう、例えば、CRXERのために転送構文を説明するのがEMBEDDED PDV値におけるデータ値をコード化しました。
8. Relationship to XER
8. XERとの関係
The Robust XML Encoding Rules (RXER) and the XML Encoding Rules (XER) [X.693] are separate, distinctly different and incompatible ASN.1 encoding rules for producing XML markup from ASN.1 abstract values. RXER is therefore unrelated to the XML value notation of X.680 [X.680].
Robust XML Encoding Rules(RXER)とXML Encoding Rules(XER)[X.693]は別々です、ASNの.1の抽象的な値からXMLマーク付けを生産するための明瞭に異なって非互換なASN.1符号化規則。 したがって、RXERはX.680[X.680]のXML値の記法に関係ありません。
This section describes some of the major differences between RXER and XER.
このセクションはRXERとXERの主要な違いのいくつかについて説明します。
Legg & Prager Experimental [Page 71] RFC 4910 Robust XML Encoding Rules July 2007
強健な[71ページ]RFC4910XML符号化規則2007年7月に実験的なLeggとプラーガー
There are essentially two varieties of XER: BASIC-XER (with a canonical form called CANONICAL-XER) and EXTENDED-XER. The significant difference between the two varieties is that XER encoding instructions are used by EXTENDED-XER, but are ignored by BASIC-XER (and therefore by CANONICAL-XER). There isn't a canonical variant of EXTENDED-XER. Characteristics that are common to BASIC-XER and EXTENDED-XER will simply be noted as being characteristics of XER.
本質的には、XERの2つのバラエティーがあります: BASIC-XER(標準形がCANONICAL-XERと呼ばれている)とEXTENDED-XER。 2つのバラエティーの著しい違いは指示をコード化するXERがEXTENDED-XERによって使用されますが、BASIC-XERによって無視されるという(そしてしたがって、CANONICAL-XER)ことです。 EXTENDED-XERの正準な異形がありません。 BASIC-XERとEXTENDED-XERに共通の特性はXERの特性であるとして単に注意されるでしょう。
Elements and attributes are the fundamental discrete structures of an XML document. Not surprisingly, schema languages for XML typically have the means to describe, name, and reference global (i.e., top-level) elements and attributes. Global type definitions are seen more as a convenience for defining the contents of elements and attributes. Traditional ASN.1 has the means to define global types (and other global constructs that support the definition of types) but nothing akin to a global element or attribute definition. The fundamental difference between RXER and XER is in how this omission is addressed.
要素と属性はXMLドキュメントの基本的な離散的な構造です。 当然ながら、XMLのためのスキーマ言語には、説明する手段、名前、参照のグローバルな(すなわち、先端レベル)要素、および属性が通常あります。 グローバルな型定義はさらに要素と属性のコンテンツを定義するための便利と考えられます。 伝統的なASN.1には、グローバルなタイプ(そして、タイプの定義をサポートする他のグローバルな構造物)を定義する手段にもかかわらず、グローバルな要素か属性定義と同系であるものは何もありません。 RXERとXERの基本的な違いがこの省略がどう扱われるかであります。
With XER, type definitions are also regarded as being element definitions by default, or as attribute definitions in the presence of an XER ATTRIBUTE encoding instruction. In some circumstances an anonymous Type is required to define an element, which leads to element names like <BOOLEAN> and <SEQUENCE>. NamedType notation also defines local elements, and there are some curious cases in EXTENDED-XER where NamedType notation can define a global type. So under XER, types can be defined by either Type or NamedType notation, and elements and attributes can also be defined by either Type or NamedType notation.
また、XERと共に、型定義はデフォルトで要素定義である、または指示をコード化するXER ATTRIBUTEの面前で属性定義と見なされます。 いくつかの事情では、匿名のTypeが、要素を定義するのに必要です。(要素は<のブール>と<SEQUENCE>のような要素名につながります)。 また、NamedType記法はローカルの要素を定義します、そして、いくつかの好奇心の強いケースがNamedType記法がグローバルなタイプを定義できるEXTENDED-XERにあります。 それで、XERの下では、TypeかNamedType記法のどちらかでタイプを定義できます、そして、また、TypeかNamedType記法のどちらかで要素と属性を定義できます。
With RXER, types are only defined by Type notation and elements and attributes are only defined by NamedType notation. Global element and attribute definitions are made possible by top-level NamedType notation in an RXER encoding control section.
RXERと共に、タイプはType記法で定義されるだけです、そして、要素と属性はNamedType記法で定義されるだけです。 制御セクションをコード化するRXERのトップレベルNamedType記法でグローバルな要素と属性定義を可能にします。
RXER, with its clean separation of Type notation for types and NamedType notation for elements and attributes, is a better basis than XER for translating an ASN.1 specification into an XML representation (i.e., ASN.X [ASN.X]) or a compatible XML Schema, where type, element, and attribute definitions are also distinctly separate constructs.
RXERはタイプのためのType記法と要素と属性のためのNamedType記法の清潔な分離があるXML表現(すなわち、ASN.X[ASN.X])にASN.1仕様を翻訳するためのXERかコンパチブルXML Schemaより良い基礎です、タイプ、要素、および属性定義が明瞭にも別々の構造物であるところで。
There is usually a requirement on applications specified in ASN.1 to maintain backward compatibility with the encodings generated by previous versions. The encodings in question are typically BER. Even with the backward-compatibility constraint there is still considerable leeway for specification writers to rewrite the earlier specification. For example, they could rename types, factor out an
通常、旧バージョンによって生成されるencodingsとの後方の互換性を維持するためにASN.1で指定されたアプリケーションに関する要件があります。 通常、問題のencodingsはBERです。 仕様作家が以前の仕様を書き直すように、後方の互換性規制があっても、かなりの余裕がまだあります。 例えば、彼らはタイプ、要素アウトを改名するかもしれません。
Legg & Prager Experimental [Page 72] RFC 4910 Robust XML Encoding Rules July 2007
強健な[72ページ]RFC4910XML符号化規則2007年7月に実験的なLeggとプラーガー
in-line type definition as a defined type (or the reverse), or replace a type definition with an equivalent parameterized reference. These changes produce no change to BER, DER, CER [X.690], Packed Encoding Rules (PER) [X.691], or Generic String Encoding Rules (GSER) [GSER] encodings (so specification writers have felt free to make such changes to improve their specification), but can change the names of elements in the XER encoding because XER uses types as element definitions. The RXER encoding is immune to this problem, thus RXER encodings are more stable than XER encodings over successive revisions of an ASN.1 specification (which explains the first 'R' in RXER). This has an obvious benefit for interoperability.
定義がaを定義したインラインタイプは、タイプするか(または、逆)、または型定義を同等なparameterized参照に取り替えます。 これらの変化は、BER、DER、CER[X.690]、Packed Encoding Rules(PER)[X.691]、またはGeneric String Encoding Rules(GSER)[GSER]encodings(仕様作家がそれらの仕様を改良するために遠慮なくそのような変更を行って)への変化を全く発生させませんが、XERが要素定義としてタイプを使用するので、XERコード化で要素の名前を変えることができます。 RXERコード化はこの問題に免疫がある、その結果、ASN.1仕様(最初に、RXERの'R'がわかる)の連続した改正の上では、RXER encodingsがXER encodingsより安定しています。 これには、相互運用性のための明白な利益があります。
RXER has special provisions for encoding values of the QName and Markup types. QName is used to hold qualified names and Markup can be used to hold arbitrary untyped markup. XER doesn't recognize any special types like these, but it is possible to get the same effects as RXER's QName and Markup types by using XER encoding instructions. Since CANONICAL-XER ignores encoding instructions, this means that under XER an application can either support qualified names and untyped markup, or support canonical XML encodings, but not both. In contrast, CRXER has canonicalization rules for qualified names and for Markup. Furthermore, EXTENDED-XER does not address the issues of normalization of untyped data for other ASN.1 canonical encoding rules (e.g., for DER; see Section 4.1.2) or normalization of XML encodings for syntax-based canonicalization (e.g., for Canonical XML; see Section 6.13).
RXERには、QNameの値をコード化するための特別条項があります、そして、Markupはタイプします。 適切な名前を保持するのにQNameを使用します、そして、任意の非タイプされたマーク付けを保持するのにMarkupを使用できます。 XERは、どんな特別なタイプもこれらが好きであると認めませんが、RXERのQNameと同じ効果を得るのが可能であり、Markupは、指示をコード化するXERを使用することによって、タイプします。 CANONICAL-XERがコード化指示を無視するので、これは、アプリケーションがXERの下では、適切な名前をサポートして、マーク付けを非タイプしたか、または正準なXML encodingsをサポートすることができることを意味しますが、ともに意味するというわけではありません。 対照的に、CRXERには、適切な名前とMarkupのためのcanonicalization規則があります。 その上、EXTENDED-XERは他のASN.1の正準な符号化規則(例えば、DERのために; セクション4.1.2を見る)のための非タイプされたデータの正常化か構文ベースのcanonicalizationのためのXML encodingsの正常化の問題を扱いません(例えば、Canonical XMLのために; セクション6.13を見てください)。
Both EXTENDED-XER and RXER use encoding instructions to define attributes, union types, and list types, among other things. Since CANONICAL-XER ignores encoding instructions, this means that under XER an application must choose between making use of attributes, union types, list types, etc., or supporting canonical XML encodings. In contrast, the canonicalization rules for CRXER encompass all the encoding instructions for RXER.
EXTENDED-XERとRXER使用の両方が属性を定義するために指示をコード化して、組合はタイプされます、そして、リストは特にタイプされます。 CANONICAL-XERがコード化指示を無視するので、これは、属性、ユニオン式、リストタイプなどを利用するか、または正準なXML encodingsをサポートするときXERの下では、アプリケーションが選ばれなければならないことを意味します。 対照的に、CRXERのためのcanonicalization規則はRXERのためにすべてのコード化指示を包含します。
9. Security Considerations
9. セキュリティ問題
RXER does not necessarily enable the exact BER octet encoding of values of the TeletexString, VideotexString, GraphicString, or GeneralString types to be reconstructed, so a transformation from DER to RXER and back to DER may not reproduce the original DER encoding. This is a result of inadequate normalization of values of these string types in DER. A character in a TeletexString value (for example) that corresponds to a specific ISO 10646 character can be encoded for BER in a variety of ways that are indistinguishable in an
RXERは必ずTeletexStringの値の正確なBER八重奏コード化を可能にするというわけではありません、とVideotexString、GraphicString、またはGeneralStringが再建されるためにタイプするので、DERからRXERまでDERへの変換はオリジナルのDERコード化を再生させないかもしれません。 これはDERのこれらのストリングタイプの値の不十分な正常化の結果です。 さまざまな中で区別がつかない方法でBERのために特定のISO10646キャラクタに文通されるTeletexString値(例えば)におけるキャラクタをコード化できます。
Legg & Prager Experimental [Page 73] RFC 4910 Robust XML Encoding Rules July 2007
強健な[73ページ]RFC4910XML符号化規則2007年7月に実験的なLeggとプラーガー
RXER re-encoding of the TeletexString value. DER does not mandate one of these possible character encodings in preference to all others.
TeletexString価値のRXER再コード化。 DERはすべての他のものに優先してこれらの可能な文字符号化の1つを強制しません。
Because of the above, RXER MUST NOT be used to re-encode, whether for storage or transmission, ASN.1 abstract values whose original DER or CER encoding must be recoverable, and whose type definitions involve the TeletexString, VideotexString, GraphicString, or GeneralString type. Such recovery is needed for the verification of digital signatures. In such cases, protocols ought to use DER or a DER- reversible encoding. In other cases where ASN.1 canonical encoding rules are used, values of the Markup type must be normalized as described in Section 4.1.2.
上記では、RXER MUST NOTがストレージかトランスミッションにかかわらず再エンコードに使用されて、オリジナルのDERかCERコード化が回復可能であるに違いなく、型定義がTeletexStringにかかわるASN.1の抽象的な値、VideotexString、GraphicString、またはGeneralStringがタイプします。 そのような回復がデジタル署名の検証に必要です。 そのような場合、プロトコルはDERかリバーシブルのDERコード化を使用するべきです。 ASN.1の正準な符号化規則が使用されている他の場合では、セクション4.1.2で説明されるようにMarkupタイプの値を正常にしなければなりません。
A transformation from CRXER to BER and back to CRXER does reproduce the original CRXER encoding, therefore it is safe to use BER, DER, or CER to re-encode ASN.1 abstract values whose original CRXER encoding must be recoverable.
CRXERからBERまでCRXERへの変換はオリジナルのCRXERコード化を再生させます、したがって、オリジナルのCRXERコード化が回復可能であるに違いない再エンコードASN.1の抽象的な値にBER、DER、またはCERを使用するのが安全です。
Digital signatures may also be calculated on the Canonical XML representation of an XML document. If RXER encodings appear in such documents, then applications must normalize the encodings as described in Section 6.13.
また、デジタル署名はXMLドキュメントのCanonical XML表現のときに計算されるかもしれません。 RXER encodingsがそのようなドキュメントに現れるなら、アプリケーションはセクション6.13で説明されるようにencodingsを正常にしなければなりません。
The null character (U+0000) cannot be represented in XML and hence cannot be transmitted in an RXER encoding. Null characters in abstract values of ASN.1 string types will be dropped if the values are RXER encoded; therefore, RXER MUST NOT be used by applications that attach significance to the null character.
ヌル文字(U+0000)をXMLに表すことができないで、したがって、RXERコード化で伝えることができません。 ASN.1ストリングタイプの抽象的な値におけるヌル文字は値がコード化されたRXERであるなら下げられるでしょう。 したがって、RXER MUST NOT、意味をヌル文字に付けるアプリケーションで、使用されてください。
When interpreting security-sensitive fields, and in particular fields used to grant or deny access, implementations MUST ensure that any comparisons are done on the underlying abstract value, regardless of the particular encoding used. Comparisons of Markup values MUST operate as though the values have been normalized as specified in Section 4.1.2.
セキュリティ敏感な分野、および特にアクセスを承諾するか、または拒絶するのに使用される分野を解釈するとき、実装は、基本的な抽象的な値でどんな比較もするのを確実にしなければなりません、使用される特定のコード化にかかわらず。 まるで値がセクション4.1.2で指定されるように正常にされたかのようにMarkup値の比較は作動しなければなりません。
10. Acknowledgements
10. 承認
The technology described in this document is the product of a research project begun jointly by Adacel Technologies Limited and Deakin University, and subsequently refined and completed by eB2Bcom.
本書では説明された技術はeB2BcomによってAdacel Technologies株式会社とディーキン大学によって共同で始められて、次に、洗練されて、完成した研究計画の製品です。
Legg & Prager Experimental [Page 74] RFC 4910 Robust XML Encoding Rules July 2007
強健な[74ページ]RFC4910XML符号化規則2007年7月に実験的なLeggとプラーガー
11. IANA Considerations
11. IANA問題
The IANA has registered a new XML namespace in accordance with RFC 3688 [XMLREG].
RFC3688[XMLREG]によると、IANAは新しいXML名前空間を登録しました。
URI: urn:ietf:params:xml:ns:asnx
URI: つぼ:ietf:params:xml:ナノ秒: asnx
Registrant Contact: Steven Legg <steven.legg@eb2bcom.com>
記入者接触: スティーブン Legg <steven.legg@eb2bcom.com 、gt。
XML: None
XML: なし
12. References
12. 参照
12.1. Normative References
12.1. 引用規格
[BCP14] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[BCP14] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO
10646", RFC 3629, November 2003.
[UTF-8]Yergeau、2003年11月のF.、「UTF-8、ISO10646の変換形式」RFC3629。
[XMLREG] Mealling, M., "The IETF XML Registry", RFC 3688, January
2004.
[XMLREG] 食事、M.、「IETF XML登録」、RFC3688、2004年1月。
[URI] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", STD 66, RFC
3986, January 2005.
[URI]バーナーズ・リー、T.、フィールディング、R.、およびL.Masinter、「Uniform Resource Identifier(URI):」 「ジェネリック構文」、STD66、RFC3986、2005年1月。
[RXEREI] Legg, S., "Encoding Instructions for the Robust XML
Encoding Rules (RXER)", RFC 4911, July 2007.
[RXEREI] Legg、S.、「強健なXML符号化規則(RXER)のために指示をコード化します」、RFC4911、2007年7月。
[ASN.X] Legg, S., "Abstract Syntax Notation X (ASN.X)", RFC 4912,
July 2007.
[ASN.X] Legg、S.、「抽象構文記法X(ASN.X)」、RFC4912、2007年7月。
[X.680] ITU-T Recommendation X.680 (07/02) | ISO/IEC 8824-1,
Information technology - Abstract Syntax Notation One
(ASN.1): Specification of basic notation.
[X.680]ITU-T推薦X.680(07/02)| ISO/IEC8824-1、情報技術--抽象的なSyntax Notation One(ASN.1): 基本的な記法の仕様。
[X.680-1] ITU-T Recommendation X.680 (2002) Amendment 1 (10/03) |
ISO/IEC 8824-1:2002/Amd 1:2004, Support for EXTENDED-XER.
[X.680-1]ITU-T推薦X.680(2002)修正1(10/03)| ISO/IEC8824-1: 2002/Amd1:2004、拡張XERのサポート。
[X.681] ITU-T Recommendation X.681 (07/02) | ISO/IEC 8824-2,
Information technology - Abstract Syntax Notation One
(ASN.1): Information object specification.
[X.681]ITU-T推薦X.681(07/02)| ISO/IEC8824-2、情報技術--抽象的なSyntax Notation One(ASN.1): 情報オブジェクト仕様。
[X.682] ITU-T Recommendation X.682 (07/02) | ISO/IEC 8824-3,
Information technology - Abstract Syntax Notation One
(ASN.1): Constraint specification.
[X.682]ITU-T推薦X.682(07/02)| ISO/IEC8824-3、情報技術--抽象的なSyntax Notation One(ASN.1): 規制仕様。
Legg & Prager Experimental [Page 75] RFC 4910 Robust XML Encoding Rules July 2007
強健な[75ページ]RFC4910XML符号化規則2007年7月に実験的なLeggとプラーガー
[X.683] ITU-T Recommendation X.683 (07/02) | ISO/IEC 8824-4,
Information technology - Abstract Syntax Notation One
(ASN.1): Parameterization of ASN.1 specifications.
[X.683]ITU-T推薦X.683(07/02)| ISO/IEC8824-4、情報技術--抽象的なSyntax Notation One(ASN.1): ASN.1仕様のパラメタリゼーション。
[X.690] ITU-T Recommendation X.690 (07/02) | ISO/IEC 8825-1,
Information technology - ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules
(DER).
[X.690]ITU-T推薦X.690(07/02)| ISO/IEC8825-1、情報技術--ASN.1符号化規則: 基本的なコード化の仕様は(BER)、正準な符号化規則(CER)、および顕著な符号化規則(DER)を統治します。
[UCS] ISO/IEC 10646-1:2000, Information technology - Universal
Multiple-Octet Coded Character Set (UCS) - Part 1:
Architecture and Basic Multilingual Plane.
情報技術--普遍的なMultiple-八重奏Coded文字コード(UCS)--[UCS]ISO/IEC10646-1:2000、第1部: アーキテクチャと基本多言語水準。
[UNICODE] The Unicode Consortium, "The Unicode Standard, Version
4.0", Boston, MA, Addison-Wesley Developers Press, 2003.
ISBN 0-321-18578-1.
[ユニコード] ユニコード共同体、「ユニコード規格、バージョン4インチ、ボストン(MA)アディソン-ウエスリー開発者プレス、2003。」 ISBN0-321-18578-1。
[XML10] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E. and
F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fourth
Edition)", W3C Recommendation,
http://www.w3.org/TR/2006/REC-xml-20060816, August 2006.
[XML10] ロバの鳴き声とT.とパオリとJ.とSperberg-マックィーンとC.とMalerとE.とF.Yergeau、「拡張マークアップ言語(XML)1.0(第4版)」、W3C推薦、 http://www.w3.org/TR/2006/REC-xml-20060816 (2006年8月)。
[XML11] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E.,
Yergeau, F., and J. Cowan, "Extensible Markup Language
(XML) 1.1 (Second Edition)", W3C Recommendation,
http://www.w3.org/TR/2006/REC-xml11-20060816, August 2006.
[XML11]は、T.、パオリ、J.、Sperberg-マックィーン、C.、Maler、E.、Yergeau、F.、およびJ.カウァン、「拡張マークアップ言語(XML)1.1(第2版)」をいななかせます、W3C推薦、 http://www.w3.org/TR/2006/REC-xml11-20060816 、2006年8月。
[XMLNS10] Bray, T., Hollander, D., Layman, A., and R. Tobin,
"Namespaces in XML 1.0 (Second Edition)", W3C
Recommendation,
http://www.w3.org/TR/2006/REC-xml-names-20060816, August
2006.
[XMLNS10]は、T.、オランダ人、D.、俗人、A.、およびR.トビン、「XML1.0(第2版)の名前空間」をいななかせます、W3C推薦、 http://www.w3.org/TR/2006/REC-xml-names-20060816 、2006年8月。
[XMLNS11] Bray, T., Hollander, D., Layman, A. and R. Tobin,
"Namespaces in XML 1.1 (Second Edition)", W3C
Recommendation,
http://www.w3.org/TR/2006/REC-xml-names11-20060816, August
2006.
[XMLNS11]は、T.とオランダ人とD.と俗人とA.とR.トビン、「XML1.1(第2版)の名前空間」をいななかせます、W3C推薦、 http://www.w3.org/TR/2006/REC-xml-names11-20060816 、2006年8月。
[INFOSET] Cowan, J. and R. Tobin, "XML Information Set (Second
Edition)", W3C Recommendation,
http://www.w3.org/TR/2004/REC-xml-infoset-20040204,
February 2004.
[INFOSET] カウァンとJ.とR.トビン、「XML一組の情報(第2版)」、W3C推薦、 http://www.w3.org/TR/2004/REC-xml-infoset-20040204 、2004年2月。
Legg & Prager Experimental [Page 76] RFC 4910 Robust XML Encoding Rules July 2007
強健な[76ページ]RFC4910XML符号化規則2007年7月に実験的なLeggとプラーガー
[XSD1] Thompson, H., Beech, D., Maloney, M. and N. Mendelsohn,
"XML Schema Part 1: Structures Second Edition", W3C
Recommendation,
http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/,
October 2004.
[XSD1] トンプソン、H.、ぶな、D.、マローニー、M.、およびN.メンデルゾーン、「XML図式第1部:」 「構造第2版」、W3C推薦、 http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/ 、2004年10月。
12.2. Informative References
12.2. 有益な参照
[GSER] Legg, S., "Generic String Encoding Rules (GSER) for ASN.1
Types", RFC 3641, October 2003.
[GSER]Legg、2003年10月のS.、「ASN.1タイプのためのジェネリックストリング符号化規則(GSER)」RFC3641。
[X.691] ITU-T Recommendation X.691 (07/02) | ISO/IEC 8825-4:2002,
Information technology - ASN.1 encoding rules:
Specification of Packed Encoding Rules (PER).
[X.691]ITU-T推薦X.691(07/02)| ISO/IEC8825-4: 2002、情報技術--ASN.1符号化規則: 詰まっているコード化の仕様は(PER)を統治します。
[X.693] ITU-T Recommendation X.693 (12/01) | ISO/IEC 8825-4:2002,
Information technology - ASN.1 encoding rules: XML
encoding rules (XER).
[X.693]ITU-T推薦X.693(12/01)| ISO/IEC8825-4: 2002、情報技術--ASN.1符号化規則: XMLコード化は(XER)を統治します。
[XSD2] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes
Second Edition", W3C Recommendation,
http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/,
October 2004.
[XSD2] ビロン、P.、およびA.Malhotra、「XML図式第2部:」 「データ型式第2版」、W3C推薦、 http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/ 、2004年10月。
[CXML] Boyer, J., "Canonical XML Version 1.0", W3C
Recommendation,
http://www.w3.org/TR/2001/REC-xml-c14n-20010315, March
2001.
[CXML]ボワイエ、J.、「正準なXML、バージョン1インチ、W3C推薦、 http://www.w3.org/TR/2001/REC-xml-c14n-20010315 、2001インチ年3月。
Legg & Prager Experimental [Page 77] RFC 4910 Robust XML Encoding Rules July 2007
強健な[77ページ]RFC4910XML符号化規則2007年7月に実験的なLeggとプラーガー
Appendix A. Additional Basic Definitions Module
付録のA.の追加基本的な定義モジュール
This appendix is normative.
この付録は規範的です。
AdditionalBasicDefinitions
{ iso(1) identified-organization(3) dod(6)
internet(1) private(4) enterprise(1)
xmled(21472) asnx(1) module(0) basic(0) }
AdditionalBasicDefinitionsiso(1)の特定された組織(3)dod(6)のインターネットの(1)の個人的な(4)企業(1)xmled(21472) asnx(1)モジュール(0)基本的な(0)
-- Copyright (C) The IETF Trust (2007). This version of -- this ASN.1 module is part of RFC 4910; see the RFC itself -- for full legal notices. -- -- Regarding this ASN.1 module or any portion of it, the authors -- make no guarantees and are not responsible for any damage -- resulting from its use. The authors grant irrevocable permission -- to anyone to use, modify, and distribute it in any way that does -- not diminish the rights of anyone else to use, modify, and -- distribute it, provided that redistributed derivative works do -- not contain misleading author or version information. -- Derivative works need not be licensed under similar terms.
-- IETFが信じる著作権(C)(2007)。 このバージョン、--このASN.1モジュールはRFC4910の一部です。 完全な法定の通知に関してRFC自身を見てください。 -- -- このASN.1モジュールかそれのどんな部分、作者も--使用から生じて、保証を全くしないで、またどんな損害にも責任がないと見なします。 それを分配してください、そして、再配付された派生物が働いていれば、してください。作者が、何らかの方法でそれを使用して、変更して、分配するそれがする人はだれへのも呼び戻せない許可--使用する他の誰の権利も減少させないのを与える、変更、--、--作者かバージョンが情報であるとミスリードしながら、含んでいません。 -- 派生している作品は同類項に基づき認可される必要はありません。
DEFINITIONS RXER INSTRUCTIONS AUTOMATIC TAGS EXTENSIBILITY IMPLIED ::= BEGIN
定義RXER指示オートマチックは含意された伸展性にタグ付けをします:、:= 始まってください。
Markup ::= CHOICE {
text SEQUENCE {
prolog UTF8String (SIZE(1..MAX)) OPTIONAL,
prefix NCName OPTIONAL,
attributes UTF8String (SIZE(1..MAX)) OPTIONAL,
content UTF8String (SIZE(1..MAX)) OPTIONAL
}
}
マークアップ:、:= 選択テキストSEQUENCE、プロローグUTF8String(SIZE(1..MAX))OPTIONAL、NCName OPTIONALを前に置いてください、属性UTF8String(SIZE(1..MAX))OPTIONAL、内容UTF8String(SIZE(1..MAX))OPTIONAL
AnyURI ::= UTF8String (CONSTRAINED BY
{ -- conforms to the format of a URI -- })
AnyURI:、:= UTF8String(CONSTRAINED BY、--URIの形式に従います--、)
NCName ::= UTF8String (CONSTRAINED BY
{ -- conforms to the NCName production of
-- Namespaces in XML 1.0 -- })
NCName:、:= UTF8String(CONSTRAINED BY、--、NCName生産に従う、--XML1.0の名前空間--、)
Name ::= UTF8String (CONSTRAINED BY
{ -- conforms to the Name production of XML -- })
以下を命名してください:= UTF8String(CONSTRAINED BY、--XMLのName生産に従います--、)
Legg & Prager Experimental [Page 78] RFC 4910 Robust XML Encoding Rules July 2007
強健な[78ページ]RFC4910XML符号化規則2007年7月に実験的なLeggとプラーガー
QName ::= SEQUENCE {
namespace-name AnyURI OPTIONAL,
local-name NCName
}
QName:、:= 系列名前空間名のAnyURI OPTIONAL、地方名NCName
ENCODING-CONTROL RXER
コード化しているコントロールRXER
TARGET-NAMESPACE "urn:ietf:params:xml:ns:asnx" PREFIX "asnx"
目標名前空間「つぼ:ietf:params:xml:ナノ秒: asnx」接頭語"asnx"
COMPONENT context [ATTRIBUTE] [LIST] SEQUENCE OF prefix NCName
COMPONENT文脈[ATTRIBUTE][LIST]SEQUENCE OF接頭語NCName
END
終わり
Authors' Addresses
作者のアドレス
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
Dr. Daniel Prager
ダニエル・プラーガー博士
EMail: dap@austhink.com
メール: dap@austhink.com
Legg & Prager Experimental [Page 79] RFC 4910 Robust XML Encoding Rules July 2007
強健な[79ページ]RFC4910XML符号化規則2007年7月に実験的なLeggとプラーガー
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 & Prager Experimental [Page 80]
LeggとプラーガーExperimentalです。[80ページ]
一覧
スポンサーリンク
