[要約] RFC 7940は、XMLを使用してラベル生成ルールセットを表現するための仕様です。このRFCの目的は、異なるネットワークデバイス間でラベル生成ルールセットを共有するための標準化を提供することです。
Internet Engineering Task Force (IETF) K. Davies
Request for Comments: 7940 ICANN
Category: Standards Track A. Freytag
ISSN: 2070-1721 ASMUS, Inc.
August 2016
Representing Label Generation Rulesets Using XML
XMLを使用したラベル生成ルールセットの表現
Abstract
概要
This document describes a method of representing rules for validating identifier labels and alternate representations of those labels using Extensible Markup Language (XML). These policies, known as "Label Generation Rulesets" (LGRs), are used for the implementation of Internationalized Domain Names (IDNs), for example. The rulesets are used to implement and share that aspect of policy defining which labels and Unicode code points are permitted for registrations, which alternative code points are considered variants, and what actions may be performed on labels containing those variants.
このドキュメントでは、Extensible Markup Language（XML）を使用して、識別子ラベルとそれらのラベルの代替表現を検証するためのルールを表現する方法について説明します。 「ラベル生成ルールセット」（LGR）として知られるこれらのポリシーは、たとえば、国際化ドメイン名（IDN）の実装に使用されます。ルールセットを使用して、登録に許可されるラベルとUnicodeコードポイント、バリアントと見なされる代替コードポイント、およびそれらのバリアントを含むラベルで実行できるアクションを定義するポリシーのその側面を実装および共有します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7940.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7940で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................4
2. Design Goals ....................................................5
3. Normative Language ..............................................6
4. LGR Format ......................................................6
4.1. Namespace ..................................................7
4.2. Basic Structure ............................................7
4.3. Metadata ...................................................8
4.3.1. The "version" Element ...............................8
4.3.2. The "date" Element ..................................9
4.3.3. The "language" Element ..............................9
4.3.4. The "scope" Element ................................10
4.3.5. The "description" Element ..........................10
4.3.6. The "validity-start" and "validity-end" Elements ...11
4.3.7. The "unicode-version" Element ......................11
4.3.8. The "references" Element ...........................12
5. Code Points and Variants .......................................13
5.1. Sequences .................................................14
5.2. Conditional Contexts ......................................15
5.3. Variants ..................................................16
5.3.1. Basic Variants .....................................16
5.3.2. The "type" Attribute ...............................17
5.3.3. Null Variants ......................................18
5.3.4. Variants with Reflexive Mapping ....................19
5.3.5. Conditional Variants ...............................20
5.4. Annotations ...............................................22
5.4.1. The "ref" Attribute ................................22
5.4.2. The "comment" Attribute ............................23
5.5. Code Point Tagging ........................................23
6. Whole Label and Context Evaluation .............................23
6.1. Basic Concepts ............................................23
6.2. Character Classes .........................................25
6.2.1. Declaring and Invoking Named Classes ...............25
6.2.2. Tag-Based Classes ..................................26
6.2.3. Unicode Property-Based Classes .....................26
6.2.4. Explicitly Declared Classes ........................28
6.2.5. Combined Classes ...................................29
6.3. Whole Label and Context Rules .............................30
6.3.1. The "rule" Element .................................31
6.3.2. The Match Operators ................................32
6.3.3. The "count" Attribute ..............................33
6.3.4. The "name" and "by-ref" Attributes .................34
6.3.5. The "choice" Element ...............................34
6.3.6. Literal Code Point Sequences .......................35
6.3.7. The "any" Element ..................................35
6.3.8. The "start" and "end" Elements .....................35
6.3.9. Example Context Rule from IDNA Specification .......36
6.4. Parameterized Context or When Rules .......................37
6.4.1. The "anchor" Element ...............................37
6.4.2. The "look-behind" and "look-ahead" Elements ........38
6.4.3. Omitting the "anchor" Element ......................40
7. The "action" Element ...........................................40
7.1. The "match" and "not-match" Attributes ....................41
7.2. Actions with Variant Type Triggers ........................41
7.2.1. The "any-variant", "all-variants", and
"only-variants" Attributes .........................41
7.2.2. Example from Tables in the Style of RFC 3743 .......44
7.3. Recommended Disposition Values ............................45
7.4. Precedence ................................................45
7.5. Implied Actions ...........................................45
7.6. Default Actions ...........................................46
8. Processing a Label against an LGR ..............................47
8.1. Determining Eligibility for a Label .......................47
8.1.1. Determining Eligibility Using Reflexive
Variant Mappings ...................................47
8.2. Determining Variants for a Label ..........................48
8.3. Determining a Disposition for a Label or Variant Label ....49
8.4. Duplicate Variant Labels ..................................50
8.5. Checking Labels for Collision .............................50
9. Conversion to and from Other Formats ...........................51
10. Media Type ....................................................51
11. IANA Considerations ...........................................52
11.1. Media Type Registration ..................................52
11.2. URN Registration .........................................53
11.3. Disposition Registry .....................................53
12. Security Considerations .......................................54
12.1. LGRs Are Only a Partial Remedy for Problem Space .........54
12.2. Computational Expense of Complex Tables ..................54
13. References ....................................................55
13.1. Normative References .....................................55
13.2. Informative References ...................................56
Appendix A. Example Tables ........................................58
Appendix B. How to Translate Tables Based on RFC 3743 into the
XML Format ............................................63
Appendix C. Indic Syllable Structure Example ......................68
C.1. Reducing Complexity .......................................70
Appendix D. RELAX NG Compact Schema ...............................71
Acknowledgements ..................................................82
Authors' Addresses ................................................82
This document specifies a method of using Extensible Markup Language (XML) to describe Label Generation Rulesets (LGRs). LGRs are algorithms used to determine whether, and under what conditions, a given identifier label is permitted, based on the code points it contains and their context. These algorithms comprise a list of permissible code points, variant code point mappings, and a set of rules that act on the code points and mappings. LGRs form part of an administrator's policies. In deploying Internationalized Domain Names (IDNs), they have also been known as IDN tables or variant tables.
このドキュメントでは、Extensible Markup Language（XML）を使用してラベル生成ルールセット（LGR）を記述する方法を指定します。 LGRは、含まれるコードポイントとそのコンテキストに基づいて、特定の識別子ラベルが許可されるかどうか、およびどのような条件下で許可されるかを決定するために使用されるアルゴリズムです。これらのアルゴリズムは、許容コードポイントのリスト、バリアントコードポイントマッピング、およびコードポイントとマッピングに作用する一連のルールで構成されます。 LGRは、管理者のポリシーの一部です。国際化ドメイン名（IDN）の展開では、IDNテーブルまたはバリアントテーブルとも呼ばれます。
There are other kinds of policies relating to labels that are not normally covered by LGRs and are therefore not necessarily representable by the XML format described here. These include, but are not limited to, policies around trademarks, or prohibition of fraudulent or objectionable words.
通常、LGRでカバーされないラベルに関連する他の種類のポリシーがあり、ここで説明するXML形式で必ずしも表現できない場合があります。これらには、商標に関するポリシー、または詐欺的または不快な言葉の禁止が含まれますが、これらに限定されません。
Administrators of the zones for top-level domain registries have historically published their LGRs using ASCII text or HTML. The formatting of these documents has been loosely based on the format used for the Language Variant Table described in [RFC3743]. [RFC4290] also provides a "model table format" that describes a similar set of functionality. Common to these formats is that the algorithms used to evaluate the data therein are implicit or specified elsewhere.
トップレベルドメインレジストリのゾーンの管理者は、これまでASCIIテキストまたはHTMLを使用してLGRを公開してきました。これらのドキュメントのフォーマットは、[RFC3743]で説明されている言語バリアントテーブルに使用されているフォーマットに大まかに基づいています。 [RFC4290]は、同様の機能セットを記述する「モデルテーブル形式」も提供します。これらの形式に共通するのは、そのデータを評価するために使用されるアルゴリズムが暗黙的であるか、他の場所で指定されていることです。
Through the first decade of IDN deployment, experience has shown that LGRs derived from these formats are difficult to consistently implement and compare, due to their differing formats. A universal format, such as one using a structured XML format, will assist by improving machine readability, consistency, reusability, and maintainability of LGRs.
IDN導入の最初の10年間を通じて、これらの形式から派生したLGRは形式が異なるため、一貫して実装および比較することが困難であることが経験により示されています。構造化されたXML形式を使用する形式などの汎用形式は、LGRのマシンの可読性、一貫性、再利用性、および保守性を向上させるのに役立ちます。
When used to represent a simple list of permitted code points, the format is quite straightforward. At the cost of some complexity in the resulting file, it also allows for an implementation of more sophisticated handling of conditional variants that reflects the known requirements of current zone administrator policies.
許可されたコードポイントの単純なリストを表すために使用する場合、形式は非常に簡単です。結果のファイルは多少複雑になりますが、現在のゾーン管理者ポリシーの既知の要件を反映する条件付きバリアントのより高度な処理を実装することもできます。
Another feature of this format is that it allows many of the algorithms to be made explicit and machine implementable. A remaining small set of implicit algorithms is described in this document to allow commonality in implementation.
この形式のもう1つの特徴は、アルゴリズムの多くを明示的にしてマシンで実装できるようにすることです。残りの暗黙のアルゴリズムの小さなセットは、実装の共通性を可能にするために、このドキュメントで説明されています。
While the predominant usage of this specification is to represent IDN label policy, the format is not limited to IDN usage and may also be used for describing ASCII domain name label rulesets, or other types of identifier labels beyond those used for domain names.
この仕様の主な使用法はIDNラベルポリシーを表すことですが、形式はIDNの使用法に限定されず、ASCIIドメイン名ラベルルールセット、またはドメイン名に使用されるもの以外の他のタイプの識別子ラベルの記述にも使用できます。
The following goals informed the design of this format:
次の目標は、このフォーマットの設計に影響を与えました。
o The format needs to be implementable in a reasonably straightforward manner in software.
o この形式は、ソフトウェアでかなり簡単な方法で実装できる必要があります。
o The format should be able to be automatically checked for formatting errors, so that common mistakes can be caught.
o よくある間違いを見つけることができるように、フォーマットはフォーマットエラーを自動的にチェックできる必要があります。
o An LGR needs to be able to express the set of valid code points that are allowed for registration under a specific administrator's policies.
o LGRは、特定の管理者のポリシーに基づいて登録が許可されている一連の有効なコードポイントを表現できる必要があります。
o An LGR needs to be able to express computed alternatives to a given identifier based on mapping relationships between code points, whether one-to-one or many-to-many. These computed alternatives are commonly known as "variants".
o LGRは、1対1または多対多のコードポイント間のマッピング関係に基づいて、特定の識別子の計算された代替を表現できる必要があります。これらの計算された代替案は、一般的に「バリアント」として知られています。
o Variant code points should be able to be tagged with explicit dispositions or categories that can be used to support registry policy (such as whether to allocate the computed variant or to merely block it from usage or registration).
o バリアントコードポイントは、レジストリポリシー（計算されたバリアントを割り当てるか、使用または登録から単にブロックするかなど）をサポートするために使用できる明示的な処理またはカテゴリでタグ付けできる必要があります。
o Variants and code points must be able to be stipulated based on contextual information. For example, some variants may only be applicable when they follow a certain code point or when the code point is displayed in a specific presentation form.
o バリアントとコードポイントは、コンテキスト情報に基づいて規定できる必要があります。たとえば、一部のバリアントは、特定のコードポイントに従う場合、またはコードポイントが特定のプレゼンテーションフォームに表示される場合にのみ適用できます。
o The data contained within an LGR must be able to be interpreted unambiguously, so that independent implementations that utilize the contents will arrive at the same results.
o LGRに含まれるデータは、明確に解釈できる必要があります。これにより、コンテンツを利用する独立した実装が同じ結果を得ることができます。
o To the largest extent possible, policy rules should be able to be specified in the XML format without relying on hidden or built-in algorithms in implementations.
o ポリシールールは、可能な限り、実装で非表示または組み込みのアルゴリズムに依存することなく、XML形式で指定できる必要があります。
o LGRs should be suitable for comparison and reuse, such that one could easily compare the contents of two or more to see the differences, to merge them, and so on.
o LGRは、比較と再利用に適している必要があります。これにより、2つ以上のコンテンツを簡単に比較して、違いを確認したり、マージしたりできるようになります。
o As many existing IDN tables as practicable should be able to be migrated to the LGR format with all applicable interpretation logic retained.
o 可能な限り多くの既存のIDNテーブルは、適用可能なすべての解釈ロジックを保持したまま、LGR形式に移行できる必要があります。
These requirements are partly derived from reviewing the existing corpus of published IDN tables, plus the requirements of ICANN's work to implement an LGR for the DNS root zone [LGR-PROCEDURE]. In particular, Section B of that document identifies five specific requirements for an LGR methodology.
これらの要件の一部は、公開されたIDNテーブルの既存のコーパスと、DNSルートゾーンのLGRを実装するためのICANNの作業[LGR-PROCEDURE]の要件のレビューから導き出されています。特に、そのドキュメントのセクションBは、LGR方法論の5つの特定の要件を識別します。
The syntax and rules in [RFC5892] and [RFC3743] were also reviewed.
[RFC5892]と[RFC3743]の構文とルールもレビューされました。
It is explicitly not the goal of this format to stipulate what code points should be listed in an LGR by a zone administrator. Which registration policies are used for a particular zone are outside the scope of this memo.
ゾーン管理者がLGRにリストする必要のあるコードポイントを規定することは、この形式の目的ではありません。特定のゾーンにどの登録ポリシーが使用されるかは、このメモの範囲外です。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
An LGR is expressed as a well-formed XML document [XML] that conforms to the schema defined in Appendix D.
LGRは、付録Dで定義されているスキーマに準拠した整形式のXMLドキュメント[XML]として表現されます。
As XML is case sensitive, an LGR must be authored with the correct casing. For example, the XML element names MUST be in lowercase as described in this specification, and matching of attribute values is only performed in a case-sensitive manner.
XMLでは大文字と小文字が区別されるため、LGRは正しい大文字小文字で作成する必要があります。たとえば、XML要素名はこの仕様で説明されているように小文字である必要があり、属性値の照合は大文字と小文字を区別する方法でのみ実行されます。
A document that is not well-formed, is non-conforming, or violates other constraints specified in this specification MUST be rejected.
整形式ではない、非準拠である、またはこの仕様で指定された他の制約に違反するドキュメントは、拒否されなければなりません（MUST）。
The XML Namespace URI is "urn:ietf:params:xml:ns:lgr-1.0".
XML名前空間URIは「urn：ietf：params：xml：ns：lgr-1.0」です。
See Section 11.2 for more information.
詳細については、セクション11.2を参照してください。
The basic XML framework of the document is as follows:
ドキュメントの基本的なXMLフレームワークは次のとおりです。
<?xml version="1.0"?>
<lgr xmlns="urn:ietf:params:xml:ns:lgr-1.0">
...
</lgr>
The "lgr" element contains up to three sub-elements or sections. First is an optional "meta" element that contains all metadata associated with the LGR, such as its authorship, what it is used for, implementation notes, and references. This is followed by a required "data" element that contains the substantive code point data. Finally, an optional "rules" element contains information on rules for evaluating labels, if any, along with "action" elements providing for the disposition of labels and computed variant labels.
「lgr」要素には、最大3つのサブ要素またはセクションが含まれます。 1つ目は、LGRに関連付けられたすべてのメタデータを含むオプションの「メタ」要素です。たとえば、作成者、使用目的、実装に関するメモ、参照などです。この後に、実質的なコードポイントデータを含む必須の「データ」要素が続きます。最後に、オプションの「rules」要素には、ラベルを評価するためのルールに関する情報が存在する場合は、ラベルの処理とバリアントラベルの計算を提供する「action」要素が含まれています。
<?xml version="1.0"?>
<lgr xmlns="urn:ietf:params:xml:ns:lgr-1.0">
<meta>
...
</meta>
<data>
...
</data>
<rules>
...
</rules>
</lgr>
A document MUST contain exactly one "lgr" element. Each "lgr" element MUST contain zero or one "meta" element, exactly one "data" element, and zero or one "rules" element; and these three elements MUST be in that order.
ドキュメントには、「lgr」要素を1つだけ含める必要があります。各「lgr」要素には、ゼロまたは1つの「meta」要素、正確に1つの「data」要素、およびゼロまたは1つの「rules」要素が含まれている必要があります。そして、これらの3つの要素はその順序でなければなりません。
Some elements that are direct or nested child elements of the "rules" element MUST be placed in a specific relative order to other elements for the LGR to be valid. An LGR that violates these constraints MUST be rejected. In other cases, changing the ordering would result in a valid, but different, specification.
「ルール」要素の直接またはネストされた子要素である一部の要素は、LGRを有効にするために、他の要素に対して特定の相対的な順序で配置する必要があります。これらの制約に違反するLGRは拒否する必要があります。他の場合では、順序を変更すると、有効ですが異なる仕様になります。
In the following descriptions, required, non-repeating elements or attributes are generally not called out explicitly, in contrast to "OPTIONAL" ones, or those that "MAY" be repeated. For attributes that take lists as values, the elements MUST be space-separated.
以下の説明では、「オプション」の要素や「繰り返される可能性がある」要素とは対照的に、必須の繰り返しのない要素または属性は、通常、明示的に呼び出されません。リストを値として取る属性の場合、要素はスペースで区切る必要があります。
The "meta" element expresses metadata associated with the LGR, and the element SHOULD be included so that the associated metadata are available as part of the LGR and cannot become disassociated. The following subsections describe elements that may appear within the "meta" element.
「meta」要素は、LGRに関連付けられたメタデータを表します。関連付けられたメタデータがLGRの一部として利用でき、関連付けが解除されないように、要素を含める必要があります（SHOULD）。次のサブセクションでは、「meta」要素内に表示される可能性のある要素について説明します。
The "meta" element can be used to identify the author or relevant contact person, explain the intended usage of the LGR, and provide implementation notes as well as references. Detailed metadata allow the LGR document to become self-documenting -- for example, if rendered in a human-readable format by an appropriate tool.
「meta」要素を使用して、作成者または関連する連絡担当者を識別し、LGRの使用目的を説明し、実装に関するメモと参照を提供できます。詳細なメタデータを使用すると、LGRドキュメントを自己文書化できます。たとえば、適切なツールで人間が読める形式でレンダリングした場合などです。
Providing metadata pertaining to the date and version of the LGR is particularly encouraged to make it easier for interoperating consumers to ensure that they are using the correct LGR.
LGRの日付とバージョンに関するメタデータを提供することは、相互運用している消費者が正しいLGRを確実に使用できるようにするために特に推奨されます。
With the exception of the "unicode-version" element, the data contained within is not required by software consuming the LGR in order to calculate valid labels or to calculate variants. If present, the "unicode-version" element MUST be used by a consumer of the table to identify that it has the correct Unicode property data to perform operations on the table. This ensures that possible differences in code point properties between editions of the Unicode Standard do not impact the product of calculations utilizing an LGR.
「unicode-version」要素を除いて、有効なラベルを計算したり、バリアントを計算したりするためにLGRを使用するソフトウェアは、その中に含まれるデータを必要としません。存在する場合、「unicode-version」要素は、テーブルの操作を実行するための正しいUnicodeプロパティデータがあることを識別するために、テーブルのコンシューマーが使用する必要があります。これにより、Unicode規格のエディション間のコードポイントプロパティの可能な違いが、LGRを利用した計算の製品に影響を与えないことが保証されます。
The "version" element is OPTIONAL. It is used to uniquely identify each version of the LGR. No specific format is required, but it is RECOMMENDED that it be the decimal representation of a single positive integer, which is incremented with each revision of the file.
「バージョン」要素はオプションです。 LGRの各バージョンを一意に識別するために使用されます。特定の形式は必要ありませんが、ファイルのリビジョンごとに増分される単一の正の整数の10進表記であることが推奨されます。
An example of a typical first edition of a document:
ドキュメントの典型的な初版の例：
<version>1</version>
The "version" element may have an OPTIONAL "comment" attribute.
「バージョン」要素には、オプションの「コメント」属性を含めることができます。
<version comment="draft">1</version>
The OPTIONAL "date" element is used to identify the date the LGR was posted. The contents of this element MUST be a valid ISO 8601 "full-date" string as described in [RFC3339].
オプションの「日付」要素は、LGRが投稿された日付を識別するために使用されます。この要素の内容は、[RFC3339]で説明されているように、有効なISO 8601「完全日付」文字列である必要があります。
Example of a date:
日付の例：
<date>2009-11-01</date>
Each OPTIONAL "language" element identifies a language or script for which the LGR is intended. The value of the "language" element MUST be a valid language tag as described in [RFC5646]. The tag may refer to a script plus undefined language if the LGR is not intended for a specific language.
オプションの各 "language"要素は、LGRの対象となる言語またはスクリプトを識別します。 [RFC5646]で説明されているように、「language」要素の値は有効な言語タグである必要があります。 LGRが特定の言語を対象としていない場合、タグはスクリプトと未定義の言語を参照する場合があります。
Example of an LGR for the English language:
英語のLGRの例：
<language>en</language>
If the LGR applies to a script rather than a specific language, the "und" language tag SHOULD be used followed by the relevant script subtag from [RFC5646]. For example, for a Cyrillic script LGR:
LGRが特定の言語ではなくスクリプトに適用される場合は、「und」言語タグを使用して（SHOULD）、[RFC5646]からの関連するスクリプトサブタグを続けます。たとえば、キリル文字のLGRの場合：
<language>und-Cyrl</language>
If the LGR covers a set of multiple languages or scripts, the "language" element MAY be repeated. However, for cases of a script-specific LGR exhibiting insignificant admixture of code points from other scripts, it is RECOMMENDED to use a single "language" element identifying the predominant script. In the exceptional case of a multi-script LGR where no script is predominant, use Zyyy (Common):
LGRが複数の言語またはスクリプトのセットをカバーしている場合、「言語」要素を繰り返すことができます。ただし、他のスクリプトからのコードポイントの取るに足らない混合を示すスクリプト固有のLGRの場合は、主要なスクリプトを識別する単一の "language"要素を使用することをお勧めします。主要なスクリプトがないマルチスクリプトLGRの例外的なケースでは、Zyyy（共通）を使用します。
<language>und-Zyyy</language>
This OPTIONAL element refers to a scope, such as a domain, to which this policy is applied. The "type" attribute specifies the type of scope being defined. A type of "domain" means that the scope is a domain that represents the apex of the DNS zone to which the LGR is applied. For that type, the content of the "scope" element MUST be a domain name written relative to the root zone, in presentation format with no trailing dot. However, in the unique case of the DNS root zone, it is represented as ".".
このOPTIONAL要素は、このポリシーが適用されるドメインなどのスコープを参照します。 「type」属性は、定義されるスコープのタイプを指定します。 「ドメイン」のタイプは、スコープがLGRが適用されるDNSゾーンの頂点を表すドメインであることを意味します。そのタイプの場合、「スコープ」要素のコンテンツは、ルートゾーンを基準にして記述されたドメイン名であり、末尾にドットがないプレゼンテーション形式である必要があります。ただし、DNSルートゾーンの一意のケースでは、「。」として表されます。
<scope type="domain">example.com</scope>
There may be multiple "scope" tags used -- for example, to reflect a list of domains to which the LGR is applied.
LGRが適用されるドメインのリストを反映するためなど、複数の「スコープ」タグが使用される場合があります。
No other values of the "type" attribute are defined by this specification; however, this specification can be used for applications other than domain names. Implementers of LGRs for applications other than domain names SHOULD define the scope extension grammar in an IETF specification or use XML namespaces to distinguish their scoping mechanism distinctly from the base LGR namespace. An explanation of any custom usage of the scope in the "description" element is RECOMMENDED.
「type」属性の他の値は、この仕様では定義されていません。ただし、この仕様はドメイン名以外のアプリケーションにも使用できます。ドメイン名以外のアプリケーションのLGRの実装者は、IETF仕様でスコープ拡張文法を定義するか、XML名前空間を使用して、スコープのメカニズムを基本のLGR名前空間と明確に区別する必要があります（SHOULD）。 「description」要素内のスコープのカスタム使用の説明は推奨されます。
<scope xmlns="http://example.com/ns/scope/1.0">
... content per alternate namespace ...
</scope>
The "description" element is an OPTIONAL, free-form element that contains any additional relevant description that is useful for the user in its interpretation. Typically, this field contains authorship information, as well as additional context on how the LGR was formulated and how it applies, such as citations and references that apply to the LGR as a whole.
「description」要素は、ユーザーが解釈するのに役立つ追加の関連説明を含む、オプションの自由形式の要素です。通常、このフィールドには、著者情報、およびLGRがどのように作成され、どのように適用されるかについての追加のコンテキスト（LGR全体に適用される引用や参照など）が含まれます。
This field should not be relied upon for providing instructions on how to parse or utilize the data contained elsewhere in the specification. Authors of tables should expect that software applications that parse and use LGRs will not use the "description" element to condition the application of the LGR's data and rules.
このフィールドは、仕様の他の場所に含まれているデータを解析または利用する方法の指示を提供するために依存すべきではありません。テーブルの作成者は、LGRを解析して使用するソフトウェアアプリケーションが、LGRのデータとルールの適用を条件付けるために「説明」要素を使用しないことを期待する必要があります。
The element has an OPTIONAL "type" attribute, which refers to the Internet media type [RFC2045] of the enclosed data. Typical types would be "text/plain" or "text/html". The attribute SHOULD be a valid media type. If supplied, it will be assumed that the contents are of that media type. If the description lacks a "type" value, it will be assumed to be plain text ("text/plain").
要素には、囲まれたデータのインターネットメディアタイプ[RFC2045]を参照するオプションの「type」属性があります。典型的なタイプは「text / plain」または「text / html」です。属性は有効なメディアタイプである必要があります（SHOULD）。指定した場合、コンテンツはそのメディアタイプであると見なされます。説明に「タイプ」値がない場合は、プレーンテキスト（「テキスト/プレーン」）であると見なされます。
The "validity-start" and "validity-end" elements are OPTIONAL elements that describe the time period from which the contents of the LGR become valid (are used in registry policy) and time when the contents of the LGR cease to be used, respectively.
「validity-start」および「validity-end」要素は、LGRのコンテンツが有効になる（レジストリポリシーで使用される）期間と、LGRのコンテンツが使用されなくなる時間を説明するOPTIONAL要素です。それぞれ。
The dates MUST conform to the "full-date" format described in Section 5.6 of [RFC3339].
日付は、[RFC3339]のセクション5.6で説明されている「完全な日付」形式に準拠している必要があります。
<validity-start>2014-03-12</validity-start>
Whenever an LGR depends on character properties from a given version of the Unicode Standard, the version number used in creating the LGR MUST be listed in the form x.y.z, where x, y, and z are positive decimal integers (see [Unicode-Versions]). If any software processing the table does not have access to character property data of the requisite version, it MUST NOT perform any operations relating to whole-label evaluation relying on Unicode character properties (Section 6.2.3).
LGRがUnicode標準の特定のバージョンの文字プロパティに依存する場合は常に、LGRの作成に使用されるバージョン番号をxyzの形式でリストする必要があります。ここで、x、y、zは正の10進整数です（[Unicode-Versions]を参照） ）。テーブルを処理するソフトウェアが必要なバージョンの文字プロパティデータにアクセスできない場合、Unicode文字プロパティに依存する全体ラベル評価に関連する操作を実行してはなりません（セクション6.2.3）。
The value of a given Unicode character property may change between versions of the Unicode Character Database [UAX44], unless such change has been explicitly disallowed in [Unicode-Stability]. It is RECOMMENDED to only reference properties defined as stable or immutable. As an alternative to referencing the property, the information can be presented explicitly in the LGR.
[Unicode-Stability]で明示的に許可されていない限り、特定のUnicode文字プロパティの値は、Unicode文字データベース[UAX44]のバージョン間で変更される可能性があります。安定または不変として定義されたプロパティのみを参照することをお勧めします。プロパティを参照する代わりに、情報をLGRで明示的に提示できます。
<unicode-version>6.3.0</unicode-version>
It is not necessary to include a "unicode-version" element for LGRs that do not make use of Unicode character properties; however, it is RECOMMENDED.
Unicode文字プロパティを利用しないLGRの「unicode-version」要素を含める必要はありません。ただし、推奨されます。
An LGR may define a list of references that are used to associate various individual elements in the LGR to one or more normative references. A common use for references is to annotate that code points belong to an externally defined collection or standard or to give normative references for rules.
LGRは、LGR内のさまざまな個々の要素を1つ以上の規範的な参照に関連付けるために使用される参照のリストを定義できます。参照の一般的な用途は、コードポイントが外部で定義されたコレクションまたは標準に属していることを注釈すること、またはルールに規範的な参照を与えることです。
References are specified in an OPTIONAL "references" element containing one or more "reference" elements, each with a unique "id" attribute. It is RECOMMENDED that the "id" attribute be a zero-based integer; however, in addition to digits 0-9, it MAY contain uppercase letters A-Z, as well as a period, hyphen, colon, or underscore. The value of each "reference" element SHOULD be the citation of a standard, dictionary, or other specification in any suitable format. In addition to an "id" attribute, a "reference" element MAY have a "comment" attribute for an optional free-form annotation.
参照は、それぞれが一意の「id」属性を持つ1つ以上の「参照」要素を含むオプションの「参照」要素で指定されます。 「id」属性はゼロから始まる整数にすることをお勧めします。ただし、0〜9の数字に加えて、A〜Zの大文字、ピリオド、ハイフン、コロン、アンダースコアを含めることができます。各「参照」要素の値は、標準、辞書、またはその他の仕様の引用であり、適切な形式である必要があります。 「id」属性に加えて、「reference」要素は、オプションの自由形式注釈の「comment」属性を持つ場合があります。
<references>
<reference id="0">The Unicode Consortium. The Unicode
Standard, Version 8.0.0, (Mountain View, CA: The Unicode
Consortium, 2015. ISBN 978-1-936213-10-8)
http://www.unicode.org/versions/Unicode8.0.0/</reference>
<reference id="1">Big-5: Computer Chinese Glyph and Character
Code Mapping Table, Technical Report C-26, 1984</reference>
<reference id="2" comment="synchronized with Unicode 6.1">
ISO/IEC
10646:2012 3rd edition</reference>
...
</references>
...
<data>
<char cp="0620" ref="0 2" />
...
</data>
A reference is associated with an element by using its id as part of an optional "ref" attribute (see Section 5.4.1). The "ref" attribute may be used with many kinds of elements in the "data" or "rules" sections of the LGR, most notably those defining code points, variants, and rules. However, a "ref" attribute may not occur in certain kinds of elements, including references to named character classes or rules. See below for the description of these elements.
参照は、そのidをオプションの「ref」属性の一部として使用することによって要素に関連付けられます（セクション5.4.1を参照）。 「ref」属性は、LGRの「data」または「rules」セクションの多くの種類の要素、特にコードポイント、バリアント、およびルールを定義する要素で使用できます。ただし、「ref」属性は、名前付き文字クラスまたはルールへの参照を含む、特定の種類の要素では発生しない場合があります。これらの要素の説明については、以下を参照してください。
The bulk of an LGR is a description of which set of code points is eligible for a given label. For rulesets that perform operations that result in potential variants, the code point-level relationships between variants need to also be described.
LGRの大部分は、特定のラベルに適したコードポイントのセットの説明です。潜在的なバリアントをもたらす操作を実行するルールセットの場合、バリアント間のコードポイントレベルの関係も説明する必要があります。
The code point data is collected within the "data" element. Within this element, a series of "char" and "range" elements describe eligible code points or ranges of code points, respectively. Collectively, these are known as the repertoire.
コードポイントデータは「data」要素内で収集されます。この要素内で、一連の「char」要素と「range」要素は、適格なコードポイントまたはコードポイントの範囲をそれぞれ記述します。総称して、これらはレパートリーとして知られています。
Discrete permissible code points or code point sequences (see Section 5.1) are declared with a "char" element. Here is a minimal example declaration for a single code point, with the code point value given in the "cp" attribute:
個別の許容コードポイントまたはコードポイントシーケンス（セクション5.1を参照）は、 "char"要素で宣言されます。次に、単一のコードポイントの最小の宣言例を示します。「cp」属性にコードポイント値が指定されています。
<char cp="002D"/>
As described below, a full declaration for a "char" element, whether or not it is used for a single code point or for a sequence (see Section 5.1), may have optional child elements defining variants. Both the "char" and "range" elements can take a number of optional attributes for conditional inclusion, commenting, cross-referencing, and character tagging, as described below.
以下で説明するように、「char」要素の完全な宣言は、単一のコードポイントまたはシーケンス（セクション5.1を参照）に使用されるかどうかに関係なく、バリアントを定義するオプションの子要素を持つことができます。 「char」要素と「range」要素はどちらも、以下で説明するように、条件付きの包含、コメント、相互参照、および文字のタグ付けのために、いくつかのオプション属性を取ることができます。
Ranges of permissible code points may be declared with a "range" element, as in this minimal example:
許容されるコードポイントの範囲は、次の最小限の例のように、「範囲」要素で宣言できます。
<range first-cp="0030" last-cp="0039"/>
The range is inclusive of the first and last code points. Any additional attributes defined for a "range" element act as if applied to each code point within. A "range" element has no child elements.
範囲には、最初と最後のコードポイントが含まれます。 「範囲」要素に定義された追加の属性は、内部の各コードポイントに適用されているかのように機能します。 「範囲」要素には子要素はありません。
It is always possible to substitute a list of individually specified code points for a "range" element. The reverse is not necessarily the case. Whenever such a substitution is possible, it makes no difference in processing the data. Tools reading or writing the LGR format are free to aggregate sequences of consecutive code points of the same properties into "range" elements.
個別に指定されたコードポイントのリストを「範囲」要素に置き換えることは常に可能です。逆は必ずしもそうではありません。このような置換が可能な場合、データの処理に違いはありません。 LGR形式の読み取りまたは書き込みツールは、同じプロパティの連続するコードポイントのシーケンスを「範囲」要素に自由に集約できます。
Code points MUST be represented according to the standard Unicode convention but without the prefix "U+": they are expressed in uppercase hexadecimal and are zero-padded to a minimum of 4 digits.
コードポイントは、標準のUnicode規則に従って表される必要がありますが、接頭辞「U +」はありません。これらは大文字の16進数で表され、最小4桁になるようにゼロが埋め込まれます。
The rationale for not allowing other encoding formats, including native Unicode encoding in XML, is explored in [UAX42]. The XML conventions used in this format, such as element and attribute names, mirror this document where practical and reasonable to do so. It is RECOMMENDED to list all "char" elements in ascending order of the "cp" attribute. Not doing so makes it unnecessarily difficult for authors and reviewers to check for errors, such as duplications, or to review and compare against listing of code points in other documents and specifications.
XMLのネイティブUnicodeエンコーディングを含む他のエンコーディング形式を許可しない理由は、[UAX42]で検討されています。要素名や属性名など、この形式で使用されるXML規則は、実用的で妥当な場合にこのドキュメントを反映しています。すべての「char」要素を「cp」属性の昇順でリストすることをお勧めします。そうしないと、作成者やレビュー担当者が重複などのエラーをチェックしたり、他のドキュメントや仕様のコードポイントのリストをレビューして比較したりすることが不必要に難しくなります。
All "char" elements in the "data" section MUST have distinct "cp" attributes. The "range" elements MUST NOT specify code point ranges that overlap either another range or any single code point "char" elements. An LGR that defines the same code point more than once by any combination of "char" or "range" elements MUST be rejected.
「data」セクションのすべての「char」要素には、異なる「cp」属性が必要です。 「範囲」要素は、別の範囲または単一のコードポイント「char」要素のいずれかと重複するコードポイント範囲を指定してはなりません。 「char」または「range」要素の任意の組み合わせによって同じコードポイントを複数回定義するLGRは拒否する必要があります。
A sequence of two or more code points may be specified in an LGR -- for example, when defining the source for n:m variant mappings. Another use of sequences would be in cases when the exact sequence of code points is required to occur in order for the constituent elements to be eligible, such as when some code point is only eligible when preceded or followed by a certain code point. The following would define the eligibility of the MIDDLE DOT (U+00B7) only when both preceded and followed by the LATIN SMALL LETTER L (U+006C):
LGRで2つ以上のコードポイントのシーケンスを指定できます。たとえば、n：mバリアントマッピングのソースを定義する場合などです。シーケンスの別の使用法は、構成要素を適格にするためにコードポイントの正確なシーケンスが発生する必要がある場合です。たとえば、特定のコードポイントの前または後にのみ、一部のコードポイントが適格である場合などです。以下は、中小ドット（U + 00B7）の適格性を、ラテン小文字L（U + 006C）が先行および後続の両方の場合にのみ定義します。
<char cp="006C 00B7 006C" comment="Catalan middle dot"/>
All sequences defined this way must be distinct, but sub-sequences may be defined. Thus, the sequence defined here may coexist with single code point definitions such as:
この方法で定義されたすべてのシーケンスは異なる必要がありますが、サブシーケンスを定義できます。したがって、ここで定義されたシーケンスは、次のような単一のコードポイント定義と共存できます。
<char cp="006C" />
As an alternative to using sequences to define a required context, a "char" or "range" element may specify a conditional context using an optional "when" attribute as described below in Section 5.2. Using a conditional context is more flexible because a context is not limited to a specific sequence of code points. In addition, using a context allows the choice of specifying either a prohibited or a required context.
シーケンスを使用して必要なコンテキストを定義する代わりに、「char」または「range」要素は、セクション5.2で後述するように、オプションの「when」属性を使用して条件付きコンテキストを指定できます。コンテキストはコードポイントの特定のシーケンスに限定されないため、条件付きコンテキストの使用はより柔軟です。さらに、コンテキストを使用すると、禁止または必須のコンテキストを指定することができます。
A conditional context is specified by a rule that must be satisfied (or, alternatively, must not be satisfied) for a code point in a given label, often at a particular location in a label.
条件付きコンテキストは、特定のラベルのコードポイントに対して、多くの場合ラベル内の特定の場所で満たす必要がある（または、満たされない）ルールによって指定されます。
To specify a conditional context, either a "when" or "not-when" attribute may be used. The value of each "when" or "not-when" attribute is a context rule as described below in Section 6.3. This rule can be a rule evaluating the whole label or a parameterized context rule. The context condition is met when the rule specified in the "when" attribute is matched or when the rule in the "not-when" attribute fails to match. It is an error to reference a rule that is not actually defined in the "rules" element.
条件付きコンテキストを指定するには、 "when"または "not-when"属性を使用できます。各「when」または「not-when」属性の値は、6.3項で後述するように、コンテキストルールです。このルールは、ラベル全体を評価するルールでも、パラメータ化されたコンテキストルールでもかまいません。 "when"属性で指定されたルールが一致する場合、または "not-when"属性のルールが一致しない場合、コンテキスト条件が満たされます。 「rules」要素で実際に定義されていないルールを参照するとエラーになります。
A parameterized context rule (see Section 6.4) defines the context immediately surrounding a given code point; unlike a sequence, the context is not limited to a specific fixed code point but, for example, may designate any member of a certain character class or a code point that has a certain Unicode character property.
パラメータ化されたコンテキストルール（セクション6.4を参照）は、特定のコードポイントを直接囲むコンテキストを定義します。シーケンスとは異なり、コンテキストは特定の固定コードポイントに限定されず、たとえば、特定の文字クラスまたは特定のUnicode文字プロパティを持つコードポイントのメンバーを指定できます。
Given a suitable definition of a parameterized context rule named "follows-virama", this example specifies that a ZERO WIDTH JOINER (U+200D) is restricted to immediately follow any of several code points classified as virama:
「follows-virama」という名前のパラメーター化されたコンテキストルールの適切な定義を前提として、この例では、ZERO WIDTH JOINER（U + 200D）がviramaとして分類されるいくつかのコードポイントの直後に続くように制限されていることを指定します。
<char cp="200D" when="follows-virama" />
For a complete example, see Appendix A.
完全な例については、付録Aを参照してください。
In contrast, a whole label rule (see Section 6.3) specifies a condition to be met by the entire label -- for example, that it must contain at least one code point from a given script anywhere in the label. In the following example, no digit from either range may occur in a label that mixes digits from both ranges:
対照的に、全体のラベルルール（6.3項を参照）は、ラベル全体が満たす条件を指定します。たとえば、指定されたスクリプトの少なくとも1つのコードポイントをラベルの任意の場所に含める必要があります。次の例では、両方の範囲の数字が混在するラベルでは、どちらの範囲の数字も使用できません。
<data>
<range first-cp="0660" last-cp="0669" not-when="mixed-digits"
tag="arabic-indic-digits" />
<range first-cp="06F0" last-cp="06F9" not-when="mixed-digits"
tag="extended-arabic-indic-digits" />
</data>
(See Section 6.3.9 for an example of the "mixed-digits" rule.)
（「数字の混在」ルールの例については、セクション6.3.9を参照してください。）
The OPTIONAL "when" or "not-when" attributes are mutually exclusive. They MAY be applied to both "char" and "range" elements in the "data" element, including "char" elements defining sequences of code points, as well as to "var" elements (see Section 5.3.5).
オプションの "when"または "not-when"属性は相互に排他的です。それらは、コードポイントのシーケンスを定義する「char」要素を含む「data」要素内の「char」要素と「range」要素の両方、および「var」要素に適用できます（セクション5.3.5を参照）。
If a label contains one or more code points that fail to satisfy a conditional context, the label is invalid (see Section 7.5). For variants, the conditional context restricts the definition of the variant to the case where the condition is met. Outside the specified context, a variant is not defined.
ラベルに条件付きコンテキストを満たすことができない1つ以上のコードポイントが含まれている場合、そのラベルは無効です（セクション7.5を参照）。バリアントの場合、条件付きコンテキストは、バリアントの定義を条件が満たされた場合に制限します。指定されたコンテキスト外では、バリアントは定義されていません。
Most LGRs typically only determine simple code point eligibility, and for them, the elements described so far would be the only ones required for their "data" section. Others additionally specify a mapping of code points to other code points, known as "variants". What constitutes a variant code point is a matter of policy and varies for each implementation. The following examples are intended to demonstrate the syntax; they are not necessarily typical.
ほとんどのLGRは通常、単純なコードポイントの適格性のみを決定し、それらについては、これまでに説明された要素のみが「データ」セクションに必要なものになります。また、「バリアント」と呼ばれる他のコードポイントへのコードポイントのマッピングを指定するものもあります。バリアントコードポイントを構成するものはポリシーの問題であり、実装ごとに異なります。次の例は、構文を示すことを目的としています。それらは必ずしも典型的ではありません。
Variant code points are specified using one of more "var" elements as children of a "char" element. The target mapping is specified using the "cp" attribute. Other, optional attributes for the "var" element are described below.
バリアントコードポイントは、1つ以上の「var」要素を「char」要素の子として使用して指定されます。ターゲットマッピングは、「cp」属性を使用して指定されます。 「var」要素のその他のオプション属性については、以下で説明します。
For example, to map LATIN SMALL LETTER V (U+0076) as a variant of LATIN SMALL LETTER U (U+0075):
たとえば、ラテン小文字V（U + 0076）をラテン小文字U（U + 0075）のバリアントとしてマッピングするには：
<char cp="0075">
<var cp="0076"/>
</char>
A sequence of multiple code points can be specified as a variant of a single code point. For example, the sequence of LATIN SMALL LETTER O (U+006F) then LATIN SMALL LETTER E (U+0065) might hypothetically be specified as a variant for a LATIN SMALL LETTER O WITH DIAERESIS (U+00F6) as follows:
複数のコードポイントのシーケンスは、単一のコードポイントのバリアントとして指定できます。たとえば、次のように、ラテン小文字O（U + 006F）、ラテン小文字E（U + 0065）のシーケンスは、仮説的にラテン小文字O（ダイアレシスあり）（U + 00F6）のバリアントとして指定できます。
<char cp="00F6">
<var cp="006F 0065"/>
</char>
The source and target of a variant mapping may both be sequences but not ranges.
バリアントマッピングのソースとターゲットは両方ともシーケンスであり、範囲ではない場合があります。
If the source of one mapping is a prefix sequence of the source for another, both variant mappings will be considered at the same location in the input label when generating permuted variant labels. If poorly designed, an LGR containing such an instance of a prefix relation could generate multiple instances of the same variant label for the same original label, but with potentially different dispositions. Any duplicate variant labels encountered MUST be treated as an error (see Section 8.4).
1つのマッピングのソースが別のマッピングのソースのプレフィックスシーケンスである場合、置換バリアントラベルを生成するときに、両方のバリアントマッピングが入力ラベルの同じ場所で考慮されます。適切に設計されていない場合、このような接頭辞関係のインスタンスを含むLGRは、同じ元のラベルに対して同じバリアントラベルの複数のインスタンスを生成する可能性がありますが、性質が異なる可能性があります。重複したバリアントラベルが発生した場合は、エラーとして処理する必要があります（セクション8.4を参照）。
The "var" element specifies variant mappings in only one direction, even though the variant relation is usually considered symmetric; that is, if A is a variant of B, then B should also be a variant of A. The format requires that the inverse of the variant be given explicitly to fully specify symmetric variant relations in the LGR. This has the beneficial side effect of making the symmetry explicit:
"var"要素は、バリアントの関係が通常対称であると見なされている場合でも、一方向のみのバリアントマッピングを指定します。つまり、AがBのバリアントである場合、BもAのバリアントである必要があります。LGRで対称バリアント関係を完全に指定するには、バリアントの逆を明示的に指定する必要があります。これには、対称性を明示的にするという有益な副作用があります。
<char cp="006F 0065">
<var cp="00F6"/>
</char>
Variant relations are normally not only symmetric but also transitive. If A is a variant of B and B is a variant of C, then A is also a variant of C. As with symmetry, these transitive relations are only part of the LGR if spelled out explicitly. Implementations that require an LGR to be symmetric and transitive should verify this mechanically.
バリアント関係は通常、対称的であるだけでなく推移的でもあります。 AがBのバリアントであり、BがCのバリアントである場合、AもCのバリアントです。対称性と同様に、これらの推移関係は、明示的に指定されている場合、LGRの一部にすぎません。 LGRが対称的で推移的である必要がある実装では、これを機械的に検証する必要があります。
All variant mappings are unique. For a given "char" element, all "var" elements MUST have a unique combination of "cp", "when", and "not-when" attributes. It is RECOMMENDED to list the "var" elements in ascending order of their target code point sequence. (For "when" and "not-when" attributes, see Section 5.3.5.)
すべてのバリアントマッピングは一意です。特定の「char」要素の場合、すべての「var」要素には、「cp」、「when」、および「not-when」属性の一意の組み合わせが必要です。ターゲットコードポイントシーケンスの昇順で「var」要素をリストすることをお勧めします。 （「when」および「not-when」属性については、5.3.5項を参照してください。）
Variants may be tagged with an OPTIONAL "type" attribute. The value of the "type" attribute may be any non-empty value not starting with an underscore and not containing spaces. This value is used to resolve the disposition of any variant labels created using a given variant. (See Section 7.2.)
バリアントは、オプションの「type」属性でタグ付けできます。 「type」属性の値は、アンダースコアで始まらず、スペースを含まない空でない値にすることができます。この値は、特定のバリアントを使用して作成されたすべてのバリアントラベルの後処理を解決するために使用されます。 （セクション7.2を参照。）
By default, the values of the "type" attribute directly describe the target policy status (disposition) for a variant label that was generated using a particular variant, with any variant label being assigned a disposition corresponding to the most restrictive variant type. Several conventional disposition values are predefined below in Section 7. Whenever these values can represent the desired policy, they SHOULD be used.
デフォルトでは、「type」属性の値は、特定のバリアントを使用して生成されたバリアントラベルのターゲットポリシーステータス（処理）を直接説明し、バリアントラベルには、最も制限的なバリアントタイプに対応する処理が割り当てられます。いくつかの従来のディスポジション値は、以下のセクション7で事前定義されています。これらの値が目的のポリシーを表すことができる場合は常に、それらを使用してください。
<char cp="767C">
<var cp="53D1" type="allocatable"/>
<var cp="5F42" type="blocked"/>
<var cp="9AEA" type="blocked"/>
<var cp="9AEE" type="blocked"/>
</char>
By default, if a variant label contains any instance of one of the variants of type "blocked", the label would be blocked, but if it contained only instances of variants to be allocated, it could be allocated. See the discussion about implied actions in Section 7.6.
デフォルトでは、バリアントラベルにタイプ「blocked」のバリアントのいずれかのインスタンスが含まれている場合、ラベルはブロックされますが、割り当てられるバリアントのインスタンスのみが含まれている場合、割り当てられます。セクション7.6の暗黙のアクションに関する説明を参照してください。
The XML format for the LGR makes the relation between the values of the "type" attribute on variants and the resulting disposition of variant labels fully explicit. See the discussion in Section 7.2. Making this relation explicit allows a generalization of the "type" attribute from directly reflecting dispositions to a more differentiated intermediate value that is then used in the resolution of label disposition. Instead of the default action of applying the most restrictive disposition to the entire label, such a generalized resolution can be used to achieve additional goals, such as limiting the set of allocatable variant labels or implementing other policies found in existing LGRs (see, for example, Appendix B).
LGRのXML形式は、バリアントの「type」属性の値とバリアントラベルの結果の処理の間の関係を完全に明示的にします。セクション7.2の説明を参照してください。この関係を明示的にすることで、「type」属性を一般化して、処理を直接反映することから、ラベル処理の解決に使用されるより差別化された中間値に変換できます。ラベル全体に最も制限的な処理を適用するデフォルトのアクションの代わりに、そのような一般化された解決策を使用して、割り当て可能なバリアントラベルのセットの制限や既存のLGRにある他のポリシーの実装などの追加の目標を達成できます（たとえば、 、付録B）。
Because variant mappings MUST be unique, it is not possible to define the same variant for the same "char" element with different "type" attributes (however, see Section 5.3.5).
バリアントマッピングは一意でなければならないため、異なる "type"属性を持つ同じ "char"要素に対して同じバリアントを定義することはできません（ただし、セクション5.3.5を参照）。
A null variant is a variant string that maps to no code point. This is used when a particular code point sequence is considered discretionary in the context of a whole label. To specify a null variant, use an empty "cp" attribute. For example, to mark a string with a ZERO WIDTH NON-JOINER (U+200C) to the same string without the ZERO WIDTH NON-JOINER:
nullバリアントは、コードポイントにマップされないバリアント文字列です。これは、特定のコードポイントシーケンスがラベル全体のコンテキストで任意と見なされる場合に使用されます。 nullバリアントを指定するには、空の "cp"属性を使用します。たとえば、ZERO WIDTH NON-JOINER（U + 200C）を含む文字列をZERO WIDTH NON-JOINERを含まない同じ文字列にマークするには：
<char cp="200C">
<var cp=""/>
</char>
This is useful in expressing the intent that some code points in a label are to be mapped away when generating a canonical variant of the label. However, in tables that are designed to have symmetric variant mappings, this could lead to combinatorial explosion if not handled carefully.
これは、ラベルの正規のバリアントを生成するときに、ラベル内の一部のコードポイントをマッピングする意図を表すのに役立ちます。ただし、対称バリアントマッピングを使用するように設計されているテーブルでは、慎重に処理しないと、組み合わせが爆発する可能性があります。
The symmetric form of a null variant is expressed as follows:
nullバリアントの対称形式は次のように表されます。
<char cp="">
<var cp="200C" type="invalid" />
</char>
A "char" element with an empty "cp" attribute MUST specify at least one variant mapping. It is strongly RECOMMENDED to use a type of "invalid" or equivalent when defining variant mappings from null sequences, so that variant mappings from null sequences are removed in variant label generation (see Section 5.3.2).
空の「cp」属性を持つ「char」要素は、少なくとも1つのバリアントマッピングを指定する必要があります。 nullシーケンスからのバリアントマッピングを定義するときは、「無効」または同等のタイプを使用して、nullシーケンスからのバリアントマッピングがバリアントラベル生成で削除されるようにすることを強くお勧めします（セクション5.3.2を参照）。
At first glance, there seems to be no call for adding variant mappings for which source and target code points are the same -- that is, for which the mapping is reflexive, or, in other words, an identity mapping. Yet, such reflexive mappings occur frequently in LGRs that follow [RFC3743].
一見すると、ソースコードポイントとターゲットコードポイントが同じであるバリアントマッピングを追加する必要はないようです。つまり、マッピングは再帰的です。つまり、IDマッピングです。しかし、そのような再帰的なマッピングは、[RFC3743]に続くLGRで頻繁に発生します。
Adding a "var" element allows both a type and a reference id to be specified for it. While the reference id is not used in processing, the type of the variant can be used to trigger actions. In permuting the label to generate all possible variants, the type associated with a reflexive variant mapping is applied to any of the permuted labels containing the original code point.
「var」要素を追加すると、タイプと参照IDの両方を指定できます。参照IDは処理では使用されませんが、バリアントのタイプを使用してアクションをトリガーできます。可能なすべてのバリアントを生成するためにラベルを並べ替える場合、再帰バリアントマッピングに関連付けられているタイプが、元のコードポイントを含む並べ替えられたラベルのいずれかに適用されます。
In the following example, let's assume that the goal is to allocate only those labels that contain a variant that is considered "preferred" in some way. As defined in the example, the code point U+3473 exists both as a variant of U+3447 and as a variant of itself (reflexive mapping). Assuming an original label of "U+3473 U+3447", the permuted variant "U+3473 U+3473" would consist of the reflexive variant of U+3473 followed by a variant of U+3447. Given the variant mappings as defined here, the types for both of the variant mappings used to generate that particular permutation would have the value "preferred":
次の例では、ある目的で「推奨」と見なされるバリアントを含むラベルのみを割り当てることが目標であると想定します。例で定義されているように、コードポイントU + 3473は、U + 3447のバリアントとしても、それ自体のバリアント（再帰マッピング）としても存在します。 「U + 3473 U + 3447」の元のラベルを想定すると、置換されたバリアント「U + 3473 U + 3473」は、U + 3473の再帰バリアントとそれに続くU + 3447のバリアントで構成されます。ここで定義されているバリアントマッピングを考えると、その特定の順列を生成するために使用される両方のバリアントマッピングの型は、値 "preferred"を持ちます。
<char cp="3447" ref="0">
<var cp="3473" type="preferred" ref="1 3" />
</char>
<char cp="3473" ref="0">
<var cp="3447" type="blocked" ref="1 3" />
<var cp="3473" type="preferred" ref="0" />
</char>
Having established the variant types in this way, a set of actions could be defined that return a disposition of "allocatable" or "activated" for a label consisting exclusively of variants with type "preferred", for example. (For details on how to define actions based on variant types, see Section 7.2.1.)
この方法でバリアントタイプを確立したら、たとえば、タイプ「優先」のバリアントのみで構成されるラベルに対して「割り当て可能」または「アクティブ化」の処理を返す一連のアクションを定義できます。 （バリアント型に基づいてアクションを定義する方法の詳細については、セクション7.2.1を参照してください。）
In general, using reflexive variant mappings in this manner makes it possible to calculate disposition values using a uniform approach for all labels, whether they consist of mapped variant code points, original code points, or a mixture of both. In particular, the dispositions for two otherwise identical labels may differ based on which variant mappings were executed in order to generate each of them. (For details on how to generate variants and evaluate dispositions, see Section 8.)
一般に、この方法で再帰的バリアントマッピングを使用すると、マップされたバリアントコードポイント、元のコードポイント、またはその両方の混合で構成されるかどうかに関係なく、すべてのラベルに対して統一されたアプローチを使用してディスポジション値を計算できます。特に、2つのその他の点で同一のラベルの後処理は、それぞれを生成するために実行されたバリアントマッピングに基づいて異なる場合があります。 （バリアントの生成方法と処分の評価方法の詳細については、セクション8を参照してください。）
Another useful convention that uses reflexive variants is described below in Section 7.2.1.
再帰的バリアントを使用するもう1つの便利な規則については、7.2.1項で説明します。
Fundamentally, variants are mappings between two sequences of code points. However, in some instances, for a variant relationship to exist, some context external to the code point sequence must also be considered. For example, a positional context may determine whether two code point sequences are variants of each other.
基本的に、バリアントはコードポイントの2つのシーケンス間のマッピングです。ただし、場合によっては、バリアント関係が存在するために、コードポイントシーケンスの外部にあるコンテキストも考慮する必要があります。たとえば、位置コンテキストは、2つのコードポイントシーケンスが相互のバリアントであるかどうかを決定します。
An example of that are Arabic code points, which can have different forms based on position, with some code points sharing forms, thus making them variants in the positions corresponding to those forms. Such positional context cannot be solely derived from the code point by itself, as the code point would be the same for the various forms.
その一例はアラビア語のコードポイントであり、位置に基づいて異なる形式をとることができ、いくつかのコードポイントは形式を共有しているため、それらの形式に対応する位置でそれらを変化させることができます。コードポイントはさまざまな形式で同じであるため、そのような位置コンテキストはコードポイントから単独で派生することはできません。
As described in Section 5.2, an OPTIONAL "when" or "not-when" attribute may be given for any "var" element to specify required or prohibited contextual conditions under which the variant is defined.
セクション5.2で説明されているように、オプションの「when」または「not-when」属性を「var」要素に指定して、バリアントが定義される必須または禁止されたコンテキスト条件を指定できます。
Assuming that the "rules" element contains suitably defined rules for "arabic-isolated" and "arabic-final", the following example shows how to mark ARABIC LETTER ALEF WITH WAVY HAMZA BELOW (U+0673) as a variant of ARABIC LETTER ALEF WITH HAMZA BELOW (U+0625), but only when it appears in its isolated or final forms:
「rules」要素に「arabic-isolated」と「arabic-final」の適切に定義されたルールが含まれていると仮定して、次の例は、アラビア語のアルファベットと以下の波状ハムザ（U + 0673）をアラビア語のアルファベットのバリアントとしてマークする方法を示しています。以下のハムザあり（U + 0625）。ただし、孤立した形式または最終的な形式で表示される場合のみ。
<char cp="0625">
<var cp="0673" when="arabic-isolated"/>
<var cp="0673" when="arabic-final"/>
</char>
While a "var" element MUST NOT contain multiple conditions (it is only allowed a single "when" or "not-when" attribute), multiple "var" elements using the same mapping MAY be specified with different "when" or "not-when" attributes. The combination of mapping and conditional context defines a unique variant.
"var"要素に複数の条件を含めることはできませんが（単一の "when"または "not-when"属性のみが許可されます）、同じマッピングを使用する複数の "var"要素は異なる "when"または "not -when」属性。マッピングと条件付きコンテキストの組み合わせにより、固有のバリアントが定義されます。
For each variant label, care must be taken to ensure that at most one of the contextual conditions is met for variants with the same mapping; otherwise, duplicate variant labels would be created for the same input label. Any such duplicate variant labels MUST be treated as an error; see Section 8.4.
バリアントラベルごとに、同じマッピングを持つバリアントについて、コンテキスト条件の多くとも1つが満たされるように注意する必要があります。そうしないと、同じ入力ラベルに対して重複するバリアントラベルが作成されます。そのような重複するバリアントラベルはエラーとして扱われる必要があります。セクション8.4を参照してください。
Two contexts may be complementary, as in the following example, which shows ARABIC LETTER TEH MARBUTA (U+0629) as a variant of ARABIC LETTER HEH (U+0647), but with two different types.
次の例のように、2つのコンテキストが補完的である可能性があります。これは、アラビア語文字TEH MARBUTA（U + 0629）をアラビア語文字HEH（U + 0647）のバリアントとして示していますが、タイプは2つあります。
<char cp="0647" >
<var cp="0629" not-when="arabic-final" type="blocked" />
<var cp="0629" when="arabic-final" type="allocatable" />
</char>
The intent is that a label that uses U+0629 instead of U+0647 in a final position should be considered essentially the same label and, therefore, allocatable to the same entity, while the same substitution in a non-final position leads to labels that are different, but considered confusable, so that either one, but not both, should be delegatable.
最終的な位置でU + 0647の代わりにU + 0629を使用するラベルは、本質的に同じラベルと見なされるため、同じエンティティに割り当てることができますが、非最終的な位置で同じ置換を行うとラベルになります。それらは異なりますが、混乱しやすいと見なされているため、両方ではなくどちらか一方が委任可能である必要があります。
For symmetry, the reverse mappings must exist and must agree in their "when" or "not-when" attributes. However, symmetry does not apply to the other attributes. For example, these are potential reverse mappings for the above:
対称性のために、逆マッピングが存在し、それらの「いつ」または「not-when」属性で一致する必要があります。ただし、対称性は他の属性には適用されません。たとえば、これらは上記の潜在的な逆マッピングです。
<char cp="0629" >
<var cp="0647" not-when="arabic-final" type="allocatable" />
<var cp="0647" when="arabic-final" type="allocatable" />
</char>
Here, both variants have the same "type" attribute. While it is tempting to recognize that, in this instance, the "when" and "not-when" attributes are complementary; therefore, between them they cover every single possible context, it is strongly RECOMMENDED to use the format shown in the example that makes the symmetry easily verifiable by parsers and tools. (The same applies to entries created for transitivity.) Arabic is an example of a script for which such conditional variants have been implemented based on the joining contexts for Arabic code points. The mechanism defined here supports other forms of conditional variants that may be required by other scripts.
ここでは、両方のバリアントが同じ「タイプ」属性を持っています。この場合、 "いつ"および "非-いつ"属性が補完的であることを認識したくなりますが、したがって、それらの間で可能なすべてのコンテキストをカバーし、パーサーやツールによって対称性を簡単に検証できるようにする例に示す形式を使用することを強くお勧めします。 （同じことは推移性のために作成されたエントリにも当てはまります。）アラビア語は、アラビア語コードポイントの結合コンテキストに基づいてこのような条件付きバリアントが実装されたスクリプトの例です。ここで定義されているメカニズムは、他のスクリプトで必要になる可能性のある他の形式の条件付きバリアントをサポートしています。
Two attributes, the "ref" and "comment" attributes, can be used to annotate individual elements in the LGR. They are ignored in machine-processing of the LGR. The "ref" attribute is intended for formal annotations and the "comment" attribute for free-form annotations. The latter can be applied more widely.
「ref」属性と「comment」属性の2つの属性を使用して、LGR内の個々の要素に注釈を付けることができます。 LGRの機械処理では無視されます。 「ref」属性は正式な注釈用であり、「comment」属性は自由形式の注釈用です。後者はより広く適用できます。
Reference information MAY optionally be specified by a "ref" attribute consisting of a space-delimited sequence of reference identifiers (see Section 4.3.8).
参照情報は、オプションで、参照識別子のスペースで区切られたシーケンスで構成される "ref"属性で指定できます（セクション4.3.8を参照）。
<char cp="5220" ref="0">
<var cp="5220" ref="5"/>
<var cp="522A" ref="2 3"/>
</char>
This facility is typically used to give source information for code points or variant relations. This information is ignored when machine-processing an LGR. If applied to a range, the "ref" attribute applies to every code point in the range. All reference identifiers MUST be from the set declared in the "references" element (see Section 4.3.8). It is an error to repeat a reference identifier in the same "ref" attribute. It is RECOMMENDED that identifiers be listed in ascending order.
この機能は通常、コードポイントまたはバリアント関係のソース情報を提供するために使用されます。 LGRを機械処理する場合、この情報は無視されます。範囲に適用される場合、「ref」属性は範囲内のすべてのコードポイントに適用されます。すべての参照識別子は、「references」要素で宣言されたセットからのものでなければなりません（セクション4.3.8を参照）。同じ「ref」属性で参照識別子を繰り返すことはエラーです。識別子を昇順でリストすることをお勧めします。
In addition to "char", "range", and "var" elements in the "data" section, a "ref" attribute may be present for a number of element types contained in the "rules" element as described below: actions and literals ("char" inside a rule), as well as for definitions of rules and classes, but not for references to named character classes or rules using the "by-ref" attribute defined below. (The use of the "by-ref" and "ref" attributes is mutually exclusive.) None of the elements in the metadata take a "ref" attribute; to provide additional information, use the "description" element instead.
「データ」セクションの「char」、「range」、および「var」要素に加えて、「ref」属性は、以下で説明するように、「rules」要素に含まれるいくつかの要素タイプに存在する場合があります。リテラル（ルール内の「char」）、およびルールとクラスの定義用。ただし、以下で定義されている「by-ref」属性を使用した名前付き文字クラスまたはルールへの参照用ではありません。 （「by-ref」属性と「ref」属性の使用は相互に排他的です。）メタデータ内のどの要素も「ref」属性を取りません。追加情報を提供するには、代わりに「description」要素を使用します。
Any "char", "range", or "variant" element in the "data" section may contain an OPTIONAL "comment" attribute. The contents of a "comment" attribute are free-form plain text. Comments are ignored in machine processing of the table. "comment" attributes MAY also be placed on all elements in the "rules" section of the document, such as actions and match operators, as well as definitions of classes and rules, but not on child elements of the "class" element. Finally, in the metadata, only the "version" and "reference" elements MAY have "comment" attributes (to match the syntax in [RFC3743]).
「data」セクションの「char」、「range」、または「variant」要素には、オプションの「comment」属性を含めることができます。 「コメント」属性の内容は、自由形式のプレーンテキストです。テーブルの機械処理ではコメントは無視されます。 「コメント」属性は、アクションや一致演算子、クラスやルールの定義など、ドキュメントの「ルール」セクションのすべての要素にも配置できますが、「クラス」要素の子要素には配置できません。最後に、メタデータでは、「バージョン」および「参照」要素のみが「コメント」属性を持つ場合があります（[RFC3743]の構文に一致させるため）。
Typically, LGRs are used to explicitly designate allowable code points, where any label that contains a code point not explicitly listed in the LGR is considered an ineligible label according to the ruleset.
通常、LGRは使用可能なコードポイントを明示的に指定するために使用されます。LGRに明示的にリストされていないコードポイントを含むラベルは、ルールセットに従って不適格なラベルと見なされます。
For more-complex registry rules, there may be a need to discern one or more subsets of code points. This can be accomplished by applying an OPTIONAL "tag" attribute to "char" or "range" elements that are child elements of the "data" element. By collecting code points that share the same tag value, character classes may be defined (see Section 6.2.2) that can then be used in parameterized context or whole label rules (see Section 6.3.2).
より複雑なレジストリルールの場合、コードポイントの1つ以上のサブセットを識別する必要がある場合があります。これは、オプションの「タグ」属性を「データ」要素の子要素である「文字」または「範囲」要素に適用することによって実現できます。同じタグ値を共有するコードポイントを収集することにより、文字クラスを定義でき（セクション6.2.2を参照）、パラメーター化されたコンテキストまたは全体のラベルルール（セクション6.3.2を参照）で使用できます。
Each "tag" attribute MAY contain multiple values separated by white space. A tag value is an identifier that may also include certain punctuation marks, such as a colon. Formally, it MUST correspond to the XML 1.0 Nmtoken (Name token) production (see [XML] Section 2.3). It is an error to duplicate a value within the same "tag" attribute. A "tag" attribute for a "range" element applies to all code points in the range. Because code point sequences are not proper members of a set of code points, a "tag" attribute MUST NOT be present in a "char" element defining a code point sequence.
各「タグ」属性には、空白で区切られた複数の値が含まれる場合があります。タグ値は、コロンなどの特定の句読点も含む可能性のある識別子です。正式には、XML 1.0 Nmtoken（名前トークン）プロダクションに対応する必要があります（[XML]セクション2.3を参照）。同じ「タグ」属性内で値を複製するとエラーになります。 「範囲」要素の「タグ」属性は、範囲内のすべてのコードポイントに適用されます。コードポイントシーケンスはコードポイントのセットの適切なメンバーではないため、「タグ」属性は、コードポイントシーケンスを定義する「char」要素に存在してはなりません（MUST NOT）。
The "rules" element contains the specification of both context-based and whole label rules. Collectively, these are known as Whole Label Evaluation (WLE) rules (Section 6.3). The "rules" element also contains the character classes (Section 6.2) that they depend on, and any actions (Section 7) that assign dispositions to labels based on rules or variant mappings.
「rules」要素には、コンテキストベースのルールとラベル全体のルールの両方の仕様が含まれています。これらは総称して、Whole Label Evaluation（WLE）ルールとして知られています（セクション6.3）。 "rules"要素には、依存する文字クラス（セクション6.2）と、ルールまたはバリアントマッピングに基づいてラベルに後処理を割り当てるアクション（セクション7）も含まれます。
A whole label rule is applied to the whole label. It is used to validate both original labels and any variant labels computed from them.
ラベル全体にルール全体が適用されます。元のラベルとそれらから計算されたバリアントラベルの両方を検証するために使用されます。
A rule implementing a conditional context as discussed in Section 5.2 does not necessarily apply to the whole label but may be specific to the context around a single code point or code point sequence. Certain code points in a label sometimes need to satisfy context-based rules -- for example, for the label to be considered valid, or to satisfy the context for a variant mapping (see the description of the "when" attribute in Section 6.4).
セクション5.2で説明した条件付きコンテキストを実装するルールは、必ずしもラベル全体に適用されるわけではありませんが、単一のコードポイントまたはコードポイントシーケンスの周囲のコンテキストに固有である場合があります。ラベル内の特定のコードポイントは、コンテキストベースのルールを満たす必要がある場合があります。たとえば、ラベルが有効と見なされるため、またはバリアントマッピングのコンテキストを満たすために必要です（6.4節の「when」属性の説明を参照）。 。
For example, if a rule is referenced in the "when" attribute of a variant mapping, it is used to describe the conditional context under which the particular variant mapping is defined to exist.
たとえば、ルールがバリアントマッピングの「when」属性で参照されている場合、特定のバリアントマッピングが存在するように定義されている条件付きコンテキストを記述するために使用されます。
Each rule is defined in a "rule" element. A rule may contain the following as child elements:
各ルールは「ルール」要素で定義されます。ルールには、以下を子要素として含めることができます。
o literal code points or code point sequences
o リテラルコードポイントまたはコードポイントシーケンス
o character classes, which define sets of code points to be used for context comparisons
o コンテキスト比較に使用されるコードポイントのセットを定義する文字クラス
o context operators, which define when character classes and literals may appear
o 文字クラスとリテラルがいつ現れるかを定義するコンテキスト演算子
o nested rules, whether defined in place or invoked by reference
o 入れ子になったルール（その場で定義されているか、参照によって呼び出されているか）
Collectively, these are called "match operators" and are listed in Section 6.3.2. An LGR containing rules or match operators that
これらは総称して「一致演算子」と呼ばれ、セクション6.3.2にリストされています。ルールまたは一致演算子を含むLGR
1. are incorrectly defined or nested,
1. 誤って定義またはネストされている
2. have invalid attributes, or
2. 無効な属性がある、または
3. have invalid or undefined attribute values
3. 無効または未定義の属性値がある
MUST be rejected. Note that not all of the constraints defined here are validated by the schema.
拒否する必要があります。ここで定義されているすべての制約がスキーマによって検証されるわけではないことに注意してください。
Character classes are sets of characters that often share a particular property. While they function like sets in every way, even supporting the usual set operators, they are called "character classes" here in a nod to the use of that term in regular expression syntax. (This also avoids confusion with the term "character set" in the sense of character encoding.)
文字クラスは、特定のプロパティを共有することが多い文字のセットです。それらはあらゆる点でセットのように機能しますが、通常のセット演算子もサポートしますが、正規表現構文でのその用語の使用に合わせて、ここでは「文字クラス」と呼ばれています。 （これにより、文字エンコードの意味での「文字セット」という用語との混同が回避されます。）
Character classes can be specified in several ways:
文字クラスは、いくつかの方法で指定できます。
o by defining the class via matching a tag in the code point data. All characters with the same "tag" attribute are part of the same class;
o コードポイントデータのタグを照合してクラスを定義する。同じ「タグ」属性を持つすべての文字は、同じクラスの一部です。
o by referencing a value of one of the Unicode character properties defined in the Unicode Character Database;
o Unicode Character Databaseで定義されているUnicode文字プロパティのいずれかの値を参照する。
o by explicitly listing all the code points in the class; or
o クラス内のすべてのコードポイントを明示的にリストする。または
o by defining the class as a set combination of any number of other classes.
o クラスを他の任意の数のクラスのセットの組み合わせとして定義する。
A character class has an OPTIONAL "name" attribute consisting of a single identifier not containing spaces. All names for classes must be unique. If the "name" attribute is omitted, the class is anonymous and exists only inside the rule or combined class where it is defined. A named character class is defined independently and can be referenced by name from within any rules or as part of other character class definitions.
文字クラスには、スペースを含まない単一の識別子で構成されるオプションの「名前」属性があります。クラスの名前はすべて一意である必要があります。 「name」属性が省略されている場合、クラスは匿名であり、それが定義されているルールまたは結合クラスの内部にのみ存在します。名前付き文字クラスは独立して定義され、ルール内から、または他の文字クラス定義の一部として名前で参照できます。
<class name="example" comment="an example class definition">
0061 4E00
</class>
...
<rule>
<class by-ref="example" />
</rule>
An empty "class" element with a "by-ref" attribute is a reference to an existing named class. The "by-ref" attribute MUST NOT be used in the same "class" element with any of these attributes: "name", "from-tag", "property", or "ref". The "name" attribute MUST be present if and only if the class is a direct child element of the "rules" element. It is an error to reference a named class for which the definition has not been seen.
「by-ref」属性を持つ空の「class」要素は、既存の名前付きクラスへの参照です。 「by-ref」属性は、「name」、「from-tag」、「property」、または「ref」のいずれかの属性を持つ同じ「class」要素で使用してはなりません（MUST NOT）。 「name」属性は、クラスが「rules」要素の直接の子要素である場合にのみ存在する必要があります。定義が確認されていない名前付きクラスを参照するとエラーになります。
The "char" or "range" elements that are child elements of the "data" element MAY contain a "tag" attribute that consists of one or more space-separated tag values; for example:
「data」要素の子要素である「char」または「range」要素は、1つ以上のスペースで区切られたタグ値で構成される「tag」属性を含むことができます。例えば：
<char cp="0061" tag="letter lower"/>
<char cp="4E00" tag="letter"/>
This defines two tags for use with code point U+0061, the tag "letter" and the tag "lower". Use
これは、コードポイントU + 0061で使用する2つのタグ、タグ「letter」とタグ「lower」を定義します。使用する
<class name="letter" from-tag="letter" />
<class name="lower" from-tag="lower" />
to define two named character classes, "letter" and "lower", containing all code points with the respective tags, the first with 0061 and 4E00 as elements, and the latter with 0061 but not 4E00 as an element. The "name" attribute may be omitted for an anonymous in-place definition of a nested, tag-based class.
2つの名前付き文字クラス「letter」と「lower」を定義します。それぞれのタグを持つすべてのコードポイントを含み、最初の要素は0061と4E00を要素とし、後者は0061を含みますが4E00を要素としません。ネストされたタグベースのクラスの匿名インプレース定義では、「name」属性を省略できます。
Tag values are typically identifiers, with the addition of a few punctuation symbols, such as a colon. Formally, they MUST correspond to the XML 1.0 Nmtoken production. While a "tag" attribute may contain a list of tag values, the "from-tag" attribute MUST always contain a single tag value.
通常、タグ値は識別子であり、コロンなどの句読記号がいくつか追加されています。正式には、XML 1.0 Nmtokenプロダクションに対応する必要があります。 「タグ」属性にはタグ値のリストを含めることができますが、「タグから」属性には常に単一のタグ値を含める必要があります。
If the document contains no "char" or "range" elements with a corresponding tag, the character class represents the empty set. This is valid, to allow a common "rules" element to be shared across files. However, it is RECOMMENDED that implementations allow for a warning to ensure that referring to an undefined tag in this way is intentional.
ドキュメントに対応するタグを持つ「char」または「range」要素が含まれていない場合、文字クラスは空のセットを表します。これは有効であり、共通の「ルール」要素をファイル間で共有できるようにします。ただし、実装で警告を許可して、この方法で未定義のタグを参照することが意図的であることを保証することをお勧めします。
A class is defined in terms of Unicode properties by giving the Unicode property alias and the property value or property value alias, separated by a colon.
クラスは、Unicodeプロパティのエイリアスと、コロンで区切られたプロパティ値またはプロパティ値のエイリアスを指定することにより、Unicodeプロパティに関して定義されます。
<class name="virama" property="ccc:9" />
The example above selects all code points for which the Unicode Canonical Combining Class (ccc) value is 9. This value of the ccc is assigned to all code points that encode viramas.
上記の例では、Unicode Canonical Combining Class（ccc）値が9であるすべてのコードポイントを選択しています。このcccの値は、ビラマをエンコードするすべてのコードポイントに割り当てられます。
Unicode property values MUST be designated via a composite of the attribute name and value as defined for the property value in [UAX42], separated by a colon. Loose matching of property values and names as described in [UAX44] is not appropriate for an XML schema and is not supported; it is likewise not supported in the XML representation [UAX42] of the Unicode Character Database itself.
Unicodeプロパティ値は、[UAX42]でプロパティ値に対して定義されているように、コロンで区切られた属性名と値の複合を介して指定する必要があります。 [UAX44]で説明されているプロパティ値と名前の緩やかなマッチングは、XMLスキーマには適切ではなく、サポートされていません。同様に、Unicode Character Database自体のXML表現[UAX42]でもサポートされていません。
A property-based class MAY be anonymous, or, when defined as an immediate child of the "rules" element, it MAY be named to relate a formal property definition to its usage, such as the use of the value 9 for ccc to designate a virama (or halant) in various scripts.
プロパティベースのクラスは匿名である場合があります。または、「rules」要素の直接の子として定義されている場合は、cccの値9を使用して指定するなど、正式なプロパティ定義をその使用法に関連付けるために名前を付けることができますさまざまなスクリプトでのビラマ（またはハラント）。
Unicode properties may, in principle, change between versions of the Unicode Standard. However, the values assigned for a given version are fixed. If Unicode properties are used, a Unicode version MUST be declared in the "unicode-version" element in the header. (Note: Some Unicode properties are by definition stable across versions and do not change once assigned; see [Unicode-Stability].)
Unicodeプロパティは、原則として、Unicode標準のバージョン間で変更される可能性があります。ただし、特定のバージョンに割り当てられた値は固定されています。 Unicodeプロパティを使用する場合は、ヘッダーの「unicode-version」要素でUnicodeバージョンを宣言する必要があります。 （注：一部のUnicodeプロパティは、定義によりバージョン間で安定しており、一度割り当てられると変更されません。[Unicode-Stability]を参照してください。）
All implementations processing LGR files SHOULD provide support for the following minimal set of Unicode properties:
LGRファイルを処理するすべての実装は、以下の最小限のUnicodeプロパティのセットをサポートする必要があります（SHOULD）。
o General Category (gc)
o 一般カテゴリ（gc）
o Script (sc)
o スクリプト（sc）
o Canonical Combining Class (ccc)
o 正規結合クラス（ccc）
o Bidi Class (bc)
o Bidiクラス（bc）
o Arabic Joining Type (jt)
o アラビア語の結合タイプ（jt）
o Indic Syllabic Category (InSC)
o インド語音節カテゴリ（InSC）
o Deprecated (Dep)
o 非推奨（Dep）
The short name for each property is given in parentheses.
各プロパティの短い名前は括弧内に示されています。
If a program that is using an LGR to determine the validity of a label encounters a property that it does not support, it MUST abort with an error.
LGRを使用してラベルの有効性を判断しているプログラムが、サポートしていないプロパティに遭遇した場合、エラーで異常終了する必要があります。
A class of code points may also be declared by listing all code points that are members of the class. This is useful when tagging cannot be used because code points are not listed individually as part of the eligible set of code points for the given LGR -- for example, because they only occur in code point sequences.
コードポイントのクラスは、クラスのメンバーであるすべてのコードポイントをリストすることによっても宣言できます。これは、コードポイントが特定のLGRに適格なコードポイントのセットの一部として個別にリストされていないためにタグ付けを使用できない場合に役立ちます。たとえば、コードポイントシーケンスでのみ発生するためです。
To define a class in terms of an explicit list of code points, use a space-separated list of hexadecimal code point values:
コードポイントの明示的なリストに関してクラスを定義するには、16進コードポイント値のスペース区切りリストを使用します。
<class name="abcd">0061 0062 0063 0064</class>
This defines a class named "abcd" containing the code points for characters "a", "b", "c", and "d". The ordering of the code points is not material, but it is RECOMMENDED to list them in ascending order; not doing so makes it unnecessarily difficult for users to detect errors such as duplicates or to compare and review these classes against other specifications.
これは、文字「a」、「b」、「c」、および「d」のコードポイントを含む「abcd」という名前のクラスを定義します。コードポイントの順序は重要ではありませんが、昇順でリストすることをお勧めします。そうしないと、ユーザーが重複などのエラーを検出したり、これらのクラスを他の仕様と比較して確認したりすることが不必要に難しくなります。
In a class definition, ranges of code points are represented by a hexadecimal start and end value separated by a hyphen. The following declaration is equivalent to the preceding:
クラス定義では、コードポイントの範囲は、ハイフンで区切られた16進数の開始値と終了値で表されます。次の宣言は前述のものと同等です。
<class name="abcd">0061-0064</class>
Range and code point declarations can be freely intermixed:
範囲とコードポイントの宣言は自由に組み合わせることができます。
<class name="abcd">0061 0062-0063 0064</class>
The contents of a class differ from a repertoire in that the latter MAY contain sequences as elements, while the former MUST NOT. Instead, they closely resemble character classes as found in regular expressions.
クラスの内容はレパートリーとは異なり、後者はシーケンスを要素として含むことができますが、前者はシーケンスを含んではなりません（MUST NOT）。代わりに、正規表現にある文字クラスによく似ています。
Classes may be combined using operators for set complement, union, intersection, difference (elements of the first class that are not in the second), and symmetric difference (elements in either class but not both). Because classes fundamentally function like sets, the union of several character classes is itself a class, for example.
クラスは、集合の補数、和集合、交差、差（2番目にない最初のクラスの要素）、および対称差（両方のクラスではなく、どちらかのクラスの要素）の演算子を使用して組み合わせることができます。クラスは基本的にセットのように機能するため、たとえば、いくつかの文字クラスの結合はそれ自体がクラスです。
+-------------------+----------------------------------------------+
| Logical Operation | Example |
+-------------------+----------------------------------------------+
| Complement | <complement><class by-ref="xxx"></complement>|
+-------------------+----------------------------------------------+
| Union | <union> |
| | <class by-ref="class-1"/> |
| | <class by-ref="class-2"/> |
| | <class by-ref="class-3"/> |
| | </union> |
+-------------------+----------------------------------------------+
| Intersection | <intersection> |
| | <class by-ref="class-1"/> |
| | <class by-ref="class-2"/> |
| | </intersection> |
+-------------------+----------------------------------------------+
| Difference | <difference> |
| | <class by-ref="class-1"/> |
| | <class by-ref="class-2"/> |
| | </difference> |
+-------------------+----------------------------------------------+
| Symmetric | <symmetric-difference> |
| Difference | <class by-ref="class-1"/> |
| | <class by-ref="class-2"/> |
| | </symmetric-difference> |
+-------------------+----------------------------------------------+
Set Operators
セット演算子
The elements from this table may be arbitrarily nested inside each other, subject to the following restriction: a "complement" element MUST contain precisely one "class" or one of the operator elements, while an "intersection", "symmetric-difference", or "difference" element MUST contain precisely two, and a "union" element MUST contain two or more of these elements.
このテーブルの要素は、次の制限に従い、相互に任意にネストすることができます。「complement」要素には、「交差」、「対称差」、または「difference」要素は正確に2つを含む必要があり、「union」要素はこれらの要素を2つ以上含む必要があります。
An anonymous combined class can be defined directly inside a rule or any of the match operator elements that allow child elements (see Section 6.3.2) by using the set combination as the outer element.
匿名結合クラスは、ルールの内部で直接定義することも、子要素（セクション6.3.2を参照）を許可する任意の一致演算子要素を、外部要素としてセットの組み合わせを使用して定義することもできます。
<rule>
<union>
<class by-ref="xxx"/>
<class by-ref="yyy"/>
</union>
</rule>
The example shows the definition of an anonymous combined class that represents the union of classes "xxx" and "yyy". There is no need to wrap this union inside another "class" element, and, in fact, set combination elements MUST NOT be nested inside a "class" element.
この例は、クラス「xxx」と「yyy」の和集合を表す匿名の結合クラスの定義を示しています。この共用体を別の「クラス」要素内にラップする必要はありません。実際、セットの組み合わせ要素は「クラス」要素内にネストしてはなりません。
Lastly, to create a named combined class that can be referenced in other classes or in rules as <class by-ref="xxxyyy"/>, add a "name" attribute to the set combination element -- for example, <union name="xxxyyy" /> -- and place it at the top level immediately below the "rules" element (see Section 6.2.1).
最後に、他のクラスまたはルールで<class by-ref = "xxxyyy" />として参照できる名前付き結合クラスを作成するには、セット結合要素に「name」属性を追加します（例：<union name） = "xxxyyy" />-「rules」要素のすぐ下の最上位に配置します（セクション6.2.1を参照）。
<rules>
<union name="xxxyyy">
<class by-ref="xxx"/>
<class by-ref="yyy"/>
</union>
...
</rules>
Because (as for ordinary sets) a combination of classes is itself a class, no matter by what combinations of set operators a combined class is created, a reference to it always uses the "class" element as described in Section 6.2.1. That is, a named class is always referenced via an empty "class" element using the "by-ref" attribute containing the name of the class to be referenced.
（通常のセットと同様に）クラスの組み合わせはそれ自体がクラスであるため、セット演算子のどのような組み合わせで結合されたクラスが作成されても、セクションへの参照は常にセクション6.2.1で説明されている "class"要素を使用します。つまり、名前付きクラスは常に、参照されるクラスの名前を含む「by-ref」属性を使用して、空の「class」要素を介して参照されます。
Each rule comprises a series of matching operators that must be satisfied in order to determine whether a label meets a given condition. Rules may reference other rules or character classes defined elsewhere in the table.
各ルールは、ラベルが特定の条件を満たすかどうかを判断するために満たす必要がある一連の一致する演算子で構成されます。ルールは、テーブルの他の場所で定義されている他のルールまたは文字クラスを参照する場合があります。
A matching rule is defined by a "rule" element, the child elements of which are one of the match operators from Section 6.3.2. In evaluating a rule, each child element is matched in order. "rule" elements MAY be nested inside each other and inside certain match operators.
一致ルールは「ルール」要素によって定義され、その子要素はセクション6.3.2の一致演算子の1つです。ルールの評価では、各子要素が順番に照合されます。 "rule"要素は、互いに入れ子にしたり、特定の一致演算子の中に入れ子にしたりできます。
A simple rule to match a label where all characters are members of some class called "preferred-codepoint":
すべての文字が「preferred-codepoint」と呼ばれるクラスのメンバーであるラベルに一致する単純なルール：
<rule name="preferred-label">
<start />
<class by-ref="preferred-codepoint" count="1+"/>
<end />
</rule>
Rules are paired with explicit and implied actions, triggering these actions when a rule matches a label. For example, a simple explicit action for the rule shown above would be:
ルールは明示的アクションと暗黙的アクションとペアになっており、ルールがラベルに一致するとこれらのアクションがトリガーされます。たとえば、上記のルールの単純な明示的なアクションは次のようになります。
<action disp="allocatable" match="preferred-label" />
The rule in this example would have the effect of setting the policy disposition for a label made up entirely of preferred code points to "allocatable". Explicit actions are further discussed in Section 7 and implicit actions in Section 7.5. Another use of rules is in defining conditional contexts for code points and variants as discussed in Sections 5.2 and 5.3.5.
この例のルールには、優先コードポイントのみで構成されたラベルのポリシー配置を「割り当て可能」に設定する効果があります。明示的なアクションについてはセクション7で、暗黙のアクションについてはセクション7.5で詳しく説明します。ルールのもう1つの用途は、セクション5.2および5.3.5で説明するように、コードポイントとバリアントの条件付きコンテキストを定義することです。
A rule that is an immediate child element of the "rules" element MUST be named using a "name" attribute containing a single identifier string with no spaces. A named rule may be incorporated into another rule by reference and may also be referenced by an "action" element, "when" attribute, or "not-when" attribute. If the "name" attribute is omitted, the rule is anonymous and MUST be nested inside another rule or match operator.
「rules」要素の直接の子要素であるルールは、スペースのない単一の識別子文字列を含む「name」属性を使用して名前を付ける必要があります。名前付きルールは、参照によって別のルールに組み込むことができ、「action」要素、「when」属性、または「not-when」属性によって参照することもできます。 「name」属性が省略されている場合、ルールは匿名であり、別のルールまたは一致演算子内にネストする必要があります。
The child elements of a rule are a series of match operators, which are listed here by type and name and with a basic example or two.
ルールの子要素は一連の一致演算子であり、ここではタイプと名前で、基本的な例が1つまたは2つリストされています。
+------------+-------------+------------------------------------+
| Type | Operator | Examples |
+------------+-------------+------------------------------------+
| logical | any | <any /> |
| +-------------+------------------------------------+
| | choice | <choice> |
| | | <rule by-ref="alternative1"/> |
| | | <rule by-ref="alternative2"/> |
| | | </choice> |
+--------------------------+------------------------------------+
| positional | start | <start /> |
| +-------------+------------------------------------+
| | end | <end /> |
+--------------------------+------------------------------------+
| literal | char | <char cp="0061 0062 0063" /> |
+--------------------------+------------------------------------+
| set | class | <class by-ref="class1" /> |
| | | <class>0061 0064-0065</class> |
+--------------------------+------------------------------------+
| group | rule | <rule by-ref="rule1" /> |
| | | <rule><any /></rule> |
+--------------------------+------------------------------------+
| contextual | anchor | <anchor /> |
| +-------------+------------------------------------+
| | look-ahead | <look-ahead><any /></look-ahead> |
| +-------------+------------------------------------+
| | look-behind | <look-behind><any /></look-behind> |
+--------------------------+------------------------------------+
Match Operators
一致演算子
Any element defining an anonymous class can be used as a match operator, including any of the set combination operators (see Section 6.2.5) as well as references to named classes.
匿名クラスを定義する任意の要素を、任意の集合結合演算子（セクション6.2.5を参照）や名前付きクラスへの参照を含め、一致演算子として使用できます。
All match operators shown as empty elements in the Examples column of the table above do not support child elements of their own; otherwise, match operators MAY be nested. In particular, anonymous "rule" elements can be used for grouping.
上記の表の「例」列に空の要素として示されているすべての一致演算子は、独自の子要素をサポートしていません。それ以外の場合、一致演算子はネストできます。特に、匿名の「ルール」要素をグループ化に使用できます。
The OPTIONAL "count" attribute, when present, specifies the minimally required or maximal permitted number of times a match operator is used to match input. If the "count" attribute is
OPTIONALの「count」属性が存在する場合は、入力の照合に一致演算子が使用される最小必要回数または最大許容回数を指定します。 「count」属性が
n the match operator matches the input exactly n times, where n is 1 or greater.
n一致演算子は、入力を正確にn回照合します。nは1以上です。
n+ the match operator matches the input at least n times, where n is 0 or greater.
n +一致演算子は、入力を少なくともn回照合します。nは0以上です。
n:m the match operator matches the input at least n times, where n is 0 or greater, but matches the input up to m times in total, where m > n. If m = n and n > 0, the match operator matches the input exactly n times.
n：m一致演算子は、少なくともn回入力に一致します（nは0以上）。ただし、合計で最大m回入力に一致します（m> n）。 m = nおよびn> 0の場合、一致演算子は入力と正確にn回一致します。
If there is no "count" attribute, the match operator matches the input exactly once.
「count」属性がない場合、一致演算子は入力を1回だけ照合します。
In matching, greedy evaluation is used in the sense defined for regular expressions: beyond the required number or times, the input is matched as many times as possible, but not so often as to prevent a match of the remainder of the rule.
マッチングでは、正規表現に定義されている意味で貪欲な評価が使用されます。必要な数または回数を超えて、入力は可能な限り何度もマッチングされますが、残りのルールのマッチングを妨げるほど頻繁ではありません。
A "count" attribute MUST NOT be applied to any element that contains a "name" attribute but MAY be applied to operators such as "class" that declare anonymous classes (including combined classes) or invoke any predefined classes by reference. The "count" attribute MUST NOT be applied to any "class" element, or element defining a combined class, when it is nested inside a combined class.
「count」属性は「name」属性を含む要素には適用できませんが、匿名クラス（結合クラスを含む）を宣言する「class」などの演算子に適用したり、参照により事前定義されたクラスを呼び出したりしてもよいです（MAY）。 「count」属性は、「class」要素、または結合されたクラス内にネストされている場合、結合されたクラスを定義する要素に適用してはなりません（MUST NOT）。
A "count" attribute MUST NOT be applied to match operators of type "start", "end", "anchor", "look-ahead", or "look-behind" or to any operators, such as "rule" or "choice", that contain a nested instance of them. This limitation applies recursively and irrespective of whether a "rule" element containing these nested instances is declared in place or used by reference.
「count」属性は、タイプ「start」、「end」、「anchor」、「look-ahead」、または「look-behind」の演算子、または「rule」や「それらのネストされたインスタンスが含まれています。この制限は、これらのネストされたインスタンスを含む「ルール」要素が適切に宣言されているか、参照によって使用されているかに関係なく、再帰的に適用されます。
However, the "count" attribute MAY be applied to any other instances of either an anonymous "rule" element or a "choice" element, including those instances nested inside other match operators. It MAY also be applied to the elements "any" and "char", when used as match operators.
ただし、「count」属性は、匿名の「rule」要素または「choice」要素のいずれかの他のインスタンス（他の一致演算子内にネストされているインスタンスを含む）に適用される場合があります。一致演算子として使用する場合、要素「any」と「char」にも適用できます（MAY）。
Like classes (see Section 6.2.1), rules declared as immediate child elements of the "rules" element MUST be named using a unique "name" attribute, and all other instances MUST NOT be named. Anonymous rules and classes or references to named rules and classes can be nested inside other match operators by reference.
クラス（セクション6.2.1を参照）と同様に、「rules」要素の直接の子要素として宣言されたルールには、一意の「name」属性を使用して名前を付ける必要があり、他のすべてのインスタンスに名前を付けることはできません。匿名のルールとクラス、または名前付きのルールとクラスへの参照は、参照によって他の一致演算子内にネストできます。
To reference a named rule or class inside a rule or match operator, use a "rule" or "class" element with an OPTIONAL "by-ref" attribute containing the name of the referenced element. It is an error to reference a rule or class for which the complete definition has not been seen. In other words, it is explicitly not possible to define recursive rules or class definitions. The "by-ref" attribute MUST NOT appear in the same element as the "name" attribute or in an element that has any child elements.
ルールまたは照合演算子内の名前付きルールまたはクラスを参照するには、「ルール」または「クラス」要素を、参照される要素の名前を含むオプションの「by-ref」属性とともに使用します。完全な定義が確認されていないルールまたはクラスを参照すると、エラーになります。つまり、再帰的なルールやクラス定義を定義することは明示的に不可能です。 「by-ref」属性は、「name」属性と同じ要素または子要素を持つ要素に出現してはなりません（MUST NOT）。
The example shows several named classes and a named rule referencing some of them by name.
この例は、いくつかの名前付きクラスと、名前でそれらのいくつかを参照する名前付きルールを示しています。
<class name="letter" property="gc:L"/>
<class name="combining-mark" property="gc:M"/>
<class name="digit" property="gc:Nd" />
<rule name="letter-grapheme">
<class by-ref="letter" count="1+"/>
<class by-ref="combining-mark" count="0+"/>
</rule>
The "choice" element is used to represent a list of two or more alternatives:
「choice」要素は、2つ以上の選択肢のリストを表すために使用されます。
<rule name="ldh">
<choice count="1+">
<class by-ref="letter"/>
<class by-ref="digit"/>
<char cp="002D" comment="literal HYPHEN"/>
</choice>
</rule>
Each child element of a "choice" element represents one alternative. The first matching alternative determines the match for the "choice" element. To express a choice where an alternative itself consists of a sequence of elements, the sequence must be wrapped in an anonymous rule.
「choice」要素の各子要素は、1つの選択肢を表します。最初に一致する選択肢は、「choice」要素の一致を決定します。選択肢自体が要素のシーケンスで構成される選択肢を表現するには、シーケンスを匿名のルールでラップする必要があります。
A literal code point sequence matches a single code point or a sequence. It is defined by a "char" element, with the code point or sequence to be matched given by the "cp" attribute. When used as a literal, a "char" element MAY contain a "count" attribute in addition to the "cp" attribute and OPTIONAL "comment" or "ref" attributes. No other attributes or child elements are permitted.
リテラルコードポイントシーケンスは、単一のコードポイントまたはシーケンスと一致します。これは「char」要素で定義され、一致するコードポイントまたはシーケンスは「cp」属性で指定されます。リテラルとして使用する場合、「char」要素には、「cp」属性とオプションの「comment」または「ref」属性に加えて「count」属性を含めることができます（MAY）。他の属性や子要素は許可されていません。
The "any" element is an empty element that matches any single code point. It MAY have a "count" attribute. For an example, see Section 6.3.9.
「any」要素は、任意の単一のコードポイントに一致する空の要素です。 「count」属性を持つ場合があります。例については、セクション6.3.9を参照してください。
Unlike a literal, the "any" element MUST NOT have a "ref" attribute.
リテラルとは異なり、「any」要素には「ref」属性があってはなりません。
To match the beginning or end of a label, use the "start" or "end" element. An empty label would match this rule:
ラベルの最初または最後に一致させるには、「start」または「end」要素を使用します。空のラベルはこのルールに一致します。
<rule name="empty-label">
<start/>
<end/>
</rule>
Conceptually, whole label rules evaluate the label as a whole, but in practice, many rules do not actually need to be specified to match the entire label. For example, to express a requirement of not starting a label with a digit, a rule needs to describe only the initial part of a label.
概念的には、全体のラベルルールはラベル全体を評価しますが、実際には、多くのルールは実際にはラベル全体と一致するように指定する必要はありません。たとえば、ラベルを数字で始めないという要件を表現するには、ルールはラベルの最初の部分のみを記述する必要があります。
This example uses the previously defined rules, together with "start" and "end" elements, to define a rule that requires that an entire label be well-formed. For this example, that means that it must start with a letter and that it contains no leading digits or combining marks nor combining marks placed on digits.
この例では、前に定義したルールを「開始」および「終了」要素とともに使用して、ラベル全体を整形式にする必要があるルールを定義します。この例の場合、これは文字で始まる必要があり、先行する数字、結合マーク、または数字に配置された結合マークが含まれていないことを意味します。
<rule name="leading-letter" >
<start />
<rule by-ref="letter-grapheme" count="1"/>
<choice count="0+">
<rule by-ref="letter-grapheme" count="0+"/>
<class by-ref="digit" count="0+"/>
</choice>
<end />
</rule>
Each "start" or "end" element occurs at most once in a rule, except if nested inside a "choice" element in such a way that in matching each alternative at most one occurrence of each is encountered. Otherwise, the result is an error, as is any case where a "start" or "end" element is not encountered as the first or last element to be matched, respectively, in matching a rule. "start" and "end" elements are empty elements that do not have a "count" attribute or any other attribute other than "comment". It is an error for any match operator enclosing a nested "start" or "end" element to have a "count" attribute.
各「開始」または「終了」要素は、「選択肢」要素内にネストされている場合を除いて、ルール内で最大1回発生します。それ以外の場合、ルールのマッチングで「最初」または「最後」の要素がそれぞれ最初または最後の要素として検出されない場合と同様に、結果はエラーになります。 「開始」および「終了」要素は、「カウント」属性または「コメント」以外の他の属性を持たない空の要素です。ネストされた「開始」または「終了」要素を囲む一致演算子が「カウント」属性を持つことはエラーです。
This is an example of the WLE rule from [RFC5892] forbidding the mixture of the Arabic-Indic and extended Arabic-Indic digits in the same label. It is implemented as a whole label rule associated with the code point ranges using the "not-when" attribute, which defines an impermissible context. The example also demonstrates several instances of the use of anonymous rules for grouping.
これは、[RFC5892]のWLEルールの例であり、同じラベルでアラビア語と拡張アラビア語の数字の混合を禁止しています。これは、許可されないコンテキストを定義する「not-when」属性を使用して、コードポイント範囲に関連付けられた全体のラベルルールとして実装されます。この例では、グループ化に匿名ルールを使用するいくつかの例も示しています。
<data>
<range first-cp="0660" last-cp="0669" not-when="mixed-digits"
tag="arabic-indic-digits" />
<range first-cp="06F0" last-cp="06F9" not-when="mixed-digits"
tag="extended-arabic-indic-digits" />
</data>
<rules>
<rule name="mixed-digits">
<choice>
<rule>
<class from-tag="arabic-indic-digits"/>
<any count="0+"/>
<class from-tag="extended-arabic-indic-digits"/>
</rule>
<rule>
<class from-tag="extended-arabic-indic-digits"/>
<any count="0+"/>
<class from-tag="arabic-indic-digits"/>
</rule>
</choice>
</rule>
</rules>
As specified in the example, a label containing a code point from either of the two digit ranges is invalid for any label matching the "mixed-digits" rule, that is, any time that a code point from the other range is also present. Note that invalidating the label is not the same as invalidating the definition of the "range" elements; in particular, the definition of the tag values does not depend on the "when" attribute.
例で指定されているように、2桁の範囲のいずれかからのコードポイントを含むラベルは、「数字の混在」ルールに一致するすべてのラベル、つまり、他の範囲のコードポイントも存在する場合は無効です。ラベルを無効にすることは、「範囲」要素の定義を無効にすることと同じではないことに注意してください。特に、タグ値の定義は「いつ」属性に依存しません。
To recap: When a rule is intended to provide a context for evaluating the validity of a code point or variant mapping, it is invoked by the "when" or "not-when" attributes described in Section 5.2. For "char" and "range" elements, an action implied by a context rule always has a disposition of "invalid" whenever the rule given by the "when" attribute is not matched (see Section 7.5). Conversely, a "not-when" attribute results in a disposition of "invalid" whenever the rule is matched. When a rule is used in this way, it is called a context or "when" rule.
要約すると、ルールがコードポイントまたはバリアントマッピングの有効性を評価するためのコンテキストを提供することを目的としている場合、セクション5.2で説明されている「when」または「not-when」属性によって呼び出されます。 「char」および「range」要素の場合、「when」属性によって指定されたルールが一致しない場合は常に、コンテキストルールによって暗示されるアクションの処理が常に「無効」になります（セクション7.5を参照）。逆に、「not-when」属性は、ルールが一致した場合は常に「無効」の性質を持ちます。ルールがこのように使用される場合、コンテキストまたは「いつ」ルールと呼ばれます。
The example in the previous section shows a whole label rule used as a context rule, essentially making the whole label the context. The next sections describe several match operators that can be used to provide a more specific specification of a context, allowing a parameterized context rule. See Section 7 for an alternative method of defining an invalid disposition for a label not matching a whole label rule.
前のセクションの例は、コンテキストルールとして使用されるラベルルール全体を示し、基本的にラベル全体をコンテキストにします。次のセクションでは、コンテキストのより具体的な仕様を提供し、パラメーター化されたコンテキストルールを可能にするために使用できるいくつかの一致演算子について説明します。ラベルルール全体と一致しないラベルに無効な後処理を定義する別の方法については、セクション7を参照してください。
Such parameterized context rules are rules that contain a special placeholder represented by an "anchor" element. As each When Rule is evaluated, if an "anchor" element is present, it is replaced by a literal corresponding to the "cp" attribute of the element containing the "when" (or "not-when") attribute. The match to the "anchor" element must be at the same position in the label as the code point or variant mapping triggering the When Rule.
このようなパラメーター化されたコンテキストルールは、「アンカー」要素で表される特別なプレースホルダーを含むルールです。 Whenルールが評価されるたびに、「アンカー」要素が存在する場合は、「when」（または「not-when」）属性を含む要素の「cp」属性に対応するリテラルに置き換えられます。 「アンカー」要素への一致は、Whenルールをトリガーするコードポイントまたはバリアントマッピングと同じラベルの位置にある必要があります。
For example, the Greek lower numeral sign is invalid if not immediately preceding a character in the Greek script. This is most naturally addressed with a parameterized When Rule using "look-ahead":
たとえば、ギリシャ語の小文字の数字記号は、ギリシャ語のスクリプトの文字の直前になければ無効です。これは、「先読み」を使用するパラメータ化されたWhenルールで最も自然に対処されます。
<char cp="0375" when="preceding-greek"/>
...
<class name="greek-script" property="sc:Grek"/>
<rule name="preceding-greek">
<anchor/>
<look-ahead>
<class by-ref="greek-script"/>
</look-ahead>
</rule>
In evaluating this rule, the "anchor" element is treated as if it was replaced by a literal
このルールを評価する際、「アンカー」要素はリテラルで置き換えられたかのように扱われます
<char cp="0375"/>
but only the instance of U+0375 at the given position is evaluated. If a label had two instances of U+0375 with the first one matching the rule and the second not, then evaluating the When Rule MUST succeed for the first instance and fail for the second.
ただし、指定された位置にあるU + 0375のインスタンスのみが評価されます。ラベルにU + 0375の2つのインスタンスがあり、最初のインスタンスがルールに一致し、2番目のインスタンスが一致しない場合、Whenルールの評価は最初のインスタンスに成功し、2番目に失敗する必要があります。
Unlike other rules, rules containing an "anchor" element MUST only be invoked via the "when" or "not-when" attributes on code points or variants; otherwise, their "anchor" elements cannot be evaluated. However, it is possible to invoke rules not containing an "anchor" element from a "when" or "not-when" attribute. (See Section 6.4.3.)
他のルールとは異なり、 "anchor"要素を含むルールは、コードポイントまたはバリアントの "when"または "not-when"属性を介してのみ呼び出す必要があります。そうでない場合、それらの「アンカー」要素は評価できません。ただし、「when」または「not-when」属性から「anchor」要素を含まないルールを呼び出すことは可能です。 （6.4.3項を参照してください。）
The "anchor" element is an empty element, with no attributes permitted except "comment".
「アンカー」要素は空の要素であり、「コメント」以外の属性は許可されません。
Context rules use the "look-behind" and "look-ahead" elements to define context before and after the code point sequence matched by the "anchor" element. If the "anchor" element is omitted, neither the "look-behind" nor the "look-ahead" element may be present in a rule.
コンテキストルールは、「後読み」要素と「先読み」要素を使用して、「アンカー」要素と一致するコードポイントシーケンスの前後のコンテキストを定義します。 「アンカー」要素が省略されている場合、「後読み」要素も「先読み」要素もルールに存在しない可能性があります。
Here is an example of a rule that defines an "initial" context for an Arabic code point:
以下は、アラビア語コードポイントの「初期」コンテキストを定義するルールの例です。
<class name="transparent" property="jt:T"/>
<class name="right-joining" property="jt:R"/>
<class name="left-joining" property="jt:L"/>
<class name="dual-joining" property="jt:D"/>
<class name="non-joining" property="jt:U"/>
<rule name="Arabic-initial">
<look-behind>
<choice>
<start/>
<rule>
<class by-ref="transparent" count="0+"/>
<class by-ref="non-joining"/>
</rule>
</choice>
</look-behind>
<anchor/>
<look-ahead>
<class by-ref="transparent" count="0+" />
<choice>
<class by-ref="right-joining" />
<class by-ref="dual-joining" />
</choice>
</look-ahead>
</rule>
A "when" rule (or context rule) is a named rule that contains any combination of "look-behind", "anchor", and "look-ahead" elements, in that order. Each of these elements occurs at most once, except if nested inside a "choice" element in such a way that in matching each alternative at most one occurrence of each is encountered. Otherwise, the result is undefined. None of these elements takes a "count" attribute, nor does any enclosing match operator; otherwise, the result is undefined. If a context rule contains a "look-ahead" or "look-behind" element, it MUST contain an "anchor" element. If, because of a "choice" element, a required anchor is not actually encountered, the results are undefined.
「いつ」ルール（またはコンテキストルール）は、「後読み」、「アンカー」、および「先読み」要素をこの順序で組み合わせた名前付きルールです。これらの各要素は、「選択肢」要素内にネストされている場合を除き、最大で1回発生します。それ以外の場合、結果は未定義です。これらの要素はいずれも「カウント」属性を取りません。また、囲んでいる一致演算子も取りません。それ以外の場合、結果は未定義です。コンテキストルールに「先読み」または「先読み」要素が含まれている場合は、「アンカー」要素が含まれている必要があります。 「choice」要素が原因で、必要なアンカーが実際に検出されない場合、結果は未定義です。
If the "anchor" element is omitted, the evaluation of the context rule is not tied to the position of the code point or sequence associated with the "when" attribute.
「アンカー」要素を省略した場合、コンテキストルールの評価は、「いつ」属性に関連付けられたコードポイントまたはシーケンスの位置に関連付けられません。
According to [RFC5892], the Katakana middle dot is invalid in any label not containing at least one Japanese character anywhere in the label. Because this requirement is independent of the position of the middle dot, the rule does not require an "anchor" element.
[RFC5892]によれば、カタカナの真ん中のドットは、少なくとも1つの日本語文字が含まれていないラベルでは無効です。この要件は中央のドットの位置とは無関係であるため、ルールには「アンカー」要素は必要ありません。
<char cp="30FB" when="japanese-in-label"/>
<rule name="japanese-in-label">
<union>
<class property="sc:Hani"/>
<class property="sc:Kata"/>
<class property="sc:Hira"/>
</union>
</rule>
The Katakana middle dot is used only with Han, Katakana, or Hiragana. The corresponding When Rule requires that at least one code point in the label be in one of these scripts, but the position of that code point is independent of the location of the middle dot; therefore, no anchor is required. (Note that the Katakana middle dot itself is of script Common, that is, "sc:Zyyy".)
カタカナの中点は、漢字、カタカナ、またはひらがなでのみ使用されます。対応するWhenルールでは、ラベル内の少なくとも1つのコードポイントがこれらのスクリプトの1つにある必要がありますが、そのコードポイントの位置は中央のドットの位置とは無関係です。したがって、アンカーは必要ありません。 （カタカナの真ん中のドット自体は、スクリプトCommon、つまり "sc：Zyyy"であることに注意してください。）
The purpose of an action is to assign a disposition to a label in response to being triggered by the label meeting a specified condition. Often, the action simply results in blocking or invalidating a label that does not match a rule. An example of an action invalidating a label because it does not match a rule named "leading-letter" is as follows:
アクションの目的は、指定された条件を満たすラベルによってトリガーされることに応答して、ラベルに後処理を割り当てることです。多くの場合、アクションの結果、ルールに一致しないラベルがブロックまたは無効化されるだけです。 「リーディングレター」という名前のルールに一致しないためにラベルを無効にするアクションの例は次のとおりです。
<action disp="invalid" not-match="leading-letter"/>
If an action is to be triggered on matching a rule, a "match" attribute is used instead. Actions are evaluated in the order that they appear in the XML file. Once an action is triggered by a label, the disposition defined in the "disp" attribute is assigned to the label and no other actions are evaluated for that label.
ルールの一致時にアクションがトリガーされる場合は、代わりに「一致」属性が使用されます。アクションは、XMLファイルに出現する順序で評価されます。アクションがラベルによってトリガーされると、「disp」属性で定義された後処理がラベルに割り当てられ、そのラベルに対して他のアクションは評価されません。
The goal of the LGR is to identify all labels and variant labels and to assign them disposition values. These dispositions are then fed into a further process that ultimately implements all aspects of policy. To allow this specification to be used with the widest range of policies, the permissible values for the "disp" attribute are neither defined nor restricted. Nevertheless, a set of commonly used disposition values is RECOMMENDED. (See Section 7.3.)
LGRの目的は、すべてのラベルとバリアントラベルを識別し、それらにディスポジション値を割り当てることです。これらの処分は、最終的にポリシーのすべての側面を実装する追加のプロセスに送られます。この仕様を幅広いポリシーで使用できるようにするために、「disp」属性の許容値は定義も制限もされていません。それにもかかわらず、一般的に使用される一連の処置値を推奨します。 （7.3項を参照してください。）
An OPTIONAL "match" or "not-match" attribute specifies a rule that must be matched or not matched as a condition for triggering an action. Only a single rule may be named as the value of a "match" or "not-match" attribute. Because rules may be composed of other rules, this restriction to a single attribute value does not impose any limitation on the contexts that can trigger an action.
オプションの "match"または "not-match"属性は、アクションをトリガーするための条件として、一致する必要があるルールまたは一致しないルールを指定します。 「一致」または「非一致」属性の値として指定できるルールは1つだけです。ルールは他のルールで構成されている場合があるため、単一の属性値に対するこの制限は、アクションをトリガーできるコンテキストに制限を課しません。
An action MUST NOT contain both a "match" and a "not-match" attribute, and the value of either attribute MUST be the name of a previously defined rule; otherwise, the document MUST be rejected. An action without any attributes is triggered by all labels unconditionally. For a very simple LGR, the following action would allocate all labels that match the repertoire:
アクションには、「一致」属性と「非一致」属性の両方を含めることはできません。また、いずれかの属性の値は、以前に定義されたルールの名前である必要があります。それ以外の場合は、ドキュメントを拒否する必要があります。属性のないアクションは、すべてのラベルによって無条件にトリガーされます。非常に単純なLGRの場合、次のアクションはレパートリーに一致するすべてのラベルを割り当てます。
<action disp="allocatable" />
Since rules are evaluated for all labels, whether they are the original label or computed by permuting the defined and valid variant mappings for the label's code points, actions based on matching or not matching a rule may be triggered for both original and variant labels, but the rules are not affected by the disposition attributes of the variant mappings. To trigger any actions based on these dispositions requires the use of additional optional attributes for actions described next.
ルールはすべてのラベルに対して評価されるため、それらが元のラベルであるか、ラベルのコードポイントに対して定義された有効なバリアントマッピングを並べ替えることによって計算されるかにかかわらず、ルールの一致または不一致に基づくアクションは、元のラベルとバリアントラベルの両方でトリガーされますが、ルールは、バリアントマッピングの後処理属性の影響を受けません。これらの後処理に基づいてアクションをトリガーするには、次に説明するアクションに追加のオプション属性を使用する必要があります。
7.2.1. The "any-variant", "all-variants", and "only-variants" Attributes
7.2.1. 「任意のバリアント」、「すべてのバリアント」、および「のみのバリアント」の属性
An action may contain one of the OPTIONAL attributes "any-variant", "all-variants", or "only-variants" defining triggers based on variant types. The permitted value for these attributes consists of one or more variant type values, separated by spaces. These MAY include type values that are not used in any "var" element in the LGR. When a variant label is generated, these variant type values are compared to the set of type values on the variant mappings used to generate the particular variant label (see Section 8).
アクションには、バリアントタイプに基づいてトリガーを定義するオプション属性「any-variant」、「all-variants」、または「only-variants」のいずれかを含めることができます。これらの属性に許可される値は、スペースで区切られた1つ以上のバリアント型の値で構成されます。これらには、LGRの「var」要素で使用されていないタイプ値が含まれる場合があります。バリアントラベルが生成されると、これらのバリアントタイプの値は、特定のバリアントラベルの生成に使用されるバリアントマッピングのタイプ値のセットと比較されます（セクション8を参照）。
Any single match may trigger an action that contains an "any-variant" attribute, while for an "all-variants" or "only-variants" attribute, the variant type for all variant code points must match one or several of the type values specified in the attribute to trigger the action. There is no requirement that the entire list of variant type values be matched, as long as all variant code points match at least one of the values.
単一の一致は「any-variant」属性を含むアクションをトリガーする可能性がありますが、「all-variants」または「only-variants」属性の場合、すべてのバリアントコードポイントのバリアントタイプは1つ以上のタイプ値と一致する必要があります属性で指定してアクションをトリガーします。すべてのバリアントコードポイントが値の少なくとも1つに一致する限り、バリアントタイプの値のリスト全体が一致する必要はありません。
An "only-variants" attribute will trigger the action only if all code points of the variant label have variant mappings from the original code points. In other words, the label contains no original code points other than those with a reflexive mapping (see Section 5.3.4).
「バリアントのみ」属性は、バリアントラベルのすべてのコードポイントに元のコードポイントからのバリアントマッピングがある場合にのみアクションをトリガーします。言い換えると、ラベルには、再帰マッピングを使用したコードポイント以外の元のコードポイントは含まれていません（セクション5.3.4を参照）。
<char cp="0078" comment="x">
<var cp="0078" type="allocatable" comment="reflexive" />
<var cp="0079" type="blocked" />
</char>
<char cp="0079" comment="y">
<var cp="0078" type="allocatable" />
</char>
...
<action disp="blocked" any-variant="blocked" />
<action disp="allocatable" only-variants="allocatable" />
<action disp="some-disp" any-variant="allocatable" />
In the example above, the label "xx" would have variant labels "xx", "xy", "yx", and "yy". The first action would result in blocking any variant label containing "y", because the variant mapping from "x" to "y" is of type "blocked", triggering the "any-variant" condition. Because in this example "x" has a reflexive variant mapping to itself of type "allocatable", the original label "xx" has a reflexive variant "xx" that would trigger the "only-variants" condition on the second action.
上記の例では、ラベル「xx」にはバリアントラベル「xx」、「xy」、「yx」、「yy」があります。最初のアクションは、「x」から「y」へのバリアントマッピングのタイプが「blocked」であり、「any-variant」条件をトリガーするため、「y」を含むすべてのバリアントラベルをブロックします。この例では、「x」にはタイプ「割り当て可能」のそれ自体への再帰バリアントマッピングがあるため、元のラベル「xx」には、2番目のアクションで「only-variants」条件をトリガーする再帰バリアント「xx」があります。
A label "yy" would have the variants "xy", "yx", and "xx". Because the variant mapping from "y" to "x" is of type "allocatable" and a mapping from "y" to "y" is not defined, the labels "xy" and "yx" trigger the "any-variant" condition on the third label. The variant "xx", being generated using the mapping from "y" to "x" of type "allocatable", would trigger the "only-variants" condition on the section action. As there is no reflexive variant "yy", the original label "yy" cannot trigger any variant type triggers. However, it could still trigger an action defined as matching or not matching a rule.
ラベル「yy」には、バリアント「xy」、「yx」、「xx」があります。 「y」から「x」へのバリアントマッピングのタイプは「割り当て可能」であり、「y」から「y」へのマッピングは定義されていないため、ラベル「xy」と「yx」は「any-variant」条件をトリガーします3番目のラベル。タイプ「割り当て可能」の「y」から「x」へのマッピングを使用して生成されたバリアント「xx」は、セクションアクションで「only-variants」条件をトリガーします。再帰バリアント "yy"がないため、元のラベル "yy"はバリアントタイプトリガーをトリガーできません。ただし、ルールの一致または不一致として定義されているアクションはトリガーされます。
In each action, one variant type trigger may be present by itself or in conjunction with an attribute matching or not matching a rule. If variant triggers and rule-matching triggers are used together, the label MUST "match" or respectively "not-match" the specified rule AND satisfy the conditions on the variant type values given by the "any-variant", "all-variants", or "only-variants" attribute.
各アクションでは、1つのバリアントタイプトリガーが単独で、またはルールと一致するか一致しない属性と組み合わせて存在する可能性があります。バリアントトリガーとルールマッチングトリガーを一緒に使用する場合、ラベルは、指定されたルールを「一致」または「一致」せず、「any-variant」、「all-variants」で指定されたバリアントタイプの値の条件を満たす必要があります。 "、または" only-variants "属性。
A useful convention combines the "any-variant" trigger with reflexive variant mappings (Section 5.3.4). This convention is used, for example, when multiple LGRs are defined within the same registry and for overlapping repertoire. In some cases, the delegation of a label from one LGR must prohibit the delegation of another label in some other LGR. This can be done using a variant of type "blocked" as in this example from an Armenian LGR, where the Armenian, Latin, and Cyrillic letters all look identical:
便利な規則では、「任意バリアント」トリガーを再帰バリアントマッピングと組み合わせます（セクション5.3.4）。この規則は、たとえば、同じレジストリ内で複数のLGRが定義されている場合や、重複するレパートリーに使用されます。場合によっては、あるLGRからのラベルの委任は、他のLGRでの別のラベルの委任を禁止する必要があります。これは、アルメニア語、ラテン語、キリル文字がすべて同じに見えるアルメニア語LGRからのこの例のように、「ブロック」タイプのバリアントを使用して行うことができます。
<char cp="0570" comment="ARMENIAN SMALL LETTER HO">
<var cp="0068" type="blocked" comment="LATIN SMALL LETTER H" />
<var cp="04BB" type="blocked"
comment="CYRILLIC SMALL LETTER SHHA" />
</char>
The issue is that the target code points for these two variants are both outside the Armenian repertoire. By using a reflexive variant with the following convention:
問題は、これら2つのバリアントのターゲットコードポイントが両方ともアルメニアのレパートリーの外にあることです。以下の規則で再帰バリアントを使用することにより：
<char cp="0068" comment="not part of repertoire"> <var cp="0068" type="out-of-repertoire-var" comment="reflexive mapping" /> <var cp="04BB" type="blocked" /> <var cp="0570" type="blocked" /> </char> ...
<char cp = "0068" comment = "レパートリーの一部ではありません"> <var cp = "0068" type = "out-of-repertoire-var" comment = "reflexive mapping" /> <var cp = "04BB"タイプ= "blocked" /> <var cp = "0570" type = "blocked" /> </ char> ...
and associating this with an action of the form:
これをフォームのアクションに関連付ける：
<action disp="invalid" any-variant="out-of-repertoire-var" />
it is possible to list the symmetric and transitive variant mappings in the LGR even where they involve out-of-repertoire code points. By associating the action shown with the special type for these reflexive mappings, any original labels containing one or more of the out-of-repertoire code points are filtered out, just as if these code points had not been listed in the LGR in the first place. Nevertheless, they do participate in the permutation of variant labels for n-repertoire labels (Armenian in the example), and these permuted variants can be used to detect collisions with out-of-repertoire labels (see Section 8).
レパートリー外のコードポイントが含まれている場合でも、LGRに対称的で推移的なバリアントマッピングをリストすることができます。示されているアクションをこれらの再帰マッピングの特別なタイプに関連付けることにより、これらのコードポイントが最初のLGRにリストされていなかったかのように、1つ以上のレパートリー外のコードポイントを含む元のラベルが除外されます場所。それにもかかわらず、それらはnレパートリーラベル（例ではアルメニア語）のバリアントラベルの順列に参加し、これらの順列バリアントはレパートリー外ラベルとの衝突を検出するために使用できます（セクション8を参照）。
This section gives an example of using variant type triggers, combined with variants with reflexive mappings (Section 5.3.4), to achieve LGRs that implement tables like those defined according to [RFC3743] where the goal is to allow as variants only labels that consist entirely of simplified or traditional variants, in addition to the original label.
このセクションでは、バリアントタイプトリガーを再帰マッピング（セクション5.3.4）と組み合わせて使用し、[RFC3743]に従って定義されているようなテーブルを実装するLGRを実現する例を示します。元のラベルに加えて、完全に簡略化されたまたは従来のバリアント。
This example assumes an LGR where all variants have been given suitable "type" attributes of "blocked", "simplified", "traditional", or "both", similar to the ones discussed in Appendix B. Given such an LGR, the following example actions evaluate the disposition for the variant label:
この例は、すべてのバリアントに、「ブロック」、「簡略化」、「従来」、または「両方」の適切な「タイプ」属性が与えられているLGRを想定しています。付録Bで説明したものと同様です。アクションの例では、バリアントラベルの後処理を評価します。
<action disp="blocked" any-variant="blocked" />
<action disp="allocatable" only-variants="simplified both" />
<action disp="allocatable" only-variants="traditional both" />
<action disp="blocked" all-variants="simplified traditional" />
<action disp="allocatable" />
The first action matches any variant label for which at least one of the code point variants is of type "blocked". The second matches any variant label for which all of the code point variants are of type "simplified" or "both" -- in other words, an all-simplified label. The third matches any label for which all variants are of type "traditional" or "both" -- that is, all traditional. These two actions are not triggered by any variant labels containing some original code points, unless each of those code points has a variant defined with a reflexive mapping (Section 5.3.4).
最初のアクションは、コードポイントバリアントの少なくとも1つが「ブロック」タイプであるすべてのバリアントラベルと一致します。 2番目は、すべてのコードポイントバリアントが「単純化」または「両方」タイプのバリアントラベルと一致します。つまり、すべて単純化されたラベルです。 3番目は、すべてのバリアントのタイプが「伝統的」または「両方」、つまりすべて伝統的であるすべてのラベルに一致します。これらの2つのアクションは、いくつかの元のコードポイントを含むバリアントラベルではトリガーされません。
The final two actions rely on the fact that actions are evaluated in sequence and that the first action triggered also defines the final disposition for a variant label (see Section 7.4). They further rely on the assumption that the only variants with type "both" are also reflexive variants.
最後の2つのアクションは、アクションが順番に評価され、トリガーされた最初のアクションがバリアントラベルの最終的な性質も定義するという事実に依存しています（セクション7.4を参照）。さらに、「両方」タイプのバリアントも再帰バリアントであるという仮定に依存しています。
Given these assumptions, any remaining simplified or traditional variants must then be part of a mixed label and so are blocked; all labels surviving to the last action are original code points only (that is, the original label). The example assumes that an original label may be a mixed label; if that is not the case, the disposition for the last action would be set to "blocked".
これらの仮定を前提として、残りの単純化されたまたは従来のバリアントは混合ラベルの一部である必要があるため、ブロックされます。最後のアクションまで存続するすべてのラベルは、元のコードポイントのみです（つまり、元のラベル）。この例では、元のラベルが混合ラベルである可能性があると想定しています。そうでない場合、最後のアクションの後処理は「ブロック」に設定されます。
There are exceptions where the assumption on reflexive mappings made above does not hold, so this basic scheme needs some refinements to cover all cases. For a more complete example, see Appendix B.
上記の再帰的マッピングに関する仮定が当てはまらない例外があるため、この基本的なスキームでは、すべてのケースをカバーするためにいくつかの改良が必要です。より完全な例については、付録Bを参照してください。
The precise nature of the policy action taken in response to a disposition and the name of the corresponding "disp" attributes are only partially defined here. It is strongly RECOMMENDED to use the following dispositions only in their conventional sense.
ここでは、廃棄に対応して実行されるポリシーアクションの正確な性質と、対応する「disp」属性の名前の一部のみを定義しています。以下の処理を従来の意味でのみ使用することを強くお勧めします。
invalid The resulting string is not a valid label. This disposition may be assigned implicitly; see Section 7.5. No variant labels should be generated from a variant mapping with this type.
invalid結果の文字列は有効なラベルではありません。この処置は暗黙的に割り当てられる場合があります。セクション7.5を参照してください。このタイプのバリアントマッピングからバリアントラベルを生成しないでください。
blocked The resulting string is a valid label but should be blocked from registration. This would typically apply for a derived variant that is undesirable due to having no practical use or being confusingly similar to some other label.
blocked結果の文字列は有効なラベルですが、登録をブロックする必要があります。これは通常、実用的でないか、他のラベルと混同されているために望ましくない派生バリアントに適用されます。
allocatable The resulting string should be reserved for use by the same operator of the origin string but not automatically allocated for use.
allocatable結果の文字列は、元の文字列と同じ演算子で使用するために予約する必要がありますが、使用のために自動的に割り当てられることはありません。
activated The resulting string should be activated for use. (This is the same as a Preferred Variant [RFC3743].)
アクティベートされた文字列は、使用するためにアクティベートする必要があります。 （これは優先バリアント[RFC3743]と同じです。）
valid The resultant string is a valid label. (This is the typical default action if no dispositions are defined.)
有効な結果の文字列は有効なラベルです。 （これは、後処理が定義されていない場合の一般的なデフォルトのアクションです。）
Actions are applied in the order of their appearance in the file. This defines their relative precedence. The first action triggered by a label defines the disposition for that label. To define the order of precedence, list the actions in the desired order. The conventional order of precedence for the actions defined in Section 7.3 is "invalid", "blocked", "allocatable", "activated", and then "valid". This default precedence is used for the default actions defined in Section 7.6.
アクションは、ファイル内での出現順に適用されます。これは、相対的な優先順位を定義します。ラベルによってトリガーされる最初のアクションは、そのラベルの後処理を定義します。優先順位を定義するには、アクションを希望の順序でリストします。セクション7.3で定義されているアクションの従来の優先順位は、「無効」、「ブロック」、「割り当て可能」、「アクティブ化」、「有効」の順です。このデフォルトの優先順位は、セクション7.6で定義されているデフォルトのアクションに使用されます。
The context rules on code points ("not-when" or "when" rules) carry an implied action with a disposition of "invalid" (not eligible) if a "when" context is not satisfied or a "not-when" context is matched, respectively. These rules are evaluated at the time the code points for a label or its variant labels are checked for validity (see Section 8). In other words, they are evaluated before any of the actions are applied, and with higher precedence. The context rules for variant mappings are evaluated when variants are generated and/or when variant tables are made symmetric and transitive. They have an implied action with a disposition of "invalid", which means that a putative variant mapping does not exist whenever the given context matches a "not-when" rule or fails to match a "when" rule specified for that mapping. The result of that disposition is that the variant mapping is ignored in generating variant labels and the value is therefore not accessible to trigger any explicit actions.
コードポイントのコンテキストルール（ "not-when"または "when"ルール）は、 "when"コンテキストが満たされない場合、または "not-when"コンテキストの場合、 "無効"（対象外）の性質を持つ暗黙のアクションを実行しますそれぞれ一致します。これらのルールは、ラベルまたはそのバリアントラベルのコードポイントの有効性がチェックされるときに評価されます（セクション8を参照）。つまり、アクションが適用される前に評価され、優先順位が高くなります。バリアントマッピングのコンテキストルールは、バリアントが生成されたとき、および/またはバリアントテーブルが対称的で推移的になったときに評価されます。これらには、「無効」の性質を持つ暗黙のアクションがあります。つまり、特定のコンテキストが「not-when」ルールに一致するか、そのマッピングに指定された「when」ルールに一致しない場合、推定バリアントマッピングは存在しません。その処理の結果、バリアントマッピングはバリアントラベルの生成では無視され、そのため、値にアクセスして明示的なアクションをトリガーできなくなります。
Note that such non-existing variant mapping is different from a blocked variant, which is a variant code point mapping that exists but results in a label that may not be allocated.
このような存在しないバリアントマッピングは、ブロックされたバリアントとは異なります。ブロックされたバリアントは、存在するが割り当てられない可能性があるラベルになるバリアントコードポイントマッピングです。
If a label does not trigger any of the actions defined explicitly in the LGR, the following implicitly defined default actions are evaluated. They are shown below in their relative order of precedence (see Section 7.4). Default actions have a lower order of precedence than explicit actions (see Section 8.3).
ラベルがLGRで明示的に定義されたアクションをトリガーしない場合、暗黙的に定義された次のデフォルトアクションが評価されます。それらは、相対的な優先順位で以下に示されています（セクション7.4を参照）。デフォルトのアクションは、明示的なアクションよりも優先順位が低くなっています（セクション8.3を参照）。
The default actions for variant labels are defined as follows. The first set is triggered based on the standard variant type values of "invalid", "blocked", "allocatable", and "activated":
バリアントラベルのデフォルトアクションは次のように定義されています。最初のセットは、「バリアント」、「ブロック」、「割り当て可能」、および「アクティブ」の標準バリアントタイプの値に基づいてトリガーされます。
<action disp="invalid" any-variant="invalid"/>
<action disp="blocked" any-variant="blocked"/>
<action disp="allocatable" any-variant="allocatable"/>
<action disp="activated" all-variants="activated"/>
A final default action sets the disposition to "valid" for any label matching the repertoire for which no other action has been triggered. This "catch-all" action also matches all remaining variant labels from variants that do not have a type value.
最後のデフォルトアクションは、他のアクションがトリガーされていないレパートリーに一致するラベルの処理を「有効」に設定します。この「キャッチオール」アクションは、タイプ値を持たないバリアントの残りのすべてのバリアントラベルにも一致します。
<action disp="valid" comment="Catch-all if other rules not met"/>
Conceptually, the implicitly defined default actions act just like a block of "action" elements that is added (virtually) beyond the last of the user-supplied actions. Any label not processed by the user-supplied actions would thus be processed by the default actions as if they were present in the LGR. As the last default action is a "catch-all", all processing is guaranteed to end with a definite disposition for the label.
概念的には、暗黙的に定義されたデフォルトのアクションは、ユーザーが提供した最後のアクションを超えて（事実上）追加される「アクション」要素のブロックのように機能します。したがって、ユーザー指定のアクションによって処理されないラベルは、LGRに存在するかのようにデフォルトのアクションによって処理されます。最後のデフォルトアクションは「キャッチオール」であるため、すべての処理は、ラベルの明確な処理で終了することが保証されています。
In order to test a given label for membership in the LGR, a consumer of the LGR must iterate through each code point within a given label and test that each instance of a code point is a member of the LGR. If any instance of a code point is not a member of the LGR, the label shall be deemed invalid.
LGRのメンバーシップについて特定のラベルをテストするには、LGRのコンシューマーが特定のラベル内の各コードポイントを反復処理し、コードポイントの各インスタンスがLGRのメンバーであることをテストする必要があります。コードポイントのインスタンスがLGRのメンバーでない場合、ラベルは無効と見なされます。
An individual instance of a code point is deemed a member of the LGR when it is listed using a "char" element, or is part of a range defined with a "range" element, and all necessary conditions in any "when" or "not-when" attributes are correctly satisfied for that instance.
コードポイントの個々のインスタンスは、「char」要素を使用してリストされた場合、または「range」要素で定義された範囲の一部であり、「when」または「」で必要なすべての条件である場合、LGRのメンバーと見なされますnot-when」属性は、そのインスタンスに対して正しく満たされます。
Alternatively, an instance of a code point is also deemed a member of the LGR when it forms part of a sequence that corresponds to a sequence listed using a "char" element for which the "cp" attribute defines a sequence, and all necessary conditions in any "when" or "not-when" attributes are correctly satisfied for that instance of the sequence.
あるいは、「cp」属性がシーケンスを定義する「char」要素を使用してリストされたシーケンスに対応するシーケンスの一部を形成するコードポイントのインスタンスも、LGRのメンバーと見なされ、必要なすべての条件"when"または "not-when"属性では、シーケンスのそのインスタンスに対して正しく満たされます。
In determining eligibility, at each position the longest possible sequence of code points is evaluated first. If that sequence matches a sequence defined in the LGR and satisfies any required context at that position, the instances of its constituent code points are deemed members of the LGR and evaluation proceeds with the next code point following the sequence. If the sequence does not match a defined sequence or does not satisfy the required context, successively shorter sequences are evaluated until only a single code point remains. The eligibility of that code point is determined as described above for an individual code point instance.
適格性の判断では、各位置で、コードポイントの可能な限り長いシーケンスが最初に評価されます。そのシーケンスがLGRで定義されたシーケンスと一致し、その位置で必要なコンテキストを満たす場合、その構成コードポイントのインスタンスはLGRのメンバーと見なされ、評価はシーケンスに続く次のコードポイントから続行されます。シーケンスが定義されたシーケンスと一致しないか、必要なコンテキストを満たさない場合、単一のコードポイントのみが残るまで、連続的に短いシーケンスが評価されます。そのコードポイントの適格性は、個々のコードポイントインスタンスについて上記のように決定されます。
A label must also not trigger any action that results in a disposition of "invalid"; otherwise, it is deemed not eligible. (This step may need to be deferred until variant code point dispositions have been determined.)
ラベルは、「無効」の処理を引き起こすアクションをトリガーしてはなりません。それ以外の場合は、対象外と見なされます。 （このステップは、バリアントコードポイントの処理が決定されるまで延期する必要がある場合があります。）
For LGRs that contain reflexive variant mappings (defined in Section 5.3.4), the final evaluation of eligibility for the label must be deferred until variants are generated. In essence, LGRs that use this feature treat the original label as the (identity) variant of itself. For such LGRs, the ordinary determination of eligibility described here is but a first step that generally excludes only a subset of invalid labels.
再帰的なバリアントマッピング（5.3.4で定義）を含むLGRの場合、バリアントが生成されるまで、ラベルの適格性の最終評価を延期する必要があります。本質的に、この機能を使用するLGRは、元のラベルをそれ自体の（識別）バリアントとして扱います。そのようなLGRの場合、ここで説明する適格性の通常の決定は、無効なラベルのサブセットのみを一般に除外する最初のステップにすぎません。
To further check the validity of a label with reflexive mappings, it is not necessary to generate all variant labels. Only a single variant needs to be created, where any reflexive variants are applied for each code point, and the label disposition is evaluated (as described in Section 8.3). A disposition of "invalid" results in the label being not eligible. (In the exceptional case where context rules are present on reflexive mappings, multiple reflexive variants may be defined, but for each original label, at most one of these can be valid at each code position. However, see Section 8.4.)
再帰マッピングでラベルの有効性をさらにチェックするために、すべてのバリアントラベルを生成する必要はありません。単一のバリアントのみを作成する必要があり、再帰的バリアントが各コードポイントに適用され、ラベルの配置が評価されます（セクション8.3で説明）。 「無効」の後処理により、ラベルは適格ではなくなります。 （コンテキストルールが再帰マッピングに存在する例外的なケースでは、複数の再帰バリアントを定義できますが、元のラベルごとに、これらの最大1つが各コード位置で有効です。ただし、8.4節を参照してください。）
For a given eligible label, the set of variant labels is deemed to consist of each possible permutation of original code points and substituted code points or sequences defined in "var" elements, whereby all "when" and "not-when" attributes are correctly satisfied for each "char" or "var" element in the given permutation and all applicable whole label rules are satisfied as follows:
特定の適格なラベルについて、バリアントラベルのセットは、「var」要素で定義された元のコードポイントと置換されたコードポイントまたはシーケンスの可能な各順列で構成されると見なされ、すべての「when」属性と「not-when」属性が正しくなります。与えられた順列の各「char」または「var」要素について満たされ、適用可能なすべてのラベル全体の規則が次のように満たされます。
1. Create each possible permutation of a label by substituting each code point or code point sequence in turn by any defined variant mapping (including any reflexive mappings).
1. 各コードポイントまたはコードポイントシーケンスを、定義されたバリアントマッピング（再帰的マッピングを含む）に置き換えて、ラベルの可能な順列をそれぞれ作成します。
2. Apply variant mappings with "when" or "not-when" attributes only if the conditions are satisfied; otherwise, they are not defined.
2. 条件が満たされた場合にのみ、 "when"または "not-when"属性を持つバリアントマッピングを適用します。それ以外の場合は定義されません。
3. Record each of the "type" values on the variant mappings used in creating a given variant label in a disposition set; for any unmapped code point, record the "type" value of any reflexive variant (see Section 5.3.4).
3. 後処理セットで特定のバリアントラベルを作成する際に使用されたバリアントマッピングの各「タイプ」値を記録します。マッピングされていないコードポイントについては、再帰バリアントの「type」値を記録します（セクション5.3.4を参照）。
4. Determine the disposition for each variant label per Section 8.3.
4. セクション8.3に従って、各バリアントラベルの配置を決定します。
5. If the disposition is "invalid", remove the label from the set.
5. 後処理が「無効」の場合は、セットからラベルを削除してください。
6. If final evaluation of the disposition for the unpermuted label per Section 8.3 results in a disposition of "invalid", remove all associated variant labels from the set.
6. セクション8.3の順列を変更しないラベルの後処理を最終的に評価した結果、「無効」の後処理が行われた場合は、関連するすべてのバリアントラベルをセットから削除します。
The number of potential permutations can be very large. In practice, implementations would use suitable optimizations to avoid having to actually create all permutations (see Section 8.5).
潜在的な順列の数は非常に大きくなる可能性があります。実際には、実装は適切な最適化を使用して、実際にすべての順列を作成する必要がないようにします（セクション8.5を参照）。
In determining the permuted set of variant labels in step (1) above, all eligible partitions into sequences must be evaluated. A label "ab" that matches a sequence "ab" defined in the LGR but also matches the sequence of individual code points "a" and "b" (both defined in the LGR) must be permuted using any defined variant mappings for both the sequence "ab" and the code points "a" and "b" individually.
上記のステップ（1）で置換されたバリアントラベルのセットを決定するには、シーケンスへのすべての適格なパーティションを評価する必要があります。 LGRで定義されたシーケンス「ab」と一致するが、個々のコードポイント「a」と「b」（どちらもLGRで定義）のシーケンスとも一致するラベル「ab」は、両方の定義済みバリアントマッピングを使用して並べ替える必要があります。シーケンス「ab」とコードポイント「a」と「b」を個別に。
For a given label (variant or original), its disposition is determined by evaluating, in order of their appearance, all actions for which the label or variant label satisfies the conditions.
特定のラベル（バリアントまたはオリジナル）の場合、その配置は、ラベルまたはバリアントラベルが条件を満たしているすべてのアクションを外観の順に評価することによって決定されます。
1. For any label that contains code points or sequences not defined in the repertoire, or does not satisfy the context rules on all of its code points and variants, the disposition is "invalid".
1. レパートリーで定義されていないコードポイントまたはシーケンスを含むラベル、またはすべてのコードポイントとバリアントのコンテキストルールを満たさないラベルの場合、処理は「無効」です。
2. For all other labels, the disposition is given by the value of the "disp" attribute for the first action triggered by the label. An action is triggered if all of the following are true:
2. 他のすべてのラベルの場合、後処理は、ラベルによってトリガーされる最初のアクションの「disp」属性の値によって指定されます。次のすべてが当てはまる場合、アクションがトリガーされます。
* the label matches the whole label rule given in the "match" attribute for that action;
* ラベルは、そのアクションの「match」属性で指定されたラベルルール全体と一致します。
* the label does not match the whole label rule given in the "not-match" attribute for that action;
* ラベルは、そのアクションの「not-match」属性で指定されたラベルルール全体と一致しません。
* any of the recorded variant types for a variant label match the types given in the "any-variant" attribute for that action;
* バリアントラベルの記録されたバリアントタイプは、そのアクションの「any-variant」属性で指定されたタイプと一致します。
* all of the recorded variant types for a variant label match the types given in the "all-variants" or "only-variants" attribute given for that action;
* バリアントラベルの記録されたバリアントタイプはすべて、そのアクションに指定された「all-variants」または「only-variants」属性で指定されたタイプと一致します。
* in case of an "only-variants" attribute, the label contains only code points that are the target of applied variant mappings;
* 「バリアントのみ」属性の場合、ラベルには、適用されたバリアントマッピングのターゲットであるコードポイントのみが含まれます。
or
または
* the action does not contain any "match", "not-match", "any-variant", "all-variants", or "only-variants" attributes: catch-all.
* アクションには、「match」、「not-match」、「any-variant」、「all-variants」、「only-variants」のいずれの属性も含まれません：catch-all。
3. For any remaining variant label, assign the variant label the disposition using the default actions defined in Section 7.6. For this step, variant types outside the predefined recommended set (see Section 7.3) are ignored.
3. 残りのバリアントラベルについては、セクション7.6で定義されているデフォルトのアクションを使用して、バリアントラベルに後処理を割り当てます。このステップでは、事前定義された推奨セット（7.3項を参照）以外のバリアントタイプは無視されます。
4. For any remaining label, set the disposition to "valid".
4. 残りのラベルについては、後処理を「有効」に設定します。
For a poorly designed LGR, it is possible to generate duplicate variant labels from the same input label, but with different, and potentially conflicting, dispositions. Implementations MUST treat any duplicate variant labels encountered as an error, irrespective of their dispositions.
設計が不十分なLGRの場合、同じ入力ラベルから重複したバリアントラベルを生成することが可能ですが、処理が異なり、潜在的に競合する場合があります。実装では、その性質に関係なく、重複するバリアントラベルをエラーとして処理する必要があります。
This situation can arise in two ways. One is described in Section 5.3.5 and involves defining the same variant mapping with two context rules that are formally distinct but nevertheless overlap so that they are not mutually exclusive for the same label.
この状況は2つの方法で発生します。 1つはセクション5.3.5で説明されており、正式に異なる2つのコンテキストルールを使用して同じバリアントマッピングを定義しますが、同じラベルに対して相互に排他的ではないように重複しています。
The other case involves variants defined for sequences, where one sequence is a prefix of another (see Section 5.3.1). The following shows such an example resulting in conflicting reflexive variants:
もう1つのケースは、シーケンスに対して定義されたバリアントを含み、1つのシーケンスは別のシーケンスのプレフィックスです（セクション5.3.1を参照）。以下は、競合する再帰バリアントが発生するそのような例を示しています。
<char cp="0061">
<var cp="0061" type="allocatable"/>
</char>
<char cp="0062"/>
<char cp="0061 0062">
<var cp="0061 0062" type="blocked"/>
</char>
A label "ab" would generate the variant labels "{a}{b}" and "{ab}" where the curly braces show the sequence boundaries as they were applied during variant mapping. The result is a duplicate variant label "ab", one based on a variant of type "allocatable" plus an original code point "b" that has no variant, and another one based on a single variant of type "blocked", thus creating two variant labels with conflicting dispositions.
ラベル「ab」は、バリアントラベル「{a} {b}」と「{ab}」を生成します。波括弧は、バリアントマッピング中に適用されたシーケンスの境界を示します。結果は、重複するバリアントラベル「ab」です。1つは「割り当て可能」タイプのバリアントに加えて、バリアントのない元のコードポイント「b」に基づいており、もう1つは「ブロック」タイプの1つのバリアントに基づいているため、作成されます。処理が競合する2つのバリアントラベル。
In the general case, it is difficult to impossible to prove by mechanical inspection of the LGR that duplicate variant labels will never occur, so implementations have to be prepared to detect this error during variant label generation. The condition is easily avoided by careful design of context rules and special attention to the relation among code point sequences with variants.
一般的なケースでは、重複するバリアントラベルが決して発生しないことをLGRの機械的検査で証明することは困難から不可能であるため、バリアントラベルの生成中にこのエラーを検出するための実装を準備する必要があります。この条件は、コンテキストルールを注意深く設計し、コードポイントシーケンスとバリアントの関係に特別な注意を払うことで簡単に回避できます。
The obvious method for checking for collision between labels is to generate the fully permuted set of variants for one of them and see whether it contains the other label as a member. As discussed above, this can be prohibitive and is not necessary.
ラベル間の衝突をチェックする明白な方法は、そのうちの1つのバリアントの完全に置換されたセットを生成し、メンバーとして他のラベルが含まれているかどうかを確認することです。上述のように、これは法外なものになる可能性があり、必要ではありません。
Because of symmetry and transitivity, all variant mappings form disjoint sets. In each of these sets, the source and target of each mapping are also variants of the sources and targets of all the other mappings. However, members of two different sets are never variants of each other.
対称性と推移性のため、すべてのバリアントマッピングは互いに素なセットを形成します。これらの各セットでは、各マッピングのソースとターゲットも、他のすべてのマッピングのソースとターゲットのバリアントです。ただし、2つの異なるセットのメンバーがお互いのバリアントになることはありません。
If two labels have code points at the same position that are members of two different variant mapping sets, any variant labels of one cannot be variant labels of the other: the sets of their variant labels are likewise disjoint. Instead of generating all permutations to compare all possible variants, it is enough to find out whether code points at the same position belong to the same variant set or not.
2つのラベルのコードポイントが同じ位置にあり、2つの異なるバリアントマッピングセットのメンバーである場合、一方のバリアントラベルを他方のバリアントラベルにすることはできません。バリアントラベルのセットも同様に互いに素です。可能なすべてのバリアントを比較するためにすべての順列を生成する代わりに、同じ位置にあるコードポイントが同じバリアントセットに属しているかどうかを調べるだけで十分です。
For that, it is sufficient to substitute an "index" mapping that identifies the set. This index mapping could be, for example, the variant mapping for which the target code point (or sequence) comes first in some sorting order. This index mapping would, in effect, identify the set of variant mappings for that position.
そのためには、セットを識別する「インデックス」マッピングを置き換えるだけで十分です。このインデックスマッピングは、たとえば、ターゲットコードポイント（またはシーケンス）があるソート順で最初に来るバリアントマッピングにすることができます。このインデックスマッピングは、実際には、その位置のバリアントマッピングのセットを識別します。
To check for collision then means generating a single variant label from the original by substituting the respective "index" value for each code point. This results in an "index label". Two labels collide whenever the index labels for them are the same.
衝突をチェックすることは、各コードポイントにそれぞれの「インデックス」値を代入することにより、元のラベルから単一のバリアントラベルを生成することを意味します。これにより、「インデックスラベル」が作成されます。 2つのラベルは、それらのインデックスラベルが同じである場合は常に衝突します。
Both [RFC3743] and [RFC4290] provide different grammars for IDN tables. The formats in those documents are unable to fully support the increased requirements of contemporary IDN variant policies.
[RFC3743]と[RFC4290]はどちらもIDNテーブルに異なる文法を提供します。これらのドキュメントの形式は、現代のIDNバリアントポリシーの増加する要件を完全にサポートできません。
This specification is a superset of functionality provided by the older IDN table formats; thus, any table expressed in those formats can be expressed in this new format. Automated conversion can be conducted between tables conformant with the grammar specified in each document.
この仕様は、以前のIDNテーブル形式で提供されていた機能のスーパーセットです。したがって、これらの形式で表現されたテーブルは、この新しい形式で表現できます。各ドキュメントで指定された文法に準拠したテーブル間で自動変換を実行できます。
For notes on how to translate a table in the style of RFC 3743, see Appendix B.
RFC 3743のスタイルでテーブルを変換する方法については、付録Bを参照してください。
Well-formed LGRs that comply with this specification SHOULD be transmitted with a media type of "application/lgr+xml". This media type will signal to an LGR-aware client that the content is designed to be interpreted as an LGR.
この仕様に準拠した整形式のLGRは、「application / lgr + xml」のメディアタイプで送信する必要があります（SHOULD）。このメディアタイプは、コンテンツがLGRとして解釈されるように設計されていることをLGR対応クライアントに通知します。
IANA has completed the following actions:
IANAは次のアクションを完了しました：
The media type "application/lgr+xml" has been registered to denote transmission of LGRs that are compliant with this specification, in accordance with [RFC6838].
メディアタイプ「application / lgr + xml」は、[RFC6838]に従って、この仕様に準拠するLGRの送信を示すために登録されています。
Type name: application
タイプ名：アプリケーション
Subtype name: lgr+xml
サブタイプ名：lgr + xml
Required parameters: N/A
必須パラメーター：なし
Optional parameters: charset (as for application/xml per [RFC7303])
オプションパラメータ：charset（[RFC7303]のapplication / xmlと同様）
Security considerations: See the security considerations for application/xml in [RFC7303] and the specific security considerations for Label Generation Rulesets (LGRs) in RFC 7940
セキュリティの考慮事項：[RFC7303]のapplication / xmlのセキュリティの考慮事項と、RFC 7940のラベル生成ルールセット（LGR）の特定のセキュリティの考慮事項を参照してください
Interoperability considerations: As for application/xml per [RFC7303]
相互運用性に関する考慮事項：application / xmlについて[RFC7303]
Published specification: See RFC 7940
公開された仕様：RFC 7940を参照
Applications that use this media type: Software using LGRs for international identifiers, such as IDNs, including registry applications and client validators.
このメディアタイプを使用するアプリケーション：レジストリアプリケーションやクライアントバリデーターなど、IDNなどの国際識別子にLGRを使用するソフトウェア。
Additional information:
追加情報：
Deprecated alias names for this type: N/A
このタイプの非推奨のエイリアス名：N / A
Magic number(s): N/A
File extension(s): .lgr
ファイル拡張子：.lgr
Macintosh file type code(s): N/A
Person & email address to contact for further information:
詳細について連絡する人とメールアドレス：
Kim Davies <kim.davies@icann.org>
Asmus Freytag <asmus@unicode.org>
Intended usage: COMMON Restrictions on usage: N/A
使用目的：一般的な使用制限：なし
Author:
著者：
Kim Davies <kim.davies@icann.org>
Asmus Freytag <asmus@unicode.org>
Change controller: IESG
コントローラーの変更：IESG
Provisional registration? (standards tree only): No
仮登録？ （標準ツリーのみ）：いいえ
This specification uses a URN to describe the XML namespace, in accordance with [RFC3688].
この仕様では、[RFC3688]に従って、URNを使用してXML名前空間を記述しています。
URI: urn:ietf:params:xml:ns:lgr-1.0
Registrant Contact: See the Authors of this document.
登録者の連絡先：このドキュメントの作成者を参照してください。
XML: None.
XML：なし。
This document establishes a vocabulary of "Label Generation Ruleset Dispositions", which has been reflected as a new IANA registry. This registry is divided into two subregistries:
このドキュメントは、新しいIANAレジストリとして反映されている「Label Generation Ruleset Dispositions」の語彙を確立します。このレジストリは2つのサブレジストリに分かれています。
o Standard Dispositions - This registry lists dispositions that have been defined in published specifications, i.e., the eligibility for such registrations is "Specification Required" [RFC5226]. The initial set of registrations are the five dispositions in this document described in Section 7.3.
o 標準処理-このレジストリには、公開された仕様で定義された処理がリストされています。つまり、そのような登録の資格は「必要な仕様」[RFC5226]です。登録の最初のセットは、セクション7.3で説明されているこのドキュメントの5つの性質です。
o Private Dispositions - This registry lists dispositions that have been registered "First Come First Served" [RFC5226] by third parties with the IANA. Such dispositions must take the form "entity:disposition" where the entity is a domain name that uniquely identifies the private user of the namespace. For example, "example.org:reserved" could be a private extension used by the example organization to denote a disposition relating to reserved labels. These extensions are not intended to be interoperable, but registration is designed to minimize potential conflicts. It is strongly recommended that any new dispositions that require interoperability and have applicability beyond a single organization be defined as Standard Dispositions.
o Private Dispositions-このレジストリには、IANAのサードパーティによって「先着順」[RFC5226]で登録された後処理が一覧表示されます。このような処理は、「entity：disposition」の形式を取る必要があります。エンティティは、名前空間のプライベートユーザーを一意に識別するドメイン名です。たとえば、「example.org:reserved」は、予約済みラベルに関連する後処理を示すためにサンプル組織が使用するプライベート拡張である可能性があります。これらの拡張機能は相互運用性を意図したものではありませんが、登録は潜在的な競合を最小限に抑えるように設計されています。相互運用性を必要とし、単一の組織を超えて適用できる新しい性質は、標準性質として定義することを強くお勧めします。
In order to distinguish them from Private Dispositions, Standard Dispositions MUST NOT contain the ":" character. All disposition names shall be in lowercase ASCII.
それらをプライベート処理と区別するために、標準処理には「：」文字を含めてはなりません。すべての後処理名は小文字のASCIIにする必要があります。
The IANA registry provides data on the name of the disposition, the intended purposes, and the registrant or defining specification for the disposition.
IANAレジストリは、処理の名前、使用目的、および処理の登録者または定義仕様に関するデータを提供します。
Substantially unrestricted use of non-ASCII characters in security-relevant identifiers such as domain name labels may cause user confusion and invite various types of attacks. In many languages, in particular those using complex or large scripts, an attacker has an opportunity to divert or confuse users as a result of different code points with identical appearance or similar semantics.
ドメイン名ラベルなどのセキュリティ関連の識別子での非ASCII文字の実質的に無制限の使用は、ユーザーを混乱させ、さまざまなタイプの攻撃を招く可能性があります。多くの言語、特に複雑なスクリプトや大きなスクリプトを使用する言語では、攻撃者は、同一の外観または類似したセマンティクスを持つ異なるコードポイントの結果として、ユーザーをそらすか混乱させる機会があります。
The use of an LGR provides a partial remedy for these risks by supplying a framework for prohibiting inappropriate code points or sequences from being registered at all and for permitting "variant" code points to be grouped together so that labels containing them may be mutually exclusive or registered only to the same owner.
LGRの使用は、不適切なコードポイントまたはシーケンスがまったく登録されないようにするフレームワークを提供し、「バリアント」コードポイントをグループ化してそれらを含むラベルが相互に排他的または同じ所有者にのみ登録されています。
In addition, by being fully machine processable the format may enable automated checks for known weaknesses in label generation rules. However, the use of this format, or compliance with this specification, by itself does not ensure that the LGRs expressed in this format are free of risk. Additional approaches may be considered, depending on the acceptable trade-off between flexibility and risk for a given application. One method of managing risk may involve a case-by-case evaluation of a proposed label in context with already-registered labels -- for example, when reviewing labels for their degree of visual confusability.
さらに、完全に機械処理可能であることにより、このフォーマットは、ラベル生成ルールの既知の弱点の自動チェックを可能にする場合があります。ただし、この形式の使用、またはこの仕様への準拠だけでは、この形式で表現されたLGRにリスクがないことは保証されません。特定のアプリケーションの柔軟性とリスクの間の許容できるトレードオフに応じて、追加のアプローチが検討される場合があります。リスクを管理する1つの方法には、たとえば、ラベルの視覚的な混乱の程度を確認する場合など、既に登録されているラベルとの関連で、提案されたラベルをケースバイケースで評価することが含まれます。
A naive implementation attempting to generate all variant labels for a given label could lead to the possibility of exhausting the resources on the machine running the LGR processor, potentially causing denial-of-service consequences. For many operations, brute-force generation can be avoided by optimization, and if needed, the number of permuted labels can be estimated more cheaply ahead of time.
特定のラベルのすべてのバリアントラベルを生成しようとする単純な実装は、LGRプロセッサを実行しているマシンのリソースを使い果たし、サービス拒否の結果を引き起こす可能性があります。多くの操作では、最適化によってブルートフォースの生成を回避できます。必要に応じて、並べ替えられたラベルの数を事前に安く見積もることができます。
The implementation of WLE rules, using certain backtracking algorithms, can take exponential time for pathological rules or labels and exhaust stack resources. This can be mitigated by proper implementation and enforcing the restrictions on permissible label length.
特定のバックトラッキングアルゴリズムを使用したWLEルールの実装では、病理学的ルールまたはラベルに指数関数的な時間がかかり、スタックリソースを使い果たす可能性があります。これは、適切な実装と許容ラベル長の制限を適用することで軽減できます。
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, <http://www.rfc-editor.org/info/rfc2045>.
[RFC2045] Freed、N。およびN. Borenstein、「Multipurpose Internet Mail Extensions（MIME）Part One：Format of Internet Message Bodies」、RFC 2045、DOI 10.17487 / RFC2045、1996年11月、<http：//www.rfc- editor.org/info/rfc2045>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, <http://www.rfc-editor.org/info/rfc3339>.
[RFC3339] Klyne、G。およびC. Newman、「インターネット上の日付と時刻：タイムスタンプ」、RFC 3339、DOI 10.17487 / RFC3339、2002年7月、<http://www.rfc-editor.org/info/rfc3339 >。
[RFC5646] Phillips, A., Ed., and M. Davis, Ed., "Tags for Identifying Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, September 2009, <http://www.rfc-editor.org/info/rfc5646>.
[RFC5646] Phillips、A.、Ed。、and M. Davis、Ed。、 "Tags for Identificationing Languages"、BCP 47、RFC 5646、DOI 10.17487 / RFC5646、September 2009、<http：//www.rfc-editor .org / info / rfc5646>。
[UAX42] The Unicode Consortium, "Unicode Character Database in XML", May 2016, <http://unicode.org/reports/tr42/>.
[UAX42] Unicodeコンソーシアム、「XMLのUnicode文字データベース」、2016年5月、<http://unicode.org/reports/tr42/>。
[Unicode-Stability] The Unicode Consortium, "Unicode Encoding Stability Policy, Property Value Stability", April 2015, <http://www.unicode.org/policies/ stability_policy.html#Property_Value>.
[Unicode-Stability] Unicodeコンソーシアム、「Unicode Encoding Stability Policy、Property Value Stability」、2015年4月、<http://www.unicode.org/policies/static_policy.html#Property_Value>。
[Unicode-Versions] The Unicode Consortium, "Unicode Version Numbering", June 2016, <http://unicode.org/versions/#Version_Numbering>.
[Unicode-Versions] Unicodeコンソーシアム、「Unicode Version Numbering」、2016年6月、<http://unicode.org/versions/#Version_Numbering>。
[XML] Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth Edition)", World Wide Web Consortium, November 2008, <http://www.w3.org/TR/REC-xml/>.
[XML] Bray、T.、Paoli、J.、Sperberg-McQueen、M.、Maler、E。、およびF. Yergeau、「Extensible Markup Language（XML）1.0（Fifth Edition）」、World Wide Web Consortium、11月2008、<http://www.w3.org/TR/REC-xml/>。
[ASIA-TABLE] DotAsia Organisation, ".ASIA ZH IDN Language Table", February 2012, <http://www.dot.asia/policies/ASIA-ZH-1.2.pdf>.
[ASIA-TABLE] DotAsia Organisation、「。ASIA ZH IDN Language Table」、2012年2月、<http://www.dot.asia/policies/ASIA-ZH-1.2.pdf>。
[LGR-PROCEDURE] Internet Corporation for Assigned Names and Numbers, "Procedure to Develop and Maintain the Label Generation Rules for the Root Zone in Respect of IDNA Labels", December 2012, <http://www.icann.org/en/resources/idn/ draft-lgr-procedure-07dec12-en.pdf>.
[LGR-PROCEDURE]割り当てられた名前と番号に関するInternet Corporation、「IDNAラベルに関するルートゾーンのラベル生成ルールを作成および維持するための手順」、2012年12月、<http://www.icann.org/en/ resources / idn / draft-lgr-procedure-07dec12-en.pdf>。
[RELAX-NG] The Organization for the Advancement of Structured Information Standards (OASIS), "RELAX NG Compact Syntax", November 2002, <https://www.oasis-open.org/committees/ relax-ng/compact-20021121.html>.
[RELAX-NG] The Organization for the Advancement of Structured Information Standards（OASIS）、 "RELAX NG Compact Syntax"、November 2002、<https://www.oasis-open.org/committees/ relax-ng / compact-20021121 .html>。
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, <http://www.rfc-editor.org/info/rfc3688>.
[RFC3688] Mealling、M。、「The IETF XML Registry」、BCP 81、RFC 3688、DOI 10.17487 / RFC3688、2004年1月、<http://www.rfc-editor.org/info/rfc3688>。
[RFC3743] Konishi, K., Huang, K., Qian, H., and Y. Ko, "Joint Engineering Team (JET) Guidelines for Internationalized Domain Names (IDN) Registration and Administration for Chinese, Japanese, and Korean", RFC 3743, DOI 10.17487/RFC3743, April 2004, <http://www.rfc-editor.org/info/rfc3743>.
[RFC3743]コニシK.、ファンK.、キアンH.、Y。コ、「中国語、日本語、韓国語向けの国際化ドメイン名（IDN）登録および管理に関する共同エンジニアリングチーム（JET）ガイドライン」、 RFC 3743、DOI 10.17487 / RFC3743、2004年4月、<http://www.rfc-editor.org/info/rfc3743>。
[RFC4290] Klensin, J., "Suggested Practices for Registration of Internationalized Domain Names (IDN)", RFC 4290, DOI 10.17487/RFC4290, December 2005, <http://www.rfc-editor.org/info/rfc4290>.
[RFC4290] Klensin、J。、「国際化ドメイン名（IDN）の登録のための推奨プラクティス」、RFC 4290、DOI 10.17487 / RFC4290、2005年12月、<http://www.rfc-editor.org/info/rfc4290> 。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、DOI 10.17487 / RFC5226、2008年5月、<http://www.rfc-editor.org / info / rfc5226>。
[RFC5564] El-Sherbiny, A., Farah, M., Oueichek, I., and A. Al-Zoman, "Linguistic Guidelines for the Use of the Arabic Language in Internet Domains", RFC 5564, DOI 10.17487/RFC5564, February 2010, <http://www.rfc-editor.org/info/rfc5564>.
[RFC5564] El-Sherbiny、A.、Farah、M.、Oueichek、I。、およびA. Al-Zoman、「インターネットドメインでアラビア語を使用するための言語ガイドライン」、RFC 5564、DOI 10.17487 / RFC5564、 2010年2月、<http://www.rfc-editor.org/info/rfc5564>。
[RFC5891] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, DOI 10.17487/RFC5891, August 2010, <http://www.rfc-editor.org/info/rfc5891>.
[RFC5891] Klensin、J。、「Internationalized Domain Names in Applications（IDNA）：Protocol」、RFC 5891、DOI 10.17487 / RFC5891、2010年8月、<http://www.rfc-editor.org/info/rfc5891>。
[RFC5892] Faltstrom, P., Ed., "The Unicode Code Points and Internationalized Domain Names for Applications (IDNA)", RFC 5892, DOI 10.17487/RFC5892, August 2010, <http://www.rfc-editor.org/info/rfc5892>.
[RFC5892] Faltstrom、P。、編、「アプリケーションのUnicodeコードポイントと国際化ドメイン名（IDNA）」、RFC 5892、DOI 10.17487 / RFC5892、2010年8月、<http://www.rfc-editor.org / info / rfc5892>。
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, <http://www.rfc-editor.org/info/rfc6838>.
[RFC6838] Freed、N.、Klensin、J。、およびT. Hansen、「Media Type Specifications and Registration Procedures」、BCP 13、RFC 6838、DOI 10.17487 / RFC6838、2013年1月、<http：//www.rfc- editor.org/info/rfc6838>。
[RFC7303] Thompson, H. and C. Lilley, "XML Media Types", RFC 7303, DOI 10.17487/RFC7303, July 2014, <http://www.rfc-editor.org/info/rfc7303>.
[RFC7303] Thompson、H。およびC. Lilley、「XML Media Types」、RFC 7303、DOI 10.17487 / RFC7303、2014年7月、<http://www.rfc-editor.org/info/rfc7303>。
[TDIL-HINDI] Technology Development for Indian Languages (TDIL) Programme, "Devanagari Script Behaviour for Hindi Ver2.0", <http://tdil-dc.in/index.php?option=com_download&task=show resourceDetails&toolid=1625&lang=en>.
[TDIL-HINDI]インド言語の技術開発（TDIL）プログラム、「ヒンディー語Ver2.0のデバナガリスクリプトの動作」、<http://tdil-dc.in/index.php?option=com_download&task=show resourceDetails＆toolid = 1625＆lang = en>。
[UAX44] The Unicode Consortium, "Unicode Character Database", June 2016, <http://unicode.org/reports/tr44/>.
[UAX44] Unicodeコンソーシアム、「Unicode Character Database」、2016年6月、<http://unicode.org/reports/tr44/>。
[WLE-RULES] Internet Corporation for Assigned Names and Numbers, "Whole Label Evaluation (WLE) Rules", August 2016, <https://community.icann.org/download/ attachments/43989034/WLE-Rules.pdf>.
[WLE-RULES] Internet Corporation for Assigned Names and Numbers、 "Whole Label Evaluation（WLE）Rules"、2016年8月、<https://community.icann.org/download/ attachments / 43989034 / WLE-Rules.pdf>。
The following presents a minimal LGR table defining the lowercase LDH (letters, digits, hyphen) repertoire and containing no rules or metadata elements. Many simple LGR tables will look quite similar, except that they would contain some metadata.
以下は、小文字のLDH（文字、数字、ハイフン）レパートリーを定義し、ルールやメタデータ要素を含まない最小のLGRテーブルを示しています。単純なLGRテーブルの多くは、メタデータが含まれていることを除いて、非常によく似ています。
<?xml version="1.0" encoding="utf-8"?>
<lgr xmlns="urn:ietf:params:xml:ns:lgr-1.0">
<data>
<char cp="002D" comment="HYPHEN (-)" />
<range first-cp="0030" last-cp="0039"
comment="DIGIT ZERO - DIGIT NINE" />
<range first-cp="0061" last-cp="007A"
comment="LATIN SMALL LETTER A - LATIN SMALL LETTER Z" />
</data>
</lgr>
In practice, any LGR that includes the hyphen might also contain rules invalidating any labels beginning with a hyphen, ending with a hyphen, and containing consecutive hyphens in the third and fourth positions as required by [RFC5891].
実際には、ハイフンを含むすべてのLGRには、ハイフンで始まりハイフンで終わり、[RFC5891]で要求される3番目と4番目の位置に連続するハイフンを含むラベルを無効にするルールも含まれる場合があります。
<?xml version="1.0" encoding="utf-8"?>
<lgr xmlns="urn:ietf:params:xml:ns:lgr-1.0">
<data>
<char cp="002D"
not-when="hyphen-minus-disallowed" />
<range first-cp="0030" last-cp="0039" />
<range first-cp="0061" last-cp="007A" />
</data>
<rules>
<rule name="hyphen-minus-disallowed"
comment="RFC5891 restrictions on U+002D">
<choice>
<rule comment="no leading hyphen">
<look-behind>
<start />
</look-behind>
<anchor />
</rule>
<rule comment="no trailing hyphen">
<anchor />
<look-ahead>
<end />
</look-ahead>
</rule>
<rule comment="no consecutive hyphens
in third and fourth positions">
<look-behind>
<start />
<any />
<any />
<char cp="002D" comment="hyphen-minus" />
</look-behind>
<anchor />
</rule>
</choice>
</rule>
</rules>
</lgr>
The following sample LGR shows a more complete collection of the elements and attributes defined in this specification in a somewhat typical context.
次のサンプルLGRは、やや典型的なコンテキストで、この仕様で定義されている要素と属性のより完全なコレクションを示しています。
<?xml version="1.0" encoding="utf-8"?>
<!-- This example uses a large subset of the features of this specification. It does not include every set operator, match operator element, or action trigger attribute, their use being largely parallel to the ones demonstrated. -->
<！-この例では、この仕様の機能の大きなサブセットを使用しています。すべてのセット演算子、一致演算子要素、またはアクショントリガー属性が含まれているわけではありません。これらの使用は、示されているものとほぼ同じです。 ->
<lgr xmlns="urn:ietf:params:xml:ns:lgr-1.0">
<!-- meta element with all optional elements -->
<meta>
<version comment="initial version">1</version>
<date>2010-01-01</date>
<language>sv</language>
<scope type="domain">example.com</scope>
<validity-start>2010-01-01</validity-start>
<validity-end>2013-12-31</validity-end>
<description type="text/html">
<![CDATA[
This language table was developed with the
<a href="http://swedish.example/">Swedish
examples institute</a>.
]]>
</description>
<unicode-version>6.3.0</unicode-version>
<references>
<reference id="0" comment="the most recent" >The
Unicode Standard 9.0</reference>
<reference id="1" >RFC 5892</reference>
<reference id="2" >Big-5: Computer Chinese Glyph
and Character Code Mapping Table, Technical Report
C-26, 1984</reference>
</references>
</meta>
<!-- the "data" section describing the repertoire -->
<data>
<!-- single code point "char" element -->
<char cp="002D" ref="1" comment="HYPHEN" />
<!-- "range" elements for contiguous code points, with tags -->
<range first-cp="0030" last-cp="0039" ref="1" tag="digit" />
<range first-cp="0061" last-cp="007A" ref ="1" tag="letter" />
<!-- code point sequence -->
<char cp="006C 00B7 006C" comment="Catalan middle dot" />
<!-- alternatively, use a When Rule -->
<char cp="00B7" when="catalan-middle-dot" />
<!-- code point with context rule -->
<char cp="200D" when="joiner" ref="2" />
<!-- code points with variants -->
<char cp="4E16" tag="preferred" ref="0">
<var cp="4E17" type="blocked" ref="2" />
<var cp="534B" type="allocatable" ref="2" />
</char>
<char cp="4E17" ref="0">
<var cp="4E16" type="allocatable" ref="2" />
<var cp="534B" type="allocatable" ref="2" />
</char>
<char cp="534B" ref="0">
<var cp="4E16" type="allocatable" ref="2" />
<var cp="4E17" type="blocked" ref="2" />
</char>
</data>
<!-- Context and whole label rules -->
<rules>
<!-- Require the given code point to be between two 006C
code points -->
<rule name="catalan-middle-dot" ref="0">
<look-behind>
<char cp="006C" />
</look-behind>
<anchor />
<look-ahead>
<char cp="006C" />
</look-ahead>
</rule>
<!-- example of a context rule based on property -->
<class name="virama" property="ccc:9" />
<rule name="joiner" ref="1" >
<look-behind>
<class by-ref="virama" />
</look-behind>
<anchor />
</rule>
<!-- example of using set operators -->
<!-- Subtract vowels from letters to get
consonant, demonstrating the different
set notations and the difference operator -->
<difference name="consonants">
<class comment="all letters">0061-007A</class>
<class comment="all vowels">
0061 0065 0069 006F 0075
</class>
</difference>
<!-- by using the start and end, rule matches whole label -->
<rule name="three-or-more-consonants">
<start />
<!-- reference the class defined by the difference,
and require three or more matches -->
<class by-ref="consonants" count="3+" />
<end />
</rule>
<!-- rule for negative matching -->
<rule name="non-preferred"
comment="matches any non-preferred code point">
<complement comment="non-preferred" >
<class from-tag="preferred" />
</complement>
</rule>
<!-- actions triggered by matching rules and/or
variant types -->
<action disp="invalid"
match="three-or-more-consonants" />
<action disp="blocked" any-variant="blocked" />
<action disp="allocatable" all-variants="allocatable"
not-match="non-preferred" />
</rules>
</lgr>
Appendix B. How to Translate Tables Based on RFC 3743 into the XML Format
付録B. RFC 3743に基づくテーブルをXML形式に変換する方法
As background, the rules specified in [RFC3743] work as follows:
背景として、[RFC3743]で指定されているルールは次のように機能します。
1. The original (requested) label is checked to make sure that all the code points are a subset of the repertoire.
1. 元の（要求された）ラベルは、すべてのコードポイントがレパートリーのサブセットであることを確認するためにチェックされます。
2. If it passes the check, the original label is allocatable.
2. チェックに合格した場合、元のラベルは割り当て可能です。
3. Generate the all-simplified and all-traditional variant labels (union of all the labels generated using all the simplified variants of the code points) for allocation.
3. 割り当て用に、すべて簡略化されたすべての従来のバリアントラベル（コードポイントのすべての簡略化されたバリアントを使用して生成されたすべてのラベルの結合）を生成します。
To illustrate by example, here is one of the more complicated set of variants:
例を挙げて説明すると、以下はより複雑なバリアントセットの1つです。
U+4E7E U+4E81 U+5E72 U+5E79 U+69A6 U+6F27
U + 4E7E U + 4E81 U + 5E72 U + 5E79 U + 69A6 U + 6F27
The following shows the relevant section of the Chinese language table published by the .ASIA registry [ASIA-TABLE]. Its entries read:
以下は、.ASIAレジストリ[ASIA-TABLE]によって公開された中国語テーブルの関連セクションを示しています。そのエントリは次のとおりです。
<codepoint>;<simpl-variant(s)>;<trad-variant(s)>;<other-variant(s)>
These are the lines corresponding to the set of variants listed above:
これらは、上記のバリアントのセットに対応する行です。
U+4E7E;U+4E7E,U+5E72;U+4E7E;U+4E81,U+5E72,U+6F27,U+5E79,U+69A6 U+4E81;U+5E72;U+4E7E;U+5E72,U+6F27,U+5E79,U+69A6 U+5E72;U+5E72;U+5E72,U+4E7E,U+5E79;U+4E7E,U+4E81,U+69A6,U+6F27 U+5E79;U+5E72;U+5E79;U+69A6,U+4E7E,U+4E81,U+6F27 U+69A6;U+5E72;U+69A6;U+5E79,U+4E7E,U+4E81,U+6F27 U+6F27;U+4E7E;U+6F27;U+4E81,U+5E72,U+5E79,U+69A6 The corresponding "data" section XML format would look like this:
U + 4E7E; U + 4E7E、U + 5E72; U + 4E7E; U + 4E81、U + 5E72、U + 6F27、U + 5E79、U + 69A6 U + 4E81; U + 5E72; U + 4E7E; U + 5E72 、U + 6F27、U + 5E79、U + 69A6 U + 5E72; U + 5E72; U + 5E72、U + 4E7E、U + 5E79、U + 4E7E、U + 4E81、U + 69A6、U + 6F27 U + 5E79 ; U + 5E72; U + 5E79; U + 69A6、U + 4E7E、U + 4E81、U + 6F27 U + 69A6; U + 5E72; U + 69A6; U + 5E79、U + 4E7E、U + 4E81、U + 6F27 U + 6F27; U + 4E7E; U + 6F27; U + 4E81、U + 5E72、U + 5E79、U + 69A6対応する「データ」セクションのXML形式は次のようになります。
<data>
<char cp="4E7E">
<var cp="4E7E" type="both" comment="identity" />
<var cp="4E81" type="blocked" />
<var cp="5E72" type="simp" />
<var cp="5E79" type="blocked" />
<var cp="69A6" type="blocked" />
<var cp="6F27" type="blocked" />
</char>
<char cp="4E81">
<var cp="4E7E" type="trad" />
<var cp="5E72" type="simp" />
<var cp="5E79" type="blocked" />
<var cp="69A6" type="blocked" />
<var cp="6F27" type="blocked" />
</char>
<char cp="5E72">
<var cp="4E7E" type="trad"/>
<var cp="4E81" type="blocked"/>
<var cp="5E72" type="both" comment="identity"/>
<var cp="5E79" type="trad"/>
<var cp="69A6" type="blocked"/>
<var cp="6F27" type="blocked"/>
</char>
<char cp="5E79">
<var cp="4E7E" type="blocked"/>
<var cp="4E81" type="blocked"/>
<var cp="5E72" type="simp"/>
<var cp="5E79" type="trad" comment="identity"/>
<var cp="69A6" type="blocked"/>
<var cp="6F27" type="blocked"/>
</char>
<char cp="69A6">
<var cp="4E7E" type="blocked"/>
<var cp="4E81" type="blocked"/>
<var cp="5E72" type="simp"/>
<var cp="5E79" type="blocked"/>
<var cp="69A6" type="trad" comment="identity"/>
<var cp="6F27" type="blocked"/>
</char>
<char cp="6F27">
<var cp="4E7E" type="simp"/>
<var cp="4E81" type="blocked"/>
<var cp="5E72" type="blocked"/>
<var cp="5E79" type="blocked"/>
<var cp="69A6" type="blocked"/>
<var cp="6F27" type="trad" comment="identity"/>
</char>
</data>
Here, the simplified variants have been given a type of "simp" and the traditional variants one of "trad", and all other ones are given "blocked".
ここでは、単純化されたバリアントには「単純」のタイプが与えられ、従来のバリアントには「トラッド」のタイプが与えられ、他のすべてのバリアントには「ブロック」が与えられます。
Because some variant mappings show in more than one column, while the XML format allows only a single type value, they have been given the type of "both".
一部のバリアントマッピングは複数の列に表示されるため、XML形式では単一の型の値しか許可されませんが、それらには「両方」の型が与えられています。
Note that some variant mappings map to themselves (identity); that is, the mapping is reflexive (see Section 5.3.4). In creating the permutation of all variant labels, these mappings have no effect, other than adding a value to the variant type list for the variant label containing them.
一部のバリアントマッピングは、それ自体（ID）にマップすることに注意してください。つまり、マッピングは再帰的です（セクション5.3.4を参照）。すべてのバリアントラベルの順列を作成する場合、これらのマッピングは、それらを含むバリアントラベルのバリアントタイプリストに値を追加する以外は効果がありません。
In the example so far, all of the entries with type="both" are also mappings where source and target are identical. That is, they are reflexive mappings as defined in Section 5.3.4.
これまでの例では、type = "both"のすべてのエントリも、ソースとターゲットが同じであるマッピングです。つまり、セクション5.3.4で定義されているように再帰的なマッピングです。
Given a label "U+4E7E U+4E81", the following labels would be ruled allocatable per [RFC3743], based on how that standard is commonly implemented in domain registries:
ラベル「U + 4E7E U + 4E81」が与えられた場合、次のラベルは、その標準がドメインレジストリで一般的にどのように実装されているかに基づいて、[RFC3743]に従って割り当て可能であると判断されます。
Original label: U+4E7E U+4E81
Simplified label 1: U+4E7E U+5E72
Simplified label 2: U+5E72 U+5E72
Traditional label: U+4E7E U+4E7E
However, if allocatable labels were generated simply by a straight permutation of all variants with type other than type="blocked" and without regard to the simplified and traditional variants, we would end up with an extra allocatable label of "U+5E72 U+4E7E". This label is composed of both a Simplified Chinese character and a Traditional Chinese code point and therefore shouldn't be allocatable.
ただし、割り当て可能なラベルがtype = "blocked"以外のタイプのすべてのバリアントの単純な順列によって生成され、単純化された従来のバリアントに関係なく生成された場合、 "U + 5E72 U +"の割り当て可能なラベルが追加されます。 4E7E」。このラベルは、簡体字中国語文字と繁体字中国語コードポイントの両方で構成されているため、割り当てることはできません。
To more fully resolve the dispositions requires several actions to be defined, as described in Section 7.2.2, that will override the default actions from Section 7.6. After blocking all labels that contain a variant with type "blocked", these actions will set to "allocatable" labels based on the following variant types: "simp", "trad", and "both". Note that these variant types do not directly relate to dispositions for the variant label, but that the actions will resolve them to the Standard Dispositions on labels, i.e., "blocked" and "allocatable".
配置をより完全に解決するには、セクション7.2.2で説明されているように、セクション7.6のデフォルトアクションをオーバーライドするいくつかのアクションを定義する必要があります。タイプ「blocked」のバリアントを含むすべてのラベルをブロックした後、これらのアクションは、「simp」、「trad」、および「both」のバリアントタイプに基づいて「割り当て可能な」ラベルに設定されます。これらのバリアントタイプはバリアントラベルの後処理に直接関係していませんが、アクションはそれらをラベルの標準的な後処理、つまり「ブロック」および「割り当て可能」に解決します。
To resolve label dispositions requires five actions to be defined (in the "rules" section of the XML document in question); these actions apply in order, and the first one triggered defines the disposition for the label. The actions are as follows:
ラベルの配置を解決するには、5つのアクションを定義する必要があります（問題のXMLドキュメントの「ルール」セクションで）。これらのアクションは順番に適用され、トリガーされた最初のアクションがラベルの後処理を定義します。アクションは次のとおりです。
1. Block all variant labels containing at least one blocked variant.
1. 少なくとも1つのブロックされたバリアントを含むすべてのバリアントラベルをブロックします。
2. Allocate all labels that consist entirely of variants that are "simp" or "both".
2. 「simp」または「both」のバリアントのみで構成されるすべてのラベルを割り当てます。
3. Also allocate all labels that are entirely "trad" or "both".
3. また、完全に「trad」または「both」であるすべてのラベルを割り当てます。
4. Block all surviving labels containing any one of the dispositions "simp" or "trad" or "both", because they are now known to be part of an undesirable mixed simplified/traditional label.
4. 「simp」、「trad」、または「both」のいずれかの処理を含む残りのラベルをすべてブロックします。これは、望ましくない混合された簡略化されたラベルと伝統的なラベルの一部であることが判明したためです。
5. Allocate any remaining label; the original label would be such a label.
5. 残りのラベルを割り当てます。元のラベルはそのようなラベルになります。
The rules declarations would be represented as:
ルール宣言は次のように表されます。
<rules>
<!--"action" elements - order defines precedence-->
<action disp="blocked" any-variant="blocked" />
<action disp="allocatable" only-variants="simp both" />
<action disp="allocatable" only-variants="trad both" />
<action disp="blocked" any-variant="simp trad" />
<action disp="allocatable" comment="catch-all" />
</rules>
Up to now, variants with type "both" have occurred only associated with reflexive variant mappings. The "action" elements defined above rely on the assumption that this is always the case. However, consider the following set of variants:
これまで、「両方」タイプのバリアントは、再帰的バリアントマッピングにのみ関連付けられて発生していました。上記で定義された「アクション」要素は、これが常に当てはまるという前提に依存しています。ただし、次のバリアントのセットを検討してください。
U+62E0;U+636E;U+636E;U+64DA
U+636E;U+636E;U+64DA;U+62E0
U+64DA;U+636E;U+64DA;U+62E0
The corresponding XML would be:
対応するXMLは次のようになります。
<char cp="62E0">
<var cp="636E" type="both" comment="both, but not reflexive" />
<var cp="64DA" type="blocked" />
</char>
<char cp="636E">
<var cp="636E" type="simp" comment="reflexive, but not both" />
<var cp="64DA" type="trad" />
<var cp="62E0" type="blocked" />
</char>
<char cp="64DA">
<var cp="636E" type="simp" />
<var cp="64DA" type="trad" comment="reflexive" />
<var cp="62E0" type="blocked" />
</char>
To make such variant sets work requires a way to selectively trigger an action based on whether a variant type is associated with an identity or reflexive mapping, or is associated with an ordinary variant mapping. This can be done by adding a prefix "r-" to the "type" attribute on reflexive variant mappings. For example, the "trad" for code point U+64DA in the preceding figure would become "r-trad".
このようなバリアントセットを機能させるには、バリアントタイプがIDマッピングまたは再帰マッピングに関連付けられているか、通常のバリアントマッピングに関連付けられているかに基づいて、アクションを選択的にトリガーする方法が必要です。これは、再帰バリアントマッピングの「type」属性に接頭辞「r-」を追加することで実行できます。たとえば、前の図のコードポイントU + 64DAの「trad」は「r-trad」になります。
With the dispositions prepared in this way, only a slight modification to the actions is needed to yield the correct set of allocatable labels:
このように処理が準備されると、割り当て可能なラベルの正しいセットを生成するために、アクションを少し変更するだけで済みます。
<action disp="blocked" any-variant="blocked" />
<action disp="allocatable" only-variants="simp r-simp both r-both" />
<action disp="allocatable" only-variants="trad r-trad both r-both" />
<action disp="blocked" all-variants="simp trad both" />
<action disp="allocatable" />
The first three actions get triggered by the same labels as before.
最初の3つのアクションは、以前と同じラベルによってトリガーされます。
The fourth action blocks any label that combines an original code point with any mix of ordinary variant mappings; however, no labels that are a combination of only original code points (code points having either no variant mappings or a reflexive mapping) would be affected. These are the original labels, and they are allocated in the last action.
4番目のアクションは、元のコードポイントと通常のバリアントマッピングの組み合わせを組み合わせたラベルをブロックします。ただし、元のコードポイント（バリアントマッピングも再帰マッピングもないコードポイント）のみの組み合わせであるラベルは影響を受けません。これらは元のラベルであり、最後のアクションで割り当てられます。
Using this scheme of assigning types to ordinary and reflexive variants, all tables in the style of RFC 3743 can be converted to XML. By defining a set of actions as outlined above, the LGR will yield the correct set of allocatable variants: all variants consisting completely of variant code points preferred for simplified or traditional, respectively, will be allocated, as will be the original label. All other variant labels will be blocked.
タイプを通常の再帰バリアントに割り当てるこのスキームを使用して、RFC 3743のスタイルのすべてのテーブルをXMLに変換できます。上で概説したようにアクションのセットを定義することにより、LGRは割り当て可能なバリアントの正しいセットを生成します。単純化または従来のそれぞれに好ましいバリアントコードポイントで完全に構成されるすべてのバリアントは、元のラベルと同様に割り当てられます。他のすべてのバリアントラベルはブロックされます。
In LGRs for Indic scripts, it may be desirable to restrict valid labels to sequences of valid Indic syllables, or aksharas. This appendix gives a sample set of rules designed to enforce this restriction.
インド語スクリプトのLGRでは、有効なラベルを一連の有効なインド語の音節またはaksharaに制限することが望ましい場合があります。この付録では、この制限を適用するために設計されたルールのサンプルセットを示します。
Below is an example of BNF for an akshara, which has been published in "Devanagari Script Behaviour for Hindi" [TDIL-HINDI]. The rules for other languages and scripts used in India are expected to be generally similar.
以下は、「ヒンディー語のデバナガリスクリプトの動作」[TDIL-HINDI]で公開されているaksharaのBNFの例です。インドで使用される他の言語とスクリプトの規則は、一般的に同様であると予想されます。
For Hindi, the BNF has the form:
ヒンディー語の場合、BNFの形式は次のとおりです。
V[m]|{C[N]H}C[N](H|[v][m])
Where:
ただし：
V (uppercase) is any independent vowel
V（大文字）は独立した母音です
m is any vowel modifier (Devanagari Anusvara, Visarga, and Candrabindu)
mは任意の母音修飾子（Devanagari Anusvara、Visarga、およびCandrabindu）
C is any consonant (with inherent vowel)
Cは子音です（固有母音付き）
N is Nukta
これはヌクタです
H is a halant (or virama)
Hはハラント（またはvirama）
v (lowercase) is any dependent vowel sign (matra)
v（小文字）は依存する母音記号（マトラ）
{} encloses items that may be repeated one or more times
{}は、1回以上繰り返すことができるアイテムを囲みます
[ ] encloses items that may or may not be present
[]存在する場合と存在しない場合があるアイテムを囲みます
| separates items, out of which only one can be present By using the Unicode character property "InSC" or "Indic_Syllabic_Category", which corresponds rather directly to the classification of characters in the BNF above, we can translate the BNF into a set of WLE rules matching the definition of an akshara.
|上記のBNFの文字の分類に直接対応するUnicode文字プロパティ "InSC"または "Indic_Syllabic_Category"を使用することにより、BNFを一連のWLEルールに変換できます。 aksharaの定義に一致します。
<rules>
<!--Character class definitions go here-->
<class name="halant" property="InSC:Virama" />
<union name="vowel-modifier">
<class property="InSC:Visarga" />
<class property="InSC:Bindu" comment="includes anusvara" />
</union>
<!--Whole label evaluation and context rules go here-->
<rule name="consonant-with-optional-nukta">
<class by-ref="InSC:Consonant" />
<class by-ref="InSC:Nukta" count="0:1"/>
</rule>
<rule name="independent-vowel-with-optional-modifier">
<class by-ref="InSC:Vowel_Independent" />
<class by-ref="vowel-modifier" count="0:1" />
</rule>
<rule name="optional-dependent-vowel-with-opt-modifier" >
<class by-ref="InSC:Vowel_Dependent" count="0:1" />
<class by-ref="vowel-modifier" count="0:1" />
</rule>
<rule name="consonant-cluster">
<rule count="0+">
<rule by-ref="consonant-with-optional-nukta" />
<class by-ref="halant" />
</rule>
<rule by-ref="consonant-with-optional-nukta" />
<choice>
<class by-ref="halant" />
<rule by-ref="optional-dependent-vowel-with-opt-modifier" />
</choice>
</rule>
<rule name="akshara">
<choice>
<rule by-ref="independent-vowel-with-optional-modifier" />
<rule by-ref="consonant-cluster" />
</choice>
</rule>
<rule name="WLE-akshara-or-other" comment="series of one or
more aksharas, possibly alternating with other types of
code points such as digits">
<start />
<choice count="1+">
<class property="InSC:other" />
<rule by-ref="akshara" />
</choice>
<end />
</rule>
<!--"action" elements go here - order defines precedence-->
<action disp="invalid" not-match="WLE-akshara-or-other" />
</rules>
With the rules and classes as defined above, the final action assigns a disposition of "invalid" to all labels that are not composed of a sequence of well-formed aksharas, optionally interspersed with other characters, perhaps digits, for example.
上記で定義されたルールとクラスを使用して、最後のアクションは、オプションで他の文字、おそらく数字などが散在する一連の整形式のaksharaで構成されていないすべてのラベルに「無効」の後処理を割り当てます。
The relevant Unicode character property could be replicated by tagging repertoire values directly in the LGR; this would remove the dependency on any specific version of the Unicode Standard.
LGRでレパートリー値を直接タグ付けすることにより、関連するUnicode文字プロパティを複製できます。これにより、Unicode標準の特定のバージョンへの依存がなくなります。
Generally, dependent vowels may only follow consonant expressions; however, for some scripts, like Bengali, the Unicode Standard supports sequences of dependent vowels or their application on independent vowels. This makes the definition of akshara less restrictive.
一般に、従属母音は子音の表現に従うだけです。ただし、ベンガル語などの一部のスクリプトでは、Unicode標準は従属母音のシーケンスまたは独立母音でのそのアプリケーションをサポートしています。これにより、aksharaの定義の制限が緩和されます。
As presented in this example, the rules are rather complex -- although useful in demonstrating the features of the XML format, such complexity would be an undesirable feature in an actual LGR.
この例で示したように、ルールはかなり複雑です。XML形式の機能を示すのに役立ちますが、そのような複雑さは実際のLGRでは望ましくない機能です。
It is possible to reduce the complexity of the rules in this example by defining alternate rules that simply define the permissible pair-wise context of adjacent code points by character class, such as a rule that a halant can only follow a (nuktated) consonant. Such pair-wise contexts are easier to understand, implement, and verify, and have the additional benefit of allowing tools to better pinpoint why a label failed to validate. They also tend to correspond more directly to the kind of well-formedness requirements that are most relevant to DNS security, like the requirement to limit the application of a combining mark (such as a vowel modifier) to only selected base characters (in this case, vowels). (See the example and discussion in [WLE-RULES].)
この例では、ハラントが（ヌクテートされた）子音のみに従うことができるというルールなど、隣接するコードポイントのペアごとの許容コンテキストを文字クラスごとに単純に定義する代替ルールを定義することで、ルールの複雑さを軽減できます。そのようなペアワイズコンテキストは、理解、実装、および検証がより簡単であり、ラベルが検証に失敗した理由をツールがより正確に特定できるという追加の利点があります。また、結合マーク（母音修飾子など）の適用を選択された基本文字のみ（この場合）に制限する要件など、DNSセキュリティに最も関連する整形式の要件に直接対応する傾向があります。 、母音）。 （[WLE-RULES]の例と説明を参照してください。）
This schema is provided in RELAX NG Compact format [RELAX-NG].
このスキーマは、RELAX NG Compact形式[RELAX-NG]で提供されます。
<CODE BEGINS> # # LGR XML Schema 1.0 #
<コード開始>＃＃LGR XMLスキーマ1.0＃
default namespace = "urn:ietf:params:xml:ns:lgr-1.0"
# # SIMPLE TYPES #
＃＃シンプルなタイプ＃
# RFC 5646 language tag (e.g., "de", "und-Latn") language-tag = xsd:token
＃RFC 5646言語タグ（「de」、「und-Latn」など）language-tag = xsd：token
# The scope to which the LGR applies. For the "domain" scope type,
# it should be a fully qualified domain name.
scope-value = xsd:token {
minLength = "1"
}
## a single code point
code-point = xsd:token {
pattern = "[0-9A-F]{4,6}"
}
## a space-separated sequence of code points
code-point-sequence = xsd:token {
pattern = "[0-9A-F]{4,6}( [0-9A-F]{4,6})+"
}
## single code point, or a sequence of code points, or empty string code-point-literal = code-point | code-point-sequence | ""
##単一のコードポイント、またはコードポイントのシーケンス、または空の文字列code-point-literal = code-point |コードポイントシーケンス| 「」
## code point or sequence only non-empty-code-point-literal = code-point | code-point-sequence
##コードポイントまたはシーケンスのみ空でないコードポイントリテラル=コードポイント|コードポイントシーケンス
## code point sent represented in short form
code-point-set-shorthand = xsd:token {
pattern = "([0-9A-F]{4,6}|[0-9A-F]{4,6}-[0-9A-F]{4,6})"
~ "( ([0-9A-F]{4,6}|[0-9A-F]{4,6}-[0-9A-F]{4,6}))*"
}
## dates are used in information fields in the meta
## section ("YYYY-MM-DD")
date-pattern = xsd:token {
pattern = "\d{4}-\d\d-\d\d"
}
## variant type
## the variant type MUST be non-empty and MUST NOT
## start with a "_"; using xsd:NMTOKEN here because
## we need space-separated lists of them
variant-type = xsd:NMTOKEN
## variant type list for action triggers
## the list MUST NOT be empty, and entries MUST NOT
## start with a "_"
variant-type-list = xsd:NMTOKENS
## reference to a rule name (used in "when" and "not-when"
## attributes, as well as the "by-ref" attribute of the "rule"
## element).
rule-ref = xsd:IDREF
## a space-separated list of tags. Tags should generally follow
## xsd:Name syntax. However, we are using the xsd:NMTOKENS here
## because there is no native XSD datatype for space-separated
## xsd:Name
tags = xsd:NMTOKENS
## The value space of a "from-tag" attribute. Although it is closer
## to xsd:IDREF lexically and semantically, tags are not unique in
## the document. As such, we are unable to take advantage of
## facilities provided by a validator. xsd:NMTOKEN is used instead
## of the stricter xsd:Names here so as to be consistent with
## the above.
tag-ref = xsd:NMTOKEN
## an identifier type (used by "name" attributes).
identifier = xsd:ID
## used in the class "by-ref" attribute to reference another class of
## the same "name" attribute value.
class-ref = xsd:IDREF
## "count" attribute pattern ("n", "n+", or "n:m")
count-pattern = xsd:token {
pattern = "\d+(\+|:\d+)?"
}
## "ref" attribute pattern
## space-separated list of "id" attribute values for
## "reference" elements. These reference ids
## must be declared in a "reference" element
## before they can be used in a "ref" attribute
ref-pattern = xsd:token {
pattern = "[\-_.:0-9A-Z]+( [\-_.:0-9A-Z]+)*"
}
# # STRUCTURES #
＃＃構造＃
## Representation of a single code point or a sequence of code
## points
char = element char {
attribute cp { code-point-literal },
attribute comment { text }?,
attribute when { rule-ref }?,
attribute not-when { rule-ref }?,
attribute tag { tags }?,
attribute ref { ref-pattern }?,
variant*
}
## Representation of a range of code points
range = element range {
attribute first-cp { code-point },
attribute last-cp { code-point },
attribute comment { text }?,
attribute when { rule-ref }?,
attribute not-when { rule-ref }?,
attribute tag { tags }?,
attribute ref { ref-pattern }?
}
## Representation of a variant code point or sequence
variant = element var {
attribute cp { code-point-literal },
attribute type { xsd:NMTOKEN }?,
attribute when { rule-ref }?,
attribute not-when { rule-ref }?,
attribute comment { text }?,
attribute ref { ref-pattern }?
}
# # Classes #
＃ ＃ クラス ＃
## a "class" element that references the name of another "class"
## (or set-operator like "union") defined elsewhere.
## If used as a matcher (appearing under a "rule" element),
## the "count" attribute may be present.
class-invocation = element class { class-invocation-content }
class-invocation-content =
attribute by-ref { class-ref },
attribute count { count-pattern }?,
attribute comment { text }?
## defines a new class (set of code points) using Unicode property
## or code points of the same tag value or code point literals
class-declaration = element class { class-declaration-content }
class-declaration-content =
# "name" attribute MUST be present if this is a "top-level"
# class declaration, i.e., appearing directly under the "rules"
# element. Otherwise, it MUST be absent.
attribute name { identifier }?,
# If used as a matcher (appearing in a "rule" element, but not
# when nested inside a set-operator or class), the "count"
# attribute may be present. Otherwise, it MUST be absent.
attribute count { count-pattern }?,
attribute comment { text }?,
attribute ref { ref-pattern }?,
(
# define the class by property (e.g., property="sc:Latn"), OR
attribute property { xsd:NMTOKEN }
# define the class by tagged code points, OR
| attribute from-tag { tag-ref }
# text node to allow for shorthand notation
# e.g., "0061 0062-0063"
| code-point-set-shorthand
)
class-invocation-or-declaration = element class {
class-invocation-content | class-declaration-content
}
class-or-set-operator-nested = class-invocation-or-declaration | set-operator
class-or-set-operator-nested = class-invocation-or-declaration |集合演算子
class-or-set-operator-declaration = # a "class" element or set-operator (effectively defining a class) # directly in the "rules" element. class-declaration | set-operator
class-or-set-operator-declaration =＃「class」要素またはset-operator（効果的にクラスを定義）＃「rules」要素に直接。クラス宣言|集合演算子
# # set-operators #
＃＃セット演算子＃
complement-operator = element complement {
attribute name { identifier }?,
attribute comment { text }?,
attribute ref { ref-pattern }?,
# "count" attribute MUST only be used when this set-operator is
# used as a matcher (i.e., nested in a "rule" element but not
# inside a set-operator or class)
attribute count { count-pattern }?,
class-or-set-operator-nested
}
union-operator = element union {
attribute name { identifier }?,
attribute comment { text }?,
attribute ref { ref-pattern }?,
# "count" attribute MUST only be used when this set-operator is
# used as a matcher (i.e., nested in a "rule" element but not
# inside a set-operator or class)
attribute count { count-pattern }?,
class-or-set-operator-nested,
# needs two or more child elements
class-or-set-operator-nested+
}
intersection-operator = element intersection {
attribute name { identifier }?,
attribute comment { text }?,
attribute ref { ref-pattern }?,
# "count" attribute MUST only be used when this set-operator is
# used as a matcher (i.e., nested in a "rule" element but not
# inside a set-operator or class)
attribute count { count-pattern }?,
class-or-set-operator-nested,
class-or-set-operator-nested
}
difference-operator = element difference {
attribute name { identifier }?,
attribute comment { text }?,
attribute ref { ref-pattern }?,
# "count" attribute MUST only be used when this set-operator is
# used as a matcher (i.e., nested in a "rule" element but not
# inside a set-operator or class)
attribute count { count-pattern }?,
class-or-set-operator-nested,
class-or-set-operator-nested
}
symmetric-difference-operator = element symmetric-difference {
attribute name { identifier }?,
attribute comment { text }?,
attribute ref { ref-pattern }?,
# "count" attribute MUST only be used when this set-operator is
# used as a matcher (i.e., nested in a "rule" element but not
# inside a set-operator or class)
attribute count { count-pattern }?,
class-or-set-operator-nested,
class-or-set-operator-nested
}
## operators that transform class(es) into a new class.
set-operator = complement-operator
| union-operator
| intersection-operator
| difference-operator
| symmetric-difference-operator
# # Match operators (matchers) #
＃＃一致演算子（マッチャー）＃
any-matcher = element any {
attribute count { count-pattern }?,
attribute comment { text }?
}
choice-matcher = element choice {
## "count" attribute MUST only be used when the choice-matcher
## contains no nested "start", "end", "anchor", "look-behind",
## or "look-ahead" operators and no nested rule-matchers
## containing any of these elements
attribute count { count-pattern }?,
attribute comment { text }?,
# two or more match operators
match-operator-choice,
match-operator-choice+
}
char-matcher =
# for use as a matcher - like "char" but without a "tag" attribute
element char {
attribute cp { non-empty-code-point-literal },
# If used as a matcher (appearing in a "rule" element), the
# "count" attribute may be present. Otherwise, it MUST be
# absent.
attribute count { count-pattern }?,
attribute comment { text }?,
attribute ref { ref-pattern }?
}
start-matcher = element start {
attribute comment { text }?
}
end-matcher = element end {
attribute comment { text }?
}
anchor-matcher = element anchor {
attribute comment { text }?
}
look-ahead-matcher = element look-ahead {
attribute comment { text }?,
match-operators-non-pos
}
look-behind-matcher = element look-behind {
attribute comment { text }?,
match-operators-non-pos
}
## non-positional match operator that can be used as a direct child
## element of the choice-matcher.
match-operator-choice = (
any-matcher | choice-matcher | start-matcher | end-matcher
| char-matcher | class-or-set-operator-nested | rule-matcher
)
## non-positional match operators do not contain any "anchor",
## "look-behind", or "look-ahead" elements.
match-operators-non-pos = (
start-matcher?,
(any-matcher | choice-matcher | char-matcher
| class-or-set-operator-nested | rule-matcher)*,
end-matcher?
)
## positional match operators have an "anchor" element, which may be
## preceded by a "look-behind" element, or followed by a "look-ahead"
## element, or both.
match-operators-pos =
look-behind-matcher?, anchor-matcher, look-ahead-matcher?
match-operators = match-operators-non-pos | match-operators-pos
match-operators = match-operators-non-pos | match-operators-pos
# # Rules #
＃＃ルール＃
# top-level rule must have "name" attribute
rule-declaration-top = element rule {
attribute name { identifier },
attribute comment { text }?,
attribute ref { ref-pattern }?,
match-operators
}
## "rule" element used as a matcher (either "by-ref" or contains
## other match operators itself)
rule-matcher =
element rule {
## "count" attribute MUST only be used when the rule-matcher
## contains no nested "start", "end", "anchor", "look-behind",
## or "look-ahead" operators and no nested rule-matchers
## containing any of these elements
attribute count { count-pattern }?,
attribute comment { text }?,
attribute ref { ref-pattern }?,
(attribute by-ref { rule-ref } | match-operators)
}
# # Actions #
＃ ＃ 行動 ＃
action-declaration = element action {
attribute comment { text }?,
attribute ref { ref-pattern }?,
# dispositions are often named after variant types or vice versa
attribute disp { variant-type },
( attribute match { rule-ref }
| attribute not-match { rule-ref } )?,
( attribute any-variant { variant-type-list }
| attribute all-variants { variant-type-list }
| attribute only-variants { variant-type-list } )?
}
# DOCUMENT STRUCTURE
＃文書の構造
start = lgr
lgr = element lgr {
meta-section?,
data-section,
rules-section?
}
## Meta section - information recorded with an LGR that generally
## does not affect machine processing (except for "unicode-version").
## However, if any "class-declaration" uses the "property" attribute,
## a "unicode-version" element MUST be present.
meta-section = element meta {
element version {
attribute comment { text }?,
text
}?
& element date { date-pattern }?
& element language { language-tag }*
& element scope {
# type may by "domain" or an application-defined value
attribute type { xsd:NCName },
scope-value
}*
& element validity-start { date-pattern }?
& element validity-end { date-pattern }?
& element unicode-version {
xsd:token {
pattern = "\d+\.\d+\.\d+"
}
}?
& element description {
# this SHOULD be a valid MIME type
attribute type { text }?,
text
}?
& element references {
element reference {
attribute id {
xsd:token {
# limit "id" attribute to uppercase letters,
# digits, and a few punctuation marks; use of
# integers is RECOMMENDED
pattern = "[\-_.:0-9A-Z]*"
minLength = "1"
}
},
attribute comment { text }?,
text
}*
}?
}
data-section = element data { (char | range)+ }
## Note that action declarations are strictly order dependent.
## class-or-set-operator-declaration and rule-declaration-top
## are weakly order dependent; they must precede first use of the
## identifier via "by-ref".
rules-section = element rules {
( class-or-set-operator-declaration
| rule-declaration-top
| action-declaration)*
}
<CODE ENDS>
<コード終了>
Acknowledgements
謝辞
This format builds upon the work on documenting IDN tables by many different registry operators. Notably, a comprehensive language table for Chinese, Japanese, and Korean was developed by the "Joint Engineering Team" [RFC3743]; this table is the basis of many registry policies. Also, a set of guidelines for Arabic script registrations [RFC5564] was published by the Arabic-language community.
このフォーマットは、多くの異なるレジストリオペレーターによるIDNテーブルの文書化に関する作業に基づいています。特に、中国語、日本語、韓国語の包括的な言語テーブルは、「共同エンジニアリングチーム」[RFC3743]によって開発されました。このテーブルは、多くのレジストリポリシーの基礎です。また、アラビア語スクリプト登録のための一連のガイドライン[RFC5564]がアラビア語コミュニティによって公開されました。
Contributions that have shaped this document have been provided by Francisco Arias, Julien Bernard, Mark Davis, Martin Duerst, Paul Hoffman, Sarmad Hussain, Barry Leiba, Alexander Mayrhofer, Alexey Melnikov, Nicholas Ostler, Thomas Roessler, Audric Schiltknecht, Steve Sheng, Michel Suignard, Andrew Sullivan, Wil Tan, and John Yunker.
この文書を形作る寄稿は、Francisco Arias、Julien Bernard、Mark Davis、Martin Duerst、Paul Hoffman、Sarmad Hussain、Barry Leiba、Alexander Mayrhofer、Alexey Melnikov、Nicholas Ostler、Thomas Roessler、Audric Schiltknecht、Steve Sheng、Michel Suignard、Andrew Sullivan、Wil Tan、およびJohn Yunker。
Authors' Addresses
著者のアドレス
Kim Davies Internet Corporation for Assigned Names and Numbers 12025 Waterfront Drive Los Angeles, CA 90094 United States of America
Kim Davies Internet Corporation for Assigned Names and Numbers 12025 Waterfront Drive Los Angeles、CA 90094アメリカ合衆国
Phone: +1 310 301 5800
Email: kim.davies@icann.org
URI: http://www.icann.org/
Asmus Freytag ASMUS, Inc.
Asmus Freytag ASMUS、Inc.
Email: asmus@unicode.org