[要約] RFC 8794は、拡張可能なバイナリメタ言語（EBML）に関する規格であり、EBMLの目的は、バイナリデータの構造化と拡張性を提供することです。
Internet Engineering Task Force (IETF) S. Lhomme
Request for Comments: 8794
Category: Standards Track D. Rice
ISSN: 2070-1721
M. Bunkus
July 2020
Extensible Binary Meta Language
拡張可能なバイナリメタ言語
Abstract
概要
This document defines the Extensible Binary Meta Language (EBML) format as a binary container format designed for audio/video storage. EBML is designed as a binary equivalent to XML and uses a storage-efficient approach to build nested Elements with identifiers, lengths, and values. Similar to how an XML Schema defines the structure and semantics of an XML Document, this document defines how EBML Schemas are created to convey the semantics of an EBML Document.
このドキュメントでは、Extensible Binary Meta Language（EBML）形式を、オーディオ/ビデオストレージ用に設計されたバイナリコンテナー形式として定義します。 EBMLは、XMLと同等のバイナリとして設計されており、ストレージ効率の高いアプローチを使用して、識別子、長さ、および値を持つネストされた要素を構築します。 XMLスキーマがXMLドキュメントの構造とセマンティクスを定義する方法と同様に、このドキュメントは、EBMLドキュメントのセマンティクスを伝達するためのEBMLスキーマの作成方法を定義します。
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コミュニティのコンセンサスを表しています。これは公開レビューを受けており、Internet Engineering Steering Group（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 https://www.rfc-editor.org/info/rfc8794.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8794で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2020 IETFトラストおよび文書の作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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トラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction 2. Notation and Conventions 3. Structure 4. Variable-Size Integer 4.1. VINT_WIDTH 4.2. VINT_MARKER 4.3. VINT_DATA 4.4. VINT Examples 5. Element ID 6. Element Data Size 6.1. Data Size Format 6.2. Unknown Data Size 6.3. Data Size Values 7. EBML Element Types 7.1. Signed Integer Element 7.2. Unsigned Integer Element 7.3. Float Element 7.4. String Element 7.5. UTF-8 Element 7.6. Date Element 7.7. Master Element 7.8. Binary Element 8. EBML Document 8.1. EBML Header 8.2. EBML Body 9. EBML Stream 10. EBML Versioning 10.1. EBML Header Version 10.2. EBML Document Version 11. Elements semantics 11.1. EBML Schema 11.1.1. EBML Schema Example 11.1.2. "<EBMLSchema>" Element 11.1.3. "<EBMLSchema>" Namespace 11.1.4. "<EBMLSchema>" Attributes 11.1.5. "<element>" Element 11.1.6. "<element>" Attributes 11.1.7. "<documentation>" Element 11.1.8. "<documentation>" Attributes 11.1.9. "<implementation_note>" Element 11.1.10. "<implementation_note>" Attributes 11.1.11. "<restriction>" Element 11.1.12. "<enum>" Element 11.1.13. "<enum>" Attributes 11.1.14. "<extension>" Element 11.1.15. "<extension>" Attributes 11.1.16. XML Schema for EBML Schema 11.1.17. Identically Recurring Elements 11.1.18. Textual expression of floats 11.1.19. Note on the use of default attributes to define Mandatory EBML Elements 11.2. EBML Header Elements 11.2.1. EBML Element 11.2.2. EBMLVersion Element 11.2.3. EBMLReadVersion Element 11.2.4. EBMLMaxIDLength Element 11.2.5. EBMLMaxSizeLength Element 11.2.6. DocType Element 11.2.7. DocTypeVersion Element 11.2.8. DocTypeReadVersion Element 11.2.9. DocTypeExtension Element 11.2.10. DocTypeExtensionName Element 11.2.11. DocTypeExtensionVersion Element 11.3. Global Elements 11.3.1. CRC-32 Element 11.3.2. Void Element 12. Considerations for Reading EBML Data 13. Terminating Elements 14. Guidelines for Updating Elements 14.1. Reducing Element Data in Size 14.1.1. Adding a Void Element 14.1.2. Extending the Element Data Size 14.1.3. Terminating Element Data 14.2. Considerations when Updating Elements with Cyclic Redundancy Check (CRC) 15. Backward and Forward Compatibility 15.1. Backward Compatibility 15.2. Forward Compatibility 16. Security Considerations 17. IANA Considerations 17.1. EBML Element IDs Registry 17.2. EBML DocTypes Registry 18. Normative References 19. Informative References Authors' Addresses
1. はじめに2.表記と規則3.構造4.可変サイズの整数4.1。 VINT_WIDTH 4.2。 VINT_MARKER 4.3。 VINT_DATA 4.4。 VINTの例5.要素ID 6.要素のデータサイズ6.1。データサイズフォーマット6.2。不明なデータサイズ6.3。データサイズ値7. EBML要素タイプ7.1。符号付き整数要素7.2。符号なし整数要素7.3。フロート要素7.4。文字列要素7.5。 UTF-8要素7.6。日付要素7.7。マスター要素7.8。 Binary Element 8. EBMLドキュメント8.1。 EBMLヘッダー8.2。 EBMLボディ9. EBMLストリーム10. EBMLバージョニング10.1 EBMLヘッダーバージョン10.2 EBMLドキュメントバージョン11.要素のセマンティクス11.1 EBMLスキーマ11.1.1。 EBMLスキーマの例11.1.2。 「<EBMLSchema>」要素11.1.3。 "<EBMLSchema>"名前空間11.1.4。 "<EBMLSchema>"属性11.1.5。 「<要素>」要素11.1.6。 "<element>"属性11.1.7。 「<documentation>」要素11.1.8。 "<documentation>"属性11.1.9。 「<implementation_note>」要素11.1.10。 "<implementation_note>"属性11.1.11。 「<restriction>」要素11.1.12。 「<enum>」要素11.1.13。 「<enum>」属性11.1.14。 「<extension>」要素11.1.15。 「<拡張子>」の属性11.1.16。 EBMLスキーマのXMLスキーマ11.1.17。同一に繰り返される要素11.1.18。フロートのテキスト表現11.1.19。デフォルトの属性を使用して必須のEBML要素を定義することに注意してください11.2。 EBMLヘッダー要素11.2.1。 EBML要素11.2.2。 EBMLVersion要素11.2.3。 EBMLReadVersion要素11.2.4。 EBMLMaxIDLength要素11.2.5。 EBMLMaxSizeLength要素11.2.6。 DocType要素11.2.7。 DocTypeVersion要素11.2.8。 DocTypeReadVersion要素11.2.9。 DocTypeExtension要素11.2.10。 DocTypeExtensionName要素11.2.11。 DocTypeExtensionVersion要素11.3。グローバル要素11.3.1。 CRC-32要素11.3.2。 Voidエレメント12. EBMLデータの読み取りに関する考慮事項13.エレメントの終了14.エレメントを更新するためのガイドライン14.1。サイズの要素データの削減14.1.1。 Void要素の追加14.1.2。要素データサイズの拡張14.1.3。要素データの終了14.2。巡回冗長検査（CRC）を使用して要素を更新する際の考慮事項15.下位互換性と上位互換性15.1。下位互換性15.2。前方互換性16.セキュリティに関する考慮事項17. IANAに関する考慮事項17.1。 EBML要素IDレジストリ17.2。 EBML DocTypesレジストリ18.規範的な参照19.有益な参照著者のアドレス
EBML, short for Extensible Binary Meta Language, specifies a binary format aligned with octets (bytes) and inspired by the principle of XML (a framework for structuring data).
EBML（Extensible Binary Meta Languageの略）は、オクテット（バイト）に揃えられ、XML（データを構造化するためのフレームワーク）の原理に着想を得たバイナリ形式を指定します。
The goal of this document is to define a generic, binary, space-efficient format that can be used to define more complex formats using an EBML Schema. EBML is used by the multimedia container, Matroska [Matroska]. The applicability of EBML for other use cases is beyond the scope of this document.
このドキュメントの目的は、EBMLスキーマを使用してより複雑なフォーマットを定義するために使用できる、一般的なバイナリのスペース効率の良いフォーマットを定義することです。 EBMLは、マルチメディアコンテナーであるMatroska [Matroska]によって使用されます。他のユースケースへのEBMLの適用性は、このドキュメントの範囲を超えています。
The definition of the EBML format recognizes the idea behind HTML and XML as a good one: separate structure and semantics allowing the same structural layer to be used with multiple, possibly widely differing, semantic layers. Except for the EBML Header and a few Global Elements, this specification does not define particular EBML format semantics; however, this specification is intended to define how other EBML-based formats can be defined, such as the audio/video container formats Matroska and WebM [WebM].
EBML形式の定義は、HTMLとXMLの背後にある考え方を良いものとして認識しています。別々の構造とセマンティクスにより、同じ構造レイヤーを複数の、場合によっては大きく異なるセマンティックレイヤーで使用できるようになります。 EBMLヘッダーといくつかのグローバル要素を除いて、この仕様は特定のEBML形式のセマンティクスを定義していません。ただし、この仕様は、オーディオ/ビデオコンテナー形式のMatroskaやWebM [WebM]など、他のEBMLベースの形式を定義する方法を定義することを目的としています。
EBML uses a simple approach of building Elements upon three pieces of data (tag, length, and value), as this approach is well known, easy to parse, and allows selective data parsing. The EBML structure additionally allows for hierarchical arrangement to support complex structural formats in an efficient manner.
EBMLは、3つのデータ（タグ、長さ、および値）に基づいて要素を構築する単純なアプローチを使用します。このアプローチはよく知られており、解析が簡単で、選択的なデータ解析が可能です。さらに、EBML構造により、階層的な配置が可能になり、複雑な構造フォーマットを効率的にサポートできます。
A typical EBML file has the following structure:
一般的なEBMLファイルの構造は次のとおりです。
EBML Header (master)
+ DocType (string)
+ DocTypeVersion (unsigned integer)
EBML Body Root (master)
+ ElementA (utf-8)
+ Parent (master)
+ ElementB (integer)
+ Parent (master)
+ ElementB (integer)
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
This document defines specific terms in order to define the format and application of "EBML". Specific terms are defined below:
このドキュメントでは、「EBML」の形式とアプリケーションを定義するために特定の用語を定義しています。特定の用語を以下に定義します。
"EBML": Extensible Binary Meta Language
"EBML"：拡張可能なバイナリメタ言語
"EBML Document Type": A name provided by an "EBML Schema" to designate a particular implementation of "EBML" for a data format (e.g., Matroska and WebM).
「EBMLドキュメントタイプ」：「EBMLスキーマ」によって提供される名前で、データ形式（MatroskaやWebMなど）の「EBML」の特定の実装を指定します。
"EBML Schema": A standardized definition for the structure of an "EBML Document Type".
「EBMLスキーマ」：「EBMLドキュメントタイプ」の構造の標準化された定義。
"EBML Document": A datastream comprised of only two components, an "EBML Header" and an "EBML Body".
「EBMLドキュメント」：「EBMLヘッダー」と「EBMLボディ」の2つのコンポーネントのみで構成されるデータストリーム。
"EBML Reader": A data parser that interprets the semantics of an "EBML Document" and creates a way for programs to use "EBML".
「EBMLリーダー」：「EBMLドキュメント」のセマンティクスを解釈し、プログラムが「EBML」を使用する方法を作成するデータパーサー。
"EBML Stream": A file that consists of one or more "EBML Documents" that are concatenated together.
「EBMLストリーム」：連結された1つ以上の「EBMLドキュメント」で構成されるファイル。
"EBML Header": A declaration that provides processing instructions and identification of the "EBML Body". The "EBML Header" is analogous to an XML Declaration [XML] (see Section 2.8 on "Prolog and Document Type Declaration").
「EBMLヘッダー」：処理命令と「EBML本文」の識別を提供する宣言。 「EBMLヘッダー」は、XML宣言[XML]に似ています（「プロローグおよびドキュメントタイプの宣言」のセクション2.8を参照）。
"EBML Body": All data of an "EBML Document" following the "EBML Header".
「EBML本文」：「EBMLヘッダー」に続く「EBMLドキュメント」のすべてのデータ。
"Variable-Size Integer": A compact variable-length binary value that defines its own length.
「可変サイズの整数」：独自の長さを定義するコンパクトな可変長のバイナリ値。
"VINT": Also known as "Variable-Size Integer".
「VINT」：「可変サイズの整数」とも呼ばれます。
"EBML Element": A foundation block of data that contains three parts: an "Element ID", an "Element Data Size", and "Element Data".
「EBMLエレメント」：「エレメントID」、「エレメントデータサイズ」、「エレメントデータ」の3つの部分を含むデータの基礎ブロック。
"Element ID": A binary value, encoded as a "Variable-Size Integer", used to uniquely identify a defined "EBML Element" within a specific "EBML Schema".
「要素ID」：特定の「EBMLスキーマ」内で定義された「EBML要素」を一意に識別するために使用される「変数サイズの整数」としてエンコードされたバイナリ値。
"Element Data Size": An expression, encoded as a "Variable-Size Integer", of the length in octets of "Element Data".
「Element Data Size」：「Variable-Size Integer」としてエンコードされた、「Element Data」のオクテット単位の長さの式。
"VINTMAX": The maximum possible value that can be stored as "Element Data Size".
「VINTMAX」：「エレメントデータサイズ」として保存できる最大可能値。
"Unknown-Sized Element": An "Element" with an unknown "Element Data Size".
「不明なサイズの要素」：「要素のデータサイズ」が不明な「要素」。
"Element Data": The value(s) of the "EBML Element", which is identified by its "Element ID" and "Element Data Size". The form of the "Element Data" is defined by this document and the corresponding "EBML Schema" of the Element's "EBML Document Type".
「要素データ」：「EBML要素」の値。「要素ID」と「要素データサイズ」で識別されます。 「要素データ」の形式は、このドキュメントと、要素の「EBMLドキュメントタイプ」の対応する「EBMLスキーマ」によって定義されます。
"Root Level": The starting level in the hierarchy of an "EBML Document".
「ルートレベル」：「EBMLドキュメント」の階層の開始レベル。
"Root Element": A mandatory, nonrepeating "EBML Element" that occurs at the top level of the path hierarchy within an "EBML Body" and contains all other "EBML Elements" of the "EBML Body", excepting optional "Void Elements".
「ルート要素」：「EBML本体」内のパス階層の最上位レベルで発生し、「EBML本体」の他のすべての「EBML要素」を含む必須の繰り返しのない「EBML要素」。オプションの「Void要素」を除く。
"Top-Level Element": An "EBML Element" defined to only occur as a "Child Element" of the "Root Element".
「最上位要素」：「ルート要素」の「子要素」としてのみ発生するように定義された「EBML要素」。
"Master Element": The "Master Element" contains zero, one, or many other "EBML Elements".
「マスター要素」：「マスター要素」には、0個、1個、または他の多くの「EBML要素」が含まれます。
"Child Element": A "Child Element" is a relative term to describe the "EBML Elements" immediately contained within a "Master Element".
「子要素」：「子要素」は、「マスター要素」内に直接含まれる「EBML要素」を表す相対的な用語です。
"Parent Element": A relative term to describe the "Master Element" that contains a specified element. For any specified "EBML Element" that is not at "Root Level", the "Parent Element" refers to the "Master Element" in which that "EBML Element" is directly contained.
「親要素」：指定した要素を含む「マスター要素」を表す相対的な用語。 「ルートレベル」にない指定された「EBML要素」の場合、「親要素」は、その「EBML要素」が直接含まれる「マスター要素」を指します。
"Descendant Element": A relative term to describe any "EBML Elements" contained within a "Master Element", including any of the "Child Elements" of its "Child Elements", and so on.
「子孫要素」：「子要素」の「子要素」などを含む「マスター要素」内に含まれる「EBML要素」を説明する相対的な用語。
"Void Element": An "Element" used to overwrite data or reserve space within a "Master Element" for later use.
「無効な要素」：データを上書きするか、「マスター要素」内のスペースを後で使用するために予約するために使用される「要素」。
"Element Name": The human-readable name of the "EBML Element".
「エレメント名」：人間が読める「EBMLエレメント」の名前。
"Element Path": The hierarchy of "Parent Element" where the "EBML Element" is expected to be found in the "EBML Body".
「エレメントパス」：「EBMLエレメント」が「EBMLボディ」で見つかると予想される「親エレメント」の階層。
"Empty Element": An "EBML Element" that has an "Element Data Size" with all "VINT_DATA" bits set to zero, which indicates that the "Element Data" of the "Element" is zero octets in length.
「空の要素」：すべての「VINT_DATA」ビットがゼロに設定された「要素データサイズ」を持つ「EBML要素」は、「要素」の「要素データ」の長さが0オクテットであることを示します。
EBML uses a system of Elements to compose an EBML Document. EBML Elements incorporate three parts: an Element ID, an Element Data Size, and Element Data. The Element Data, which is described by the Element ID, includes either binary data, one or more other EBML Elements, or both.
EBMLは、要素のシステムを使用してEBMLドキュメントを作成します。 EBML要素には、要素ID、要素データサイズ、要素データの3つの部分が組み込まれています。要素IDによって記述される要素データには、バイナリデータ、1つ以上の他のEBML要素、またはその両方が含まれます。
The Element ID and Element Data Size are both encoded as a Variable-Size Integer. The Variable-Size Integer is composed of a VINT_WIDTH, VINT_MARKER, and VINT_DATA, in that order. Variable-Size Integers MUST left-pad the VINT_DATA value with zero bits so that the whole Variable-Size Integer is octet aligned. The Variable-Size Integer will be referred to as VINT for shorthand.
要素IDと要素データサイズはどちらも可変サイズの整数としてエンコードされます。可変サイズの整数は、VINT_WIDTH、VINT_MARKER、VINT_DATAの順に構成されています。可変サイズの整数は、可変サイズの整数全体がオクテットに揃えられるように、VINT_DATA値にゼロビットを左側に埋め込む必要があります。可変サイズの整数は、略してVINTと呼ばれます。
Each Variable-Size Integer starts with a VINT_WIDTH followed by a VINT_MARKER. VINT_WIDTH is a sequence of zero or more bits of value "0" and is terminated by the VINT_MARKER, which is a single bit of value "1". The total length in bits of both VINT_WIDTH and VINT_MARKER is the total length in octets in of the Variable-Size Integer.
各可変サイズの整数はVINT_WIDTHで始まり、その後にVINT_MARKERが続きます。 VINT_WIDTHは、値「0」の0個以上のビットのシーケンスであり、値「1」の単一ビットであるVINT_MARKERで終了します。 VINT_WIDTHとVINT_MARKERの両方のビット単位の全長は、可変サイズの整数のオクテット単位の全長です。
The single bit "1" starts a Variable-Size Integer with a length of one octet. The sequence of bits "01" starts a Variable-Size Integer with a length of two octets. "001" starts a Variable-Size Integer with a length of three octets, and so on, with each additional "0" bit adding one octet to the length of the Variable-Size Integer.
単一ビット「1」は、1オクテットの長さの可変サイズ整数を開始します。ビット「01」のシーケンスは、2オクテットの長さの可変サイズ整数を開始します。 「001」は、3オクテットの長さで可変サイズの整数を開始します。「0」ビットを追加するたびに、可変サイズの整数の長さに1オクテットが追加されます。
The VINT_MARKER serves as a separator between the VINT_WIDTH and VINT_DATA. Each Variable-Size Integer MUST contain exactly one VINT_MARKER. The VINT_MARKER is one bit in length and contain a bit with a value of one. The first bit with a value of one within the Variable-Size Integer is the VINT_MARKER.
VINT_MARKERは、VINT_WIDTHとVINT_DATAの間のセパレーターとして機能します。各可変サイズの整数には、正確に1つのVINT_MARKERが含まれている必要があります。 VINT_MARKERは長さが1ビットで、値が1のビットが含まれています。可変サイズの整数内の値が1である最初のビットはVINT_MARKERです。
The VINT_DATA portion of the Variable-Size Integer includes all data following (but not including) the VINT_MARKER until end of the Variable-Size Integer whose length is derived from the VINT_WIDTH. The bits required for the VINT_WIDTH and the VINT_MARKER use one out of every eight bits of the total length of the Variable-Size Integer. Thus, a Variable-Size Integer of 1-octet length supplies 7 bits for VINT_DATA, a 2-octet length supplies 14 bits for VINT_DATA, and a 3-octet length supplies 21 bits for VINT_DATA. If the number of bits required for VINT_DATA is less than the bit size of VINT_DATA, then VINT_DATA MUST be zero-padded to the left to a size that fits. The VINT_DATA value MUST be expressed as a big-endian unsigned integer.
可変サイズの整数のVINT_DATA部分には、長さがVINT_WIDTHから派生する可変サイズの整数の終わりまで、VINT_MARKERに続く（含まない）すべてのデータが含まれます。 VINT_WIDTHとVINT_MARKERに必要なビットは、可変サイズ整数の全長の8ビットごとに1つを使用します。したがって、1オクテット長の可変サイズ整数はVINT_DATAに7ビットを提供し、2オクテット長はVINT_DATAに14ビットを提供し、3オクテット長はVINT_DATAに21ビットを提供します。 VINT_DATAに必要なビット数がVINT_DATAのビットサイズよりも小さい場合は、VINT_DATAを適切なサイズになるように左側にゼロパディングする必要があります。 VINT_DATA値は、ビッグエンディアンの符号なし整数として表現する必要があります。
Table 1 shows examples of Variable-Size Integers with lengths from 1 to 5 octets. The "Usable Bits" column refers to the number of bits that can be used in the VINT_DATA. The "Representation" column depicts a binary expression of Variable-Size Integers where VINT_WIDTH is depicted by "0", the VINT_MARKER as "1", and the VINT_DATA as "x".
表1は、長さが1〜5オクテットの可変サイズ整数の例を示しています。 「使用可能なビット」列は、VINT_DATAで使用できるビット数を示します。 「Representation」列は、可変サイズの整数のバイナリ式を示しています。VINT_WIDTHは「0」、VINT_MARKERは「1」、VINT_DATAは「x」で表されています。
+==============+=============+===============================+
| Octet Length | Usable Bits | Representation |
+==============+=============+===============================+
| 1 | 7 | 1xxx xxxx |
+--------------+-------------+-------------------------------+
| 2 | 14 | 01xx xxxx xxxx xxxx |
+--------------+-------------+-------------------------------+
| 3 | 21 | 001x xxxx xxxx xxxx xxxx xxxx |
+--------------+-------------+-------------------------------+
| 4 | 28 | 0001 xxxx xxxx xxxx xxxx xxxx |
| | | xxxx xxxx |
+--------------+-------------+-------------------------------+
| 5 | 35 | 0000 1xxx xxxx xxxx xxxx xxxx |
| | | xxxx xxxx xxxx xxxx |
+--------------+-------------+-------------------------------+
Table 1: VINT examples depicting usable bits
表1：使用可能なビットを表すVINTの例
A Variable-Size Integer may be rendered at octet lengths larger than needed to store the data in order to facilitate overwriting it at a later date -- e.g., when its final size isn't known in advance. In Table 2, an integer "2" (with a corresponding binary value of 0b10) is shown encoded as different Variable-Size Integers with lengths from one octet to four octets. All four encoded examples have identical semantic meaning, though the VINT_WIDTH and the padding of the VINT_DATA vary.
可変サイズの整数は、データを格納するために必要なオクテット長よりも長い長さでレンダリングされる場合があります。たとえば、最終的なサイズが事前にわからない場合などに、後でデータを上書きできるようにするためです。表2では、整数 "2"（対応するバイナリ値0b10）は、1オクテットから4オクテットまでの長さのさまざまな可変サイズ整数としてエンコードされています。 VINT_WIDTHとVINT_DATAのパディングは異なりますが、4つのエンコードされた例はすべて同じ意味を持っています。
+=========+==============+=====================+====================+
| Integer | Octet | As Represented in | As Represented in |
| | Length | VINT (binary) | VINT (hexadecimal) |
+=========+==============+=====================+====================+
| 2 | 1 | 1000 0010 | 0x82 |
+---------+--------------+---------------------+--------------------+
| 2 | 2 | 0100 0000 0000 0010 | 0x4002 |
+---------+--------------+---------------------+--------------------+
| 2 | 3 | 0010 0000 0000 0000 | 0x200002 |
| | | 0000 0010 | |
+---------+--------------+---------------------+--------------------+
| 2 | 4 | 0001 0000 0000 0000 | 0x10000002 |
| | | 0000 0000 0000 0010 | |
+---------+--------------+---------------------+--------------------+
Table 2: VINT examples depicting the same integer value rendered at different VINT lengths
表2：異なるVINT長でレンダリングされた同じ整数値を示すVINTの例
An Element ID is a Variable-Size Integer. By default, Element IDs are from one octet to four octets in length, although Element IDs of greater lengths MAY be used if the EBMLMaxIDLength Element of the EBML Header is set to a value greater than four (see Section 11.2.4). The bits of the VINT_DATA component of the Element ID MUST NOT be all "0" values or all "1" values. The VINT_DATA component of the Element ID MUST be encoded at the shortest valid length. For example, an Element ID with binary encoding of "1011 1111" is valid, whereas an Element ID with binary encoding of "0100 0000 0011 1111" stores a semantically equal VINT_DATA but is invalid, because a shorter VINT encoding is possible. Additionally, an Element ID with binary encoding of "1111 1111" is invalid, since the VINT_DATA section is set to all one values, whereas an Element ID with binary encoding of "0100 0000 0111 1111" stores a semantically equal VINT_DATA and is the shortest-possible VINT encoding.
要素IDは可変サイズの整数です。デフォルトでは、要素IDの長さは1オクテットから4オクテットですが、EBMLヘッダーのEBMLMaxIDLength要素が4より大きい値に設定されている場合は、より長い要素IDを使用できます（セクション11.2.4を参照）。要素IDのVINT_DATAコンポーネントのビットは、すべて「0」値またはすべて「1」値であってはなりません。要素IDのVINT_DATAコンポーネントは、有効な最短の長さでエンコードする必要があります。たとえば、バイナリエンコーディングが「1011 1111」のElement IDは有効ですが、バイナリエンコーディングが「0100 0000 0011 1111」のElement IDは、意味的に等しいVINT_DATAを格納しますが、短いVINTエンコーディングが可能であるため無効です。さらに、VINT_DATAセクションがすべて1の値に設定されているため、バイナリエンコードが「1111 1111」のElement IDは無効ですが、バイナリエンコードが「0100 0000 0111 1111」のElement IDは、意味的に等しいVINT_DATAを格納し、最短です-可能なVINTエンコーディング。
Table 3 details these specific examples further:
表3に、これらの具体例の詳細を示します。
+============+=============+================+====================+
| VINT_WIDTH | VINT_MARKER | VINT_DATA | Element ID Status |
+============+=============+================+====================+
| | 1 | 0000000 | Invalid: VINT_DATA |
| | | | MUST NOT be set to |
| | | | all 0 |
+------------+-------------+----------------+--------------------+
| 0 | 1 | 00000000000000 | Invalid: VINT_DATA |
| | | | MUST NOT be set to |
| | | | all 0 |
+------------+-------------+----------------+--------------------+
| | 1 | 0000001 | Valid |
+------------+-------------+----------------+--------------------+
| 0 | 1 | 00000000000001 | Invalid: A shorter |
| | | | VINT_DATA encoding |
| | | | is available. |
+------------+-------------+----------------+--------------------+
| | 1 | 0111111 | Valid |
+------------+-------------+----------------+--------------------+
| 0 | 1 | 00000000111111 | Invalid: A shorter |
| | | | VINT_DATA encoding |
| | | | is available. |
+------------+-------------+----------------+--------------------+
| | 1 | 1111111 | Invalid: VINT_DATA |
| | | | MUST NOT be set to |
| | | | all 1 |
+------------+-------------+----------------+--------------------+
| 0 | 1 | 00000001111111 | Valid |
+------------+-------------+----------------+--------------------+
Table 3: Examples of valid and invalid Element IDs
表3：有効な要素IDと無効な要素IDの例
The range and count of possible Element IDs are determined by their octet length. Examples of this are provided in Table 4.
可能なエレメントIDの範囲と数は、オクテットの長さによって決まります。この例を表4に示します。
+=========================+================+=================+
| Element ID Octet Length | Range of Valid | Number of Valid |
| | Element IDs | Element IDs |
+=========================+================+=================+
| 1 | 0x81 - 0xFE | 126 |
+-------------------------+----------------+-----------------+
| 2 | 0x407F - | 16,256 |
| | 0x7FFE | |
+-------------------------+----------------+-----------------+
| 3 | 0x203FFF - | 2,080,768 |
| | 0x3FFFFE | |
+-------------------------+----------------+-----------------+
| 4 | 0x101FFFFF - | 268,338,304 |
| | 0x1FFFFFFE | |
+-------------------------+----------------+-----------------+
Table 4: Examples of count and range for Element IDs at various octet lengths
表4：さまざまなオクテット長での要素IDの数と範囲の例
The Element Data Size expresses the length in octets of Element Data. The Element Data Size itself is encoded as a Variable-Size Integer. By default, Element Data Sizes can be encoded in lengths from one octet to eight octets, although Element Data Sizes of greater lengths MAY be used if the octet length of the longest Element Data Size of the EBML Document is declared in the EBMLMaxSizeLength Element of the EBML Header (see Section 11.2.5). Unlike the VINT_DATA of the Element ID, the VINT_DATA component of the Element Data Size is not mandated to be encoded at the shortest valid length. For example, an Element Data Size with binary encoding of 1011 1111 or a binary encoding of 0100 0000 0011 1111 are both valid Element Data Sizes and both store a semantically equal value (both 0b00000000111111 and 0b0111111, the VINT_DATA sections of the examples, represent the integer 63).
要素データサイズは、要素データの長さをオクテット単位で表します。要素データサイズ自体は、可変サイズの整数としてエンコードされます。デフォルトでは、要素データサイズは1オクテットから8オクテットの長さでエンコードできますが、EBMLドキュメントの最長の要素データサイズのオクテット長がのEBMLMaxSizeLength要素で宣言されている場合は、より長い要素データサイズを使用できます。 EBMLヘッダー（セクション11.2.5を参照）。エレメントIDのVINT_DATAとは異なり、エレメントデータサイズのVINT_DATAコンポーネントは、有効な最短の長さでエンコードするように義務付けられていません。たとえば、バイナリエンコーディングが1011 1111またはバイナリエンコーディングが0100 0000 0011 1111の要素データサイズはどちらも有効な要素データサイズであり、どちらも意味的に等しい値を格納します（例のVINT_DATAセクションである0b00000000111111と0b0111111の両方は、整数63）。
Although an Element ID with all VINT_DATA bits set to zero is invalid, an Element Data Size with all VINT_DATA bits set to zero is allowed for EBML Element Types that do not mandate a nonzero length (see Section 7). An Element Data Size with all VINT_DATA bits set to zero indicates that the Element Data is zero octets in length. Such an EBML Element is referred to as an Empty Element. If an Empty Element has a default value declared, then the EBML Reader MUST interpret the value of the Empty Element as the default value. If an Empty Element has no default value declared, then the EBML Reader MUST use the value of the Empty Element for the corresponding EBML Element Type of the Element ID, 0 for numbers and an empty string for strings.
すべてのVINT_DATAビットがゼロに設定された要素IDは無効ですが、ゼロ以外の長さを要求しないEBML要素タイプには、すべてのVINT_DATAビットがゼロに設定された要素データサイズが許可されます（セクション7を参照）。すべてのVINT_DATAビットがゼロに設定された要素データサイズは、要素データの長さが0オクテットであることを示します。このようなEBML要素は、空の要素と呼ばれます。空の要素にデフォルト値が宣言されている場合、EBMLリーダーは空の要素の値をデフォルト値として解釈する必要があります。空の要素にデフォルト値が宣言されていない場合、EBMLリーダーは、要素IDの対応するEBML要素タイプに空の要素の値を使用する必要があります。0は数字、空の文字列は文字列に使用します。
An Element Data Size with all VINT_DATA bits set to one is reserved as an indicator that the size of the EBML Element is unknown. The only reserved value for the VINT_DATA of Element Data Size is all bits set to one. An EBML Element with an unknown Element Data Size is referred to as an Unknown-Sized Element. Only a Master Element is allowed to be of unknown size, and it can only be so if the "unknownsizeallowed" attribute of its EBML Schema is set to true (see Section 11.1.6.10).
すべてのVINT_DATAビットが1に設定されたエレメントデータサイズは、EBMLエレメントのサイズが不明であることを示すインジケータとして予約されています。 Element Data SizeのVINT_DATAに予約されている唯一の値は、すべてのビットが1に設定されていることです。不明なエレメントデータサイズのEBMLエレメントは、不明なサイズのエレメントと呼ばれます。マスターエレメントのみが不明なサイズであることが許可され、EBMLスキーマの「unknownsizeallowed」属性がtrueに設定されている場合にのみ許可されます（セクション11.1.6.10を参照）。
The use of Unknown-Sized Elements allows an EBML Element to be written and read before the size of the EBML Element is known. Unknown-Sized Elements MUST only be used if the Element Data Size is not known before the Element Data is written, such as in some cases of datastreaming. The end of an Unknown-Sized Element is determined by whichever comes first:
サイズの不明な要素を使用すると、EBML要素のサイズがわかる前に、EBML要素を読み書きできます。不明なサイズの要素は、データストリーミングの場合など、要素データが書き込まれる前に要素データサイズが不明な場合にのみ使用する必要があります。不明なサイズの要素の終了は、どちらが先かによって決まります。
* Any EBML Element that is a valid Parent Element of the Unknown-Sized Element according to the EBML Schema, Global Elements excluded.
* EBMLスキーマに従って、不明なサイズの要素の有効な親要素であるEBML要素。グローバル要素は除外されます。
* Any valid EBML Element according to the EBML Schema, Global Elements excluded, that is not a Descendant Element of the Unknown-Sized Element but shares a common direct parent, such as a Top-Level Element.
* サイズが不明な要素の子孫要素ではないが、最上位要素などの共通の直接の親を共有する、EBMLスキーマによる有効なEBML要素。グローバル要素は除外されます。
* Any EBML Element that is a valid Root Element according to the EBML Schema, Global Elements excluded.
* EBMLスキーマに従って有効なルート要素であるすべてのEBML要素。グローバル要素は除外されます。
* The end of the Parent Element with a known size has been reached.
* 既知のサイズの親要素の終わりに達しました。
* The end of the EBML Document, either when reaching the end of the file or because a new EBML Header started.
* ファイルの終わりに達したとき、または新しいEBMLヘッダーが開始されたための、EBMLドキュメントの終わり。
Consider an Unknown-Sized Element whose EBML path is "\root\level1\level2\elt". When reading a new Element ID, assuming the EBML Path of that new Element is valid, here are some possible and impossible ways that this new Element is ending "elt":
EBMLパスが「\ root \ level1 \ level2 \ elt」である不明なサイズの要素について考えます。新しい要素のEBMLパスが有効であると想定して、新しい要素IDを読み取る場合、この新しい要素が「elt」で終了する可能性と不可能性の方法がいくつかあります。
+==================================+============================+
| EBML Path of new element | Status |
+==================================+============================+
| \root\level1\level2 | Ends the Unknown-Sized |
| | Element, as it is a new |
| | Parent Element |
+----------------------------------+----------------------------+
| \root\level1 | Ends the Unknown-Sized |
| | Element, as it is a new |
| | Parent Element |
+----------------------------------+----------------------------+
| \root | Ends the Unknown-Sized |
| | Element, as it is a new |
| | Root Element |
+----------------------------------+----------------------------+
| \root2 | Ends the Unknown-Sized |
| | Element, as it is a new |
| | Root Element |
+----------------------------------+----------------------------+
| \root\level1\level2\other | Ends the Unknown-Sized |
| | Element, as they share the |
| | same parent |
+----------------------------------+----------------------------+
| \root\level1\level2\elt | Ends the Unknown-Sized |
| | Element, as they share the |
| | same parent |
+----------------------------------+----------------------------+
| \root\level1\level2\elt\inside | Doesn't end the Unknown- |
| | Sized Element; it's a |
| | child of "elt" |
+----------------------------------+----------------------------+
| \root\level1\level2\elt\<global> | Global Element is valid; |
| | it's a child of "elt" |
+----------------------------------+----------------------------+
| \root\level1\level2\<global> | Global Element cannot be |
| | interpreted with this |
| | path; while parsing "elt", |
| | a Global Element can only |
| | be a child of "elt" |
+----------------------------------+----------------------------+
Table 5: Examples of determining the end of an Unknown-Sized Element
表5：サイズが不明な要素の終了を判断する例
For Element Data Sizes encoded at octet lengths from one to eight, Table 6 depicts the range of possible values that can be encoded as an Element Data Size. An Element Data Size with an octet length of 8 is able to express a size of 2^(56)-2 or 72,057,594,037,927,934 octets (or about 72 petabytes). The maximum possible value that can be stored as Element Data Size is referred to as VINTMAX.
1から8までのオクテット長でエンコードされたエレメントデータサイズの場合、表6は、エレメントデータサイズとしてエンコードできる可能な値の範囲を示しています。オクテット長が8の要素データサイズは、2 ^（56）-2または72,057,594,037,927,934オクテット（または約72ペタバイト）のサイズを表現できます。要素データサイズとして保存できる最大値は、VINTMAXと呼ばれます。
+==============+======================+
| Octet Length | Possible Value Range |
+==============+======================+
| 1 | 0 to 2^(7) - 2 |
+--------------+----------------------+
| 2 | 0 to 2^(14) - 2 |
+--------------+----------------------+
| 3 | 0 to 2^(21) - 2 |
+--------------+----------------------+
| 4 | 0 to 2^(28) - 2 |
+--------------+----------------------+
| 5 | 0 to 2^(35) - 2 |
+--------------+----------------------+
| 6 | 0 to 2^(42) - 2 |
+--------------+----------------------+
| 7 | 0 to 2^(49) - 2 |
+--------------+----------------------+
| 8 | 0 to 2^(56) - 2 |
+--------------+----------------------+
Table 6: Possible range of values that can be stored in VINTs, by octet length
表6：オクテット長による、VINTに格納できる値の可能な範囲
If the length of Element Data equals 2^(n*7)-1, then the octet length of the Element Data Size MUST be at least n+1. This rule prevents an Element Data Size from being expressed as the unknown-size value. Table 7 clarifies this rule by showing a valid and invalid expression of an Element Data Size with a VINT_DATA of 127 (which is equal to 2^(1*7)-1) and 16,383 (which is equal to 2^(2*7)-1).
要素データの長さが2 ^（n * 7）-1に等しい場合、要素データサイズのオクテット長は少なくともn + 1でなければなりません。このルールは、要素のデータサイズが不明なサイズの値として表現されないようにします。表7は、VINT_DATAが127（2 ^（1 * 7）-1に等しい）および16,383（2 ^（2 * 7に等しい）の要素データサイズの有効な式と無効な式を示すことにより、このルールを明確にしています。 ）-1）。
+============+=============+=======================+==============+
| VINT_WIDTH | VINT_MARKER | VINT_DATA | Element Data |
| | | | Size Status |
+============+=============+=======================+==============+
| | 1 | 1111111 | Reserved |
| | | | (meaning |
| | | | Unknown) |
+------------+-------------+-----------------------+--------------+
| 0 | 1 | 00000001111111 | Valid |
| | | | (meaning 127 |
| | | | octets) |
+------------+-------------+-----------------------+--------------+
| 00 | 1 | 000000000000001111111 | Valid |
| | | | (meaning 127 |
| | | | octets) |
+------------+-------------+-----------------------+--------------+
| 0 | 1 | 11111111111111 | Reserved |
| | | | (meaning |
| | | | Unknown) |
+------------+-------------+-----------------------+--------------+
| 00 | 1 | 000000011111111111111 | Valid |
| | | | (16,383 |
| | | | octets) |
+------------+-------------+-----------------------+--------------+
Table 7: Demonstration of VINT_DATA reservation for VINTs of unknown size
表7：サイズが不明なVINTのVINT_DATA予約のデモンストレーション
EBML Elements are defined by an EBML Schema (see Section 11.1), which MUST declare one of the following EBML Element Types for each EBML Element. An EBML Element Type defines a concept of storing data within an EBML Element that describes such characteristics as length, endianness, and definition.
EBML要素はEBMLスキーマ（セクション11.1を参照）によって定義され、EBML要素ごとに次のEBML要素タイプの1つを宣言する必要があります。 EBML要素タイプは、長さ、エンディアン、定義などの特性を記述するEBML要素内にデータを格納するという概念を定義します。
EBML Elements that are defined as a Signed Integer Element, Unsigned Integer Element, Float Element, or Date Element use big-endian storage.
符号付き整数要素、符号なし整数要素、浮動要素、または日付要素として定義されているEBML要素は、ビッグエンディアンストレージを使用します。
A Signed Integer Element MUST declare a length from zero to eight octets. If the EBML Element is not defined to have a default value, then a Signed Integer Element with a zero-octet length represents an integer value of zero.
符号付き整数要素は、0から8オクテットの長さを宣言しなければなりません。 EBML要素がデフォルト値を持つように定義されていない場合、長さが0オクテットの符号付き整数要素は、整数値0を表します。
A Signed Integer Element stores an integer (meaning that it can be written without a fractional component) that could be negative, positive, or zero. Signed Integers are stored with two's complement notation with the leftmost bit being the sign bit. Because EBML limits Signed Integers to 8 octets in length, a Signed Integer Element stores a number from -9,223,372,036,854,775,808 to +9,223,372,036,854,775,807.
符号付き整数要素は、負、正、またはゼロの整数（小数コンポーネントなしで書き込むことができることを意味します）を格納します。符号付き整数は、左端のビットが符号ビットである2の補数表記で格納されます。 EBMLは符号付き整数を8オクテットに制限しているため、符号付き整数要素は-9,223,372,036,854,775,808から+9,223,372,036,854,775,807までの数値を格納します。
An Unsigned Integer Element MUST declare a length from zero to eight octets. If the EBML Element is not defined to have a default value, then an Unsigned Integer Element with a zero-octet length represents an integer value of zero.
符号なし整数要素は、0〜8オクテットの長さを宣言する必要があります。 EBML要素がデフォルト値を持つように定義されていない場合、オクテット長が0の符号なし整数要素は、整数値0を表します。
An Unsigned Integer Element stores an integer (meaning that it can be written without a fractional component) that could be positive or zero. Because EBML limits Unsigned Integers to 8 octets in length, an Unsigned Integer Element stores a number from 0 to 18,446,744,073,709,551,615.
符号なし整数要素は、正またはゼロの整数（小数コンポーネントなしで書き込むことができることを意味します）を格納します。 EBMLは符号なし整数を8オクテットに制限しているため、符号なし整数要素は0から18,446,744,073,709,551,615までの数値を格納します。
A Float Element MUST declare a length of either zero octets (0 bit), four octets (32 bit), or eight octets (64 bit). If the EBML Element is not defined to have a default value, then a Float Element with a zero-octet length represents a numerical value of zero.
Float Elementは、0オクテット（0ビット）、4オクテット（32ビット）、または8オクテット（64ビット）の長さを宣言しなければなりません（MUST）。 EBML要素がデフォルト値を持つように定義されていない場合、オクテット長が0のFloat要素は数値0を表します。
A Float Element stores a floating-point number in the 32-bit and 64-bit binary interchange format, as defined in [IEEE.754].
浮動小数点要素は、[IEEE.754]で定義されているように、32ビットおよび64ビットのバイナリ交換形式で浮動小数点数を格納します。
A String Element MUST declare a length in octets from zero to VINTMAX. If the EBML Element is not defined to have a default value, then a String Element with a zero-octet length represents an empty string.
文字列要素は、0からVINTMAXまでの長さをオクテットで宣言する必要があります。 EBML要素がデフォルト値を持つように定義されていない場合、長さ0オクテットの文字列要素は空の文字列を表します。
A String Element MUST either be empty (zero-length) or contain printable ASCII characters [RFC0020] in the range of 0x20 to 0x7E, with an exception made for termination (see Section 13).
文字列要素は空（長さがゼロ）であるか、印刷可能なASCII文字[RFC0020]を0x20から0x7Eの範囲で含んでいる必要があります（ただし、終了の場合は例外です（セクション13を参照）。
A UTF-8 Element MUST declare a length in octets from zero to VINTMAX. If the EBML Element is not defined to have a default value, then a UTF-8 Element with a zero-octet length represents an empty string.
UTF-8要素は、長さをオクテットで0からVINTMAXまで宣言する必要があります。 EBML要素がデフォルト値を持つように定義されていない場合、長さ0オクテットのUTF-8要素は空の文字列を表します。
A UTF-8 Element contains only a valid Unicode string as defined in [RFC3629], with an exception made for termination (see Section 13).
UTF-8要素には、[RFC3629]で定義されている有効なUnicode文字列のみが含まれますが、終了については例外があります（セクション13を参照）。
A Date Element MUST declare a length of either zero octets or eight octets. If the EBML Element is not defined to have a default value, then a Date Element with a zero-octet length represents a timestamp of 2001-01-01T00:00:00.000000000 UTC [RFC3339].
日付要素は、0オクテットまたは8オクテットの長さを宣言する必要があります。 EBML要素がデフォルト値を持つように定義されていない場合、長さゼロのオクテットの日付要素は、2001-01-01T00：00：00.000000000 UTC [RFC3339]のタイムスタンプを表します。
The Date Element stores an integer in the same format as the Signed Integer Element that expresses a point in time referenced in nanoseconds from the precise beginning of the third millennium of the Gregorian Calendar in Coordinated Universal Time (also known as 2001-01-01T00:00:00.000000000 UTC). This provides a possible expression of time from 1708-09-11T00:12:44.854775808 UTC to 2293-04-11T11:47:16.854775807 UTC.
日付要素は、符号付き整数要素と同じ形式で整数を格納します。これは、協定世界時（2001-01-01T00とも呼ばれる）でのグレゴリオ暦の3千年目の正確な開始からのナノ秒で参照される時点を表します。 00：00.000000000 UTC）。これは、1708-09-11T00：12：44.854775808 UTCから2293-04-11T11：47：16.854775807 UTCまでの時間の可能な表現を提供します。
A Master Element MUST declare a length in octets from zero to VINTMAX or be of unknown length. See Section 6 for rules that apply to elements of unknown length.
マスター要素は、0からVINTMAXまでのオクテットの長さを宣言するか、不明な長さでなければなりません。長さが不明な要素に適用される規則については、セクション6を参照してください。
The Master Element contains zero or more other elements. EBML Elements contained within a Master Element MUST have the EBMLParentPath of their Element Path equal to the EBMLFullPath of the Master Element Element Path (see Section 11.1.6.2). Element Data stored within Master Elements SHOULD only consist of EBML Elements and SHOULD NOT contain any data that is not part of an EBML Element. The EBML Schema identifies what Element IDs are valid within the Master Elements for that version of the EBML Document Type. Any data contained within a Master Element that is not part of a Child Element MUST be ignored.
マスター要素には、0個以上の他の要素が含まれています。マスターエレメント内に含まれるEBMLエレメントは、エレメントパスのEBMLParentPathがマスターエレメントエレメントパスのEBMLFullPathと等しい必要があります（セクション11.1.6.2を参照）。マスター要素内に格納された要素データは、EBML要素のみで構成されるべきであり（SHOULD）、EBML要素の一部ではないデータを含んでいてはなりません（SHOULD NOT）。 EBMLスキーマは、そのバージョンのEBMLドキュメントタイプのマスター要素内で有効な要素IDを識別します。子要素の一部ではないマスター要素内に含まれるデータはすべて無視する必要があります。
A Binary Element MUST declare a length in octets from zero to VINTMAX.
バイナリエレメントは、長さをオクテットで0からVINTMAXまで宣言する必要があります。
The contents of a Binary Element should not be interpreted by the EBML Reader.
Binary Elementのコンテンツは、EBMLリーダーによって解釈されるべきではありません。
An EBML Document is composed of only two components, an EBML Header and an EBML Body. An EBML Document MUST start with an EBML Header that declares significant characteristics of the entire EBML Body. An EBML Document consists of EBML Elements and MUST NOT contain any data that is not part of an EBML Element.
EBMLドキュメントは、EBMLヘッダーとEBML本文の2つのコンポーネントのみで構成されます。 EBMLドキュメントは、EBML本文全体の重要な特性を宣言するEBMLヘッダーで始まる必要があります。 EBMLドキュメントはEBML要素で構成され、EBML要素の一部ではないデータを含むことはできません。
The EBML Header is a declaration that provides processing instructions and identification of the EBML Body. The EBML Header of an EBML Document is analogous to the XML Declaration of an XML Document.
EBMLヘッダーは、処理命令とEBML本文の識別を提供する宣言です。 EBMLドキュメントのEBMLヘッダーは、XMLドキュメントのXML宣言に類似しています。
The EBML Header documents the EBML Schema (also known as the EBML DocType) that is used to semantically interpret the structure and meaning of the EBML Document. Additionally, the EBML Header documents the versions of both EBML and the EBML Schema that were used to write the EBML Document and the versions required to read the EBML Document.
EBMLヘッダーは、EBMLドキュメントの構造と意味を意味的に解釈するために使用されるEBMLスキーマ（EBML DocTypeとも呼ばれます）を文書化します。さらに、EBMLヘッダーには、EBMLドキュメントの書き込みに使用されたEBMLとEBMLスキーマの両方のバージョンと、EBMLドキュメントの読み取りに必要なバージョンが記載されています。
The EBML Header MUST contain a single Master Element with an Element Name of "EBML" and Element ID of "0x1A45DFA3" (see Section 11.2.1); the Master Element may have any number of additional EBML Elements within it. The EBML Header of an EBML Document that uses an EBMLVersion of 1 MUST only contain EBML Elements that are defined as part of this document.
EBMLヘッダーには、「EBML」の要素名と「0x1A45DFA3」の要素IDを持つ単一のマスター要素が含まれている必要があります（セクション11.2.1を参照）。マスター要素には、追加のEBML要素をいくつでも含めることができます。 1のEBMLバージョンを使用するEBMLドキュメントのEBMLヘッダーには、このドキュメントの一部として定義されているEBML要素のみを含める必要があります。
Elements within an EBML Header can be at most 4 octets long, except for the EBML Element with Element Name "EBML" and Element ID "0x1A45DFA3" (see Section 11.2.1); this Element can be up to 8 octets long.
EBMLヘッダー内の要素は、要素名が「EBML」で要素IDが「0x1A45DFA3」のEBML要素を除いて、最大4オクテットの長さにすることができます（セクション11.2.1を参照）。この要素は最大8オクテットの長さにすることができます。
All data of an EBML Document following the EBML Header is the EBML Body. The end of the EBML Body, as well as the end of the EBML Document that contains the EBML Body, is reached at whichever comes first: the beginning of a new EBML Header at the Root Level or the end of the file. This document defines precisely which EBML Elements are to be used within the EBML Header but does not name or define which EBML Elements are to be used within the EBML Body. The definition of which EBML Elements are to be used within the EBML Body is defined by an EBML Schema.
EBMLヘッダーに続くEBMLドキュメントのすべてのデータは、EBML本文です。 EBMLボディの終わり、およびEBMLボディを含むEBMLドキュメントの終わりは、ルートレベルでの新しいEBMLヘッダーの始まりまたはファイルの終わりのいずれか早い方に到達します。このドキュメントは、EBMLヘッダー内で使用されるEBML要素を正確に定義しますが、EBML本体内で使用されるEBML要素を指定または定義しません。 EBMLボディ内で使用されるEBML要素の定義は、EBMLスキーマによって定義されます。
Within the EBML Body, the maximum octet length allowed for any Element ID is set by the EBMLMaxIDLength Element of the EBML Header, and the maximum octet length allowed for any Element Data Size is set by the EBMLMaxSizeLength Element of the EBML Header.
EBMLボディ内で、任意の要素IDに許可される最大オクテット長は、EBMLヘッダーのEBMLMaxIDLength要素によって設定され、任意の要素データサイズに許可される最大オクテット長は、EBMLヘッダーのEBMLMaxSizeLength要素によって設定されます。
An EBML Stream is a file that consists of one or more EBML Documents that are concatenated together. An occurrence of an EBML Header at the Root Level marks the beginning of an EBML Document.
EBMLストリームは、連結された1つ以上のEBMLドキュメントで構成されるファイルです。ルートレベルでのEBMLヘッダーの出現は、EBMLドキュメントの開始を示します。
An EBML Document handles 2 different versions: the version of the EBML Header and the version of the EBML Body. Both versions are meant to be backward compatible.
EBMLドキュメントは、EBMLヘッダーのバージョンとEBMLボディのバージョンの2つの異なるバージョンを処理します。どちらのバージョンも、下位互換性を保つためのものです。
The version of the EBML Header is found in EBMLVersion. An EBML parser can read an EBML Header if it can read either the EBMLVersion version or a version equal or higher than the one found in EBMLReadVersion.
EBMLヘッダーのバージョンはEBMLVersionにあります。 EBMLパーサーは、EBMLバージョン、またはEBMLReadVersionにあるバージョン以上のバージョンのいずれかを読み取ることができる場合、EBMLヘッダーを読み取ることができます。
The version of the EBML Body is found in EBMLDocTypeVersion. A parser for the particular DocType format can read the EBML Document if it can read either the EBMLDocTypeVersion version of that format or a version equal or higher than the one found in EBMLDocTypeReadVersion.
EBMLボディのバージョンはEBMLDocTypeVersionにあります。特定のDocType形式のパーサーは、その形式のEBMLDocTypeVersionバージョン、またはEBMLDocTypeReadVersionにあるバージョン以上のバージョンのいずれかを読み取ることができる場合、EBMLドキュメントを読み取ることができます。
An EBML Schema is a well-formed XML Document [XML] that defines the properties, arrangement, and usage of EBML Elements that compose a specific EBML Document Type. The relationship of an EBML Schema to an EBML Document is analogous to the relationship of an XML Schema [XML-SCHEMA] to an XML Document [XML]. An EBML Schema MUST be clearly associated with one or more EBML Document Types. An EBML Document Type is identified by a string stored within the EBML Header in the DocType Element -- for example, Matroska or WebM (see Section 11.2.6). The DocType value for an EBML Document Type MUST be unique, persistent, and described in the IANA registry (see Section 17.2).
EBMLスキーマは、特定のEBMLドキュメントタイプを構成するEBML要素のプロパティ、配置、および使用法を定義する整形式のXMLドキュメント[XML]です。 EBMLスキーマとEBMLドキュメントの関係は、XMLスキーマ[XML-SCHEMA]とXMLドキュメント[XML]の関係に似ています。 EBMLスキーマは、1つ以上のEBMLドキュメントタイプに明確に関連付けられている必要があります。 EBMLドキュメントタイプは、DocType要素のEBMLヘッダー内に格納されている文字列（MatroskaやWebMなど）によって識別されます（セクション11.2.6を参照）。 EBMLドキュメントタイプのDocType値は一意で永続的である必要があり、IANAレジストリに記述されている必要があります（セクション17.2を参照）。
An EBML Schema MUST declare exactly one EBML Element at Root Level (referred to as the Root Element) that occurs exactly once within an EBML Document. The Void Element MAY also occur at Root Level but is not a Root Element (see Section 11.3.2).
EBMLスキーマは、EBMLドキュメント内で1回だけ発生するルートレベルで1つのEBML要素（ルート要素と呼ばれる）を宣言する必要があります。 Void要素はルートレベルでも発生する場合がありますが、ルート要素ではありません（セクション11.3.2を参照）。
The EBML Schema MUST document all Elements of the EBML Body. The EBML Schema does not document Global Elements that are defined by this document (namely, the Void Element and the CRC-32 Element).
EBMLスキーマは、EBML本文のすべての要素を文書化する必要があります。 EBMLスキーマは、このドキュメントで定義されているグローバル要素（つまり、Void要素とCRC-32要素）を文書化していません。
The EBML Schema MUST NOT use the Element ID "0x1A45DFA3", which is reserved for the EBML Header for the purpose of resynchronization.
EBMLスキーマは、再同期の目的でEBMLヘッダー用に予約されている要素ID「0x1A45DFA3」を使用してはなりません（MUST NOT）。
An EBML Schema MAY constrain the use of EBML Header Elements (see Section 11.2) by adding or constraining that Element's "range" attribute. For example, an EBML Schema MAY constrain the EBMLMaxSizeLength to a maximum value of "8" or MAY constrain the EBMLVersion to only support a value of "1". If an EBML Schema adopts the EBML Header Element as is, then it is not required to document that Element within the EBML Schema. If an EBML Schema constrains the range of an EBML Header Element, then that Element MUST be documented within an "<element>" node of the EBML Schema. This document provides an example of an EBML Schema; see Section 11.1.1.
EBMLスキーマは、その要素の「範囲」属性を追加または制約することにより、EBMLヘッダー要素（セクション11.2を参照）の使用を制約する場合があります。たとえば、EBMLスキーマは、EBMLMaxSizeLengthを「8」の最大値に制約してもよいし、EBMLVersionが「1」の値のみをサポートするように制約してもよい（MAY）。 EBMLスキーマがEBMLヘッダー要素をそのまま採用する場合、その要素をEBMLスキーマ内に文書化する必要はありません。 EBMLスキーマがEBMLヘッダー要素の範囲を制約する場合、その要素はEBMLスキーマの「<element>」ノード内にドキュメント化する必要があります。このドキュメントは、EBMLスキーマの例を提供します。セクション11.1.1を参照してください。
<?xml version="1.0" encoding="utf-8"?>
<EBMLSchema xmlns="urn:ietf:rfc:8794"
docType="files-in-ebml-demo" version="1">
<!-- constraints to the range of two EBML Header Elements -->
<element name="EBMLReadVersion" path="\EBML\EBMLReadVersion"
id="0x42F7" minOccurs="1" maxOccurs="1" range="1" default="1"
type="uinteger"/>
<element name="EBMLMaxSizeLength"
path="\EBML\EBMLMaxSizeLength" id="0x42F3" minOccurs="1"
maxOccurs="1" range="8" default="8" type="uinteger"/>
<!-- Root Element-->
<element name="Files" path="\Files" id="0x1946696C"
type="master">
<documentation lang="en"
purpose="definition">Container of data and
attributes representing one or many files.</documentation>
</element>
<element name="File" path="\Files\File" id="0x6146"
type="master" minOccurs="1">
<documentation lang="en" purpose="definition">
An attached file.
</documentation>
</element>
<element name="FileName" path="\Files\File\FileName"
id="0x614E" type="utf-8"
minOccurs="1">
<documentation lang="en" purpose="definition">
Filename of the attached file.
</documentation>
</element>
<element name="MimeType" path="\Files\File\MimeType"
id="0x464D" type="string"
minOccurs="1">
<documentation lang="en" purpose="definition">
MIME type of the file.
</documentation>
</element>
<element name="ModificationTimestamp"
path="\Files\File\ModificationTimestamp" id="0x4654"
type="date" minOccurs="1">
<documentation lang="en" purpose="definition">
Modification timestamp of the file.
</documentation>
</element>
<element name="Data" path="\Files\File\Data" id="0x4664"
type="binary" minOccurs="1">
<documentation lang="en" purpose="definition">
The data of the file.
</documentation>
</element>
</EBMLSchema>
Within an EBML Schema, the XPath [XPath] of the "<EBMLSchema>" element is "/EBMLSchema".
EBMLスキーマ内では、「<EBMLSchema>」要素のXPath [XPath]は「/ EBMLSchema」です。
When used as an XML Document, the EBML Schema MUST use "<EBMLSchema>" as the top-level element. The "<EBMLSchema>" element can contain "<element>" subelements.
XMLドキュメントとして使用する場合、EBMLスキーマは「<EBMLSchema>」を最上位要素として使用する必要があります。 「<EBMLSchema>」要素には、「<element>」サブ要素を含めることができます。
The namespace URI for elements of the EBML Schema is a URN as defined by [RFC8141] that uses the namespace identifier 'ietf' defined by [RFC2648] and extended by [RFC3688]. This URN is "urn:ietf:rfc:8794".
EBMLスキーマの要素の名前空間URIは、[RFC2648]で定義され、[RFC3688]で拡張された名前空間識別子 'ietf'を使用する[RFC8141]で定義されたURNです。このURNは「urn：ietf：rfc：8794」です。
Within an EBML Schema, the "<EBMLSchema>" element uses the following attributes to define an EBML Element:
EBMLスキーマ内で、「<EBMLSchema>」要素は次の属性を使用してEBML要素を定義します。
Within an EBML Schema, the XPath of the "@docType" attribute is "/EBMLSchema/@docType".
EBMLスキーマ内では、「@ docType」属性のXPathは「/ EBMLSchema / @ docType」です。
The docType lists the official name of the EBML Document Type that is defined by the EBML Schema; for example, "<EBMLSchema docType="matroska">".
docTypeは、EBMLスキーマによって定義されたEBMLドキュメントタイプの正式名をリストします。たとえば、「<EBMLSchema docType = "matroska">」です。
The "docType" attribute is REQUIRED within the "<EBMLSchema>" Element.
「docType」属性は、「<EBMLSchema>」要素内で必須です。
Within an EBML Schema, the XPath of the "@version" attribute is "/EBMLSchema/@version".
EBMLスキーマ内では、「@ version」属性のXPathは「/ EBMLSchema / @ version」です。
The version lists a nonnegative integer that specifies the version of the docType documented by the EBML Schema. Unlike XML Schemas, an EBML Schema documents all versions of a docType's definition rather than using separate EBML Schemas for each version of a docType. EBML Elements may be introduced and deprecated by using the "minver" and "maxver" attributes of "<element>".
バージョンには、EBMLスキーマによって文書化されたdocTypeのバージョンを指定する負でない整数がリストされます。 XMLスキーマとは異なり、EBMLスキーマは、docTypeのバージョンごとに別々のEBMLスキーマを使用するのではなく、docTypeの定義のすべてのバージョンを文書化します。 EBML要素は、「<element>」の「minver」および「maxver」属性を使用することによって導入および非推奨にすることができます。
The "version" attribute is REQUIRED within the "<EBMLSchema>" Element.
「<EBMLSchema>」要素内で「バージョン」属性が必須です。
Within an EBML Schema, the XPath of the "@ebml" attribute is "/EBMLSchema/@ebml".
EBMLスキーマ内では、「@ ebml」属性のXPathは「/ EBMLSchema / @ ebml」です。
The "ebml" attribute is a positive integer that specifies the version of the EBML Header (see Section 11.2.2) used by the EBML Schema. If the attribute is omitted, the EBML Header version is 1.
「ebml」属性は、EBMLスキーマで使用されるEBMLヘッダー（セクション11.2.2を参照）のバージョンを指定する正の整数です。属性が省略されている場合、EBMLヘッダーのバージョンは1です。
Within an EBML Schema, the XPath of the "<element>" element is "/EBMLSchema/element".
EBMLスキーマ内では、「<element>」要素のXPathは「/ EBMLSchema / element」です。
Each "<element>" defines one EBML Element through the use of several attributes that are defined in Section 11.1.6. EBML Schemas MAY contain additional attributes to extend the semantics but MUST NOT conflict with the definitions of the "<element>" attributes defined within this document.
各「<element>」は、セクション11.1.6で定義されているいくつかの属性を使用して1つのEBML要素を定義します。 EBMLスキーマには、セマンティクスを拡張するための追加の属性が含まれる場合がありますが、このドキュメント内で定義されている「<element>」属性の定義と競合してはなりません。
The "<element>" nodes contain a description of the meaning and use of the EBML Element stored within one or more "<documentation>" subelements, followed by optional "<implementation_note>" subelements, followed by zero or one "<restriction>" subelement, followed by optional "<extension>" subelements. All "<element>" nodes MUST be subelements of the "<EBMLSchema>".
「<element>」ノードには、1つ以上の「<documentation>」サブエレメント内に格納されているEBMLエレメントの意味と使用法の説明が含まれ、その後にオプションの「<implementation_note>」サブエレメントが続き、その後にゼロまたは1つの「<restriction>」が続きます。 "サブ要素の後に、オプションの" <extension> "サブ要素が続きます。すべての「<element>」ノードは、「<EBMLSchema>」のサブエレメントである必要があります。
Within an EBML Schema, the "<element>" uses the following attributes to define an EBML Element:
EBMLスキーマ内では、「<element>」は次の属性を使用してEBML要素を定義します。
Within an EBML Schema, the XPath of the "@name" attribute is "/EBMLSchema/element/@name".
EBMLスキーマ内では、「@ name」属性のXPathは「/ EBMLSchema / element / @ name」です。
The name provides the human-readable name of the EBML Element. The value of the name MUST be in the form of characters "A" to "Z", "a" to "z", "0" to "9", "-", and ".". The first character of the name MUST be in the form of an "A" to "Z", "a" to "z", or "0" to "9" character.
名前は、EBML要素の人間が読める名前を提供します。名前の値は、文字「A」から「Z」、「a」から「z」、「0」から「9」、「-」、および「。」の形式にする必要があります。名前の最初の文字は、「A」から「Z」、「a」から「z」、または「0」から「9」の形式でなければなりません。
The "name" attribute is REQUIRED.
「name」属性は必須です。
Within an EBML Schema, the XPath of the "@path" attribute is "/EBMLSchema/element/@path".
EBMLスキーマ内では、「@ path」属性のXPathは「/ EBMLSchema / element / @ path」です。
The path defines the allowed storage locations of the EBML Element within an EBML Document. This path MUST be defined with the full hierarchy of EBML Elements separated with a "\". The top EBML Element in the path hierarchy is the first in the value. The syntax of the "path" attribute is defined using this Augmented Backus-Naur Form (ABNF) [RFC5234] with the case-sensitive update [RFC7405] notation:
パスは、EBMLドキュメント内のEBML要素の許可される保存場所を定義します。このパスは、「\」で区切られたEBML要素の完全な階層で定義する必要があります。パス階層の最上位のEBML要素は、値の最初です。 「パス」属性の構文は、大文字と小文字が区別される更新[RFC7405]表記を伴うこの拡張バッカスナウアフォーム（ABNF）[RFC5234]を使用して定義されます。
The "path" attribute is REQUIRED.
「パス」属性は必須です。
EBMLFullPath = EBMLParentPath EBMLElement
EBMLFullPath = EBMLParentPath EBMLElement
EBMLParentPath = PathDelimiter [EBMLParents]
EBMLParentPath = PathDelimiter [EBMLParents]
EBMLParents = 0*IntermediatePathAtom EBMLLastParent
IntermediatePathAtom = EBMLPathAtom / GlobalPlaceholder
EBMLLastParent = EBMLPathAtom / GlobalPlaceholder
EBMLPathAtom = [IsRecursive] EBMLAtomName PathDelimiter
EBMLElement = [IsRecursive] EBMLAtomName
PathDelimiter = "\"
IsRecursive = "+"
EBMLAtomName = ALPHA / DIGIT 0*EBMLNameChar
EBMLNameChar = ALPHA / DIGIT / "-" / "."
GlobalPlaceholder = "(" GlobalParentOccurrence "\)"
GlobalParentOccurrence = [PathMinOccurrence] "-" [PathMaxOccurrence]
PathMinOccurrence = 1*DIGIT ; no upper limit
PathMaxOccurrence = 1*DIGIT ; no upper limit
The "*", "(", and ")" symbols are interpreted as defined in [RFC5234].
「*」、「（」、および「）」記号は、[RFC5234]で定義されているように解釈されます。
The EBMLAtomName of the EBMLElement part MUST be equal to the "@name" attribute of the EBML Schema. If the EBMLElement part contains an IsRecursive part, the EBML Element can occur within itself recursively (see Section 11.1.6.11).
EBMLElementパーツのEBMLAtomNameは、EBMLスキーマの「@name」属性と等しい必要があります。 EBMLElement部分にIsRecursive部分が含まれている場合、EBML要素自体が再帰的に発生する可能性があります（セクション11.1.6.11を参照）。
The starting PathDelimiter of EBMLParentPath corresponds to the root of the EBML Document.
EBMLParentPathの最初のPathDelimiterは、EBMLドキュメントのルートに対応します。
The "@path" value MUST be unique within the EBML Schema. The "@id" value corresponding to this "@path" MUST NOT be defined for use within another EBML Element with the same EBMLParentPath as this "@path".
「@path」値は、EBMLスキーマ内で一意である必要があります。この「@path」に対応する「@id」値は、この「@path」と同じEBMLParentPathを持つ別のEBML要素内で使用するために定義してはなりません。
A path with a GlobalPlaceholder as the EBMLLastParent defines a Global Element; see Section 11.3. If the element has no EBMLLastParent part, or the EBMLLastParent part is not a GlobalPlaceholder, then the Element is not a Global Element.
EBMLLastParentがGlobalPlaceholderであるパスは、グローバル要素を定義します。セクション11.3を参照してください。要素にEBMLLastParent部分がない場合、またはEBMLLastParent部分がGlobalPlaceholderでない場合、その要素はグローバル要素ではありません。
The GlobalParentOccurrence part is interpreted as the number of valid EBMLPathAtom parts that can replace the GlobalPlaceholder in the path. PathMinOccurrence represents the minimum number of EBMLPathAtoms required to replace the GlobalPlaceholder. PathMaxOccurrence represents the maximum number of EBMLPathAtoms possible to replace the GlobalPlaceholder.
GlobalParentOccurrenceパーツは、パス内のGlobalPlaceholderを置き換えることができる有効なEBMLPathAtomパーツの数として解釈されます。 PathMinOccurrenceは、GlobalPlaceholderを置き換えるために必要なEBMLPathAtomの最小数を表します。 PathMaxOccurrenceは、GlobalPlaceholderを置き換えることができるEBMLPathAtomの最大数を表します。
If PathMinOccurrence is not present, then that GlobalParentOccurrence has a PathMinOccurrence value of 0. If PathMaxOccurrence is not present, then there is no upper bound for the permitted number of EBMLPathAtoms possible to replace the GlobalPlaceholder. PathMaxOccurrence MUST NOT have the value 0, as it would mean no EBMLPathAtom can replace the GlobalPlaceholder, and the EBMLFullPath would be the same without that GlobalPlaceholder part. PathMaxOccurrence MUST be bigger than, or equal to, PathMinOccurrence.
PathMinOccurrenceが存在しない場合、そのGlobalParentOccurrenceのPathMinOccurrence値は0になります。PathMaxOccurrenceが存在しない場合、GlobalPlaceholderを置き換えることができるEBMLPathAtomの許容数に上限はありません。 PathMaxOccurrenceの値を0にすることはできません。これは、EBMLPathAtomがGlobalPlaceholderを置き換えることができず、EBMLFullPathがそのGlobalPlaceholderパーツなしで同じになるためです。 PathMaxOccurrenceは、PathMinOccurrence以上である必要があります。
For example, in "\a\(0-1\)global", the Element path "\a\x\global" corresponds to an EBMLPathAtom occurrence of 1. The Element "\a\x\y\global" corresponds to an EBMLPathAtom occurrence of 2, etc. In those cases, "\a\x" or "\a\x\y" MUST be valid paths to be able to contain the element "global".
たとえば、「\ a \（0-1 \）global」では、エレメントパス「\ a \ x \ global」は、EBMLPathAtomの1回の出現に対応します。エレメント「\ a \ x \ y \ global」は、 EBMLPathAtomオカレンス2など。これらの場合、「\ a \ x」または「\ a \ x \ y」は、要素「global」を含むことができる有効なパスでなければなりません。
Consider another EBML Path, "\a\(1-\)global". There has to be at least one EBMLPathAtom between the "\a\" part and "global". So the "global" EBML Element cannot be found inside the "\a" EBML Element, as it means the resulting path "\a\global" has no EBMLPathAtom between the "\a\" and "global". However, the "global" EBML Element can be found inside the "\a\b" EBML Element, because the resulting path, "\a\b\global", has one EBMLPathAtom between the "\a\" and "global". Alternatively, it can be found inside the "\a\b\c" EBML Element (two EBMLPathAtom), or inside the "\a\b\c\d" EBML Element (three EBMLPathAtom), etc.
別のEBMLパス、「\ a \（1-\）global」を検討してください。 「\ a \」部分と「グローバル」の間に少なくとも1つのEBMLPathAtomが必要です。したがって、「\ a」EBMLエレメント内に「グローバル」EBMLエレメントが見つかりません。これは、結果のパス「\ a \ global」に「\ a \」と「グローバル」の間にEBMLPathAtomがないことを意味するためです。ただし、「グローバル」EBML要素は「\ a \ b」EBML要素内にあります。これは、結果のパス「\ a \ b \ global」が「\ a \」と「グローバル」の間に1つのEBMLPathAtomを持つためです。 。または、 "\ a \ b \ c" EBML要素（2つのEBMLPathAtom）内、または "\ a \ b \ c \ d" EBML要素（3つのEBMLPathAtom）内などにあります。
Consider another EBML Path, "\a\(0-1\)global". There has to be at most one EBMLPathAtom between the "\a\" part and "global". So the "global" EBML Element can be found inside either the "\a" EBML Element (0 EBMLPathAtom replacing GlobalPlaceholder) or the "\a\b" EBML Element (one replacement EBMLPathAtom). But it cannot be found inside the "\a\b\c" EBML Element, because the resulting path, "\a\b\c\global", has two EBMLPathAtom between "\a\" and "global".
別のEBMLパス、「\ a \（0-1 \）global」を検討してください。 「\ a \」部分と「グローバル」の間には最大で1つのEBMLPathAtomが必要です。そのため、「グローバル」EBML要素は、「\ a」EBML要素（GlobalPlaceholderを置き換えるEBMLPathAtom）または「\ a \ b」EBML要素（1つの置換EBMLPathAtom）内にあります。ただし、結果のパス「\ a \ b \ c \ global」には「\ a \」と「global」の間に2つのEBMLPathAtomがあるため、「\ a \ b \ c」EBML要素内では見つかりません。
Within an EBML Schema, the XPath of the "@id" attribute is "/EBMLSchema/element/@id".
EBMLスキーマ内では、「@ id」属性のXPathは「/ EBMLSchema / element / @ id」です。
The Element ID is encoded as a Variable-Size Integer. It is read and stored in big-endian order. In the EBML Schema, it is expressed in hexadecimal notation prefixed by a 0x. To reduce the risk of false positives while parsing EBML Streams, the Element IDs of the Root Element and Top-Level Elements SHOULD be at least 4 octets in length. Element IDs defined for use at Root Level or directly under the Root Level MAY use shorter octet lengths to facilitate padding and optimize edits to EBML Documents; for instance, the Void Element uses an Element ID with a length of one octet to allow its usage in more writing and editing scenarios.
要素IDは可変サイズの整数としてエンコードされます。ビッグエンディアンの順序で読み込まれ、保存されます。 EBMLスキーマでは、接頭辞0xが付いた16進表記で表されます。 EBMLストリームを解析する際の誤検知のリスクを軽減するために、ルート要素と最上位要素の要素IDは、少なくとも4オクテットの長さである必要があります。ルートレベルまたはルートレベルの直下で使用するために定義された要素IDは、より短いオクテット長を使用して、パディングを容易にし、EBMLドキュメントへの編集を最適化できます。たとえば、Void要素は、1オクテットの長さの要素IDを使用して、より多くの書き込みおよび編集シナリオでの使用を可能にします。
The Element ID of any Element found within an EBML Document MUST only match a single "@path" value of its corresponding EBML Schema, but a separate instance of that Element ID value defined by the EBML Schema MAY occur within a different "@path". If more than one Element is defined to use the same "@id" value, then the "@path" values of those Elements MUST NOT share the same EBMLParentPath. Elements MUST NOT be defined to use the same "@id" value if one of their common Parent Elements could be an Unknown-Sized Element.
EBMLドキュメント内で見つかった要素の要素IDは、対応するEBMLスキーマの単一の "@path"値とのみ一致する必要がありますが、EBMLスキーマによって定義されたその要素ID値の個別のインスタンスは、異なる "@path"内で発生する場合があります。同じ "@id"値を使用するように複数の要素が定義されている場合、それらの要素の "@path"値は同じEBMLParentPathを共有してはなりません（MUST NOT）。共通の親要素の1つがサイズ不明の要素である可能性がある場合、要素は同じ "@id"値を使用するように定義してはなりません（MUST NOT）。
The "id" attribute is REQUIRED.
「id」属性は必須です。
Within an EBML Schema, the XPath of the "@minOccurs" attribute is "/EBMLSchema/element/@minOccurs".
EBMLスキーマ内では、「@ minOccurs」属性のXPathは「/ EBMLSchema / element / @ minOccurs」です。
"minOccurs" is a nonnegative integer expressing the minimum permitted number of occurrences of this EBML Element within its Parent Element.
「minOccurs」は、親要素内でのこのEBML要素の最小許容出現回数を表す非負の整数です。
Each instance of the Parent Element MUST contain at least this many instances of this EBML Element. If the EBML Element has an empty EBMLParentPath, then "minOccurs" refers to constraints on the occurrence of the EBML Element within the EBML Document. EBML Elements with "minOccurs" set to "1" that also have a default value (see Section 11.1.6.8) declared are not REQUIRED to be stored but are REQUIRED to be interpreted; see Section 11.1.19.
親要素の各インスタンスには、少なくともこのEBML要素のこれだけ多くのインスタンスが含まれている必要があります。 EBML要素に空のEBMLParentPathがある場合、「minOccurs」は、EBMLドキュメント内のEBML要素の出現に対する制約を参照します。 「minOccurs」が「1」に設定され、デフォルト値（セクション11.1.6.8を参照）も宣言されているEBML要素は、格納する必要はありませんが、解釈する必要があります。セクション11.1.19を参照してください。
An EBML Element defined with a "minOccurs" value greater than zero is called a Mandatory EBML Element.
ゼロより大きい「minOccurs」値で定義されたEBML要素は、必須EBML要素と呼ばれます。
The "minOccurs" attribute is OPTIONAL. If the "minOccurs" attribute is not present, then that EBML Element has a "minOccurs" value of 0.
「minOccurs」属性はオプションです。 「minOccurs」属性が存在しない場合、そのEBML要素の「minOccurs」値は0です。
The semantic meaning of "minOccurs" within an EBML Schema is analogous to the meaning of "minOccurs" within an XML Schema.
EBMLスキーマ内の「minOccurs」の意味上の意味は、XMLスキーマ内の「minOccurs」の意味に類似しています。
Within an EBML Schema, the XPath of the "@maxOccurs" attribute is "/EBMLSchema/element/@maxOccurs".
EBMLスキーマ内では、「@ maxOccurs」属性のXPathは「/ EBMLSchema / element / @ maxOccurs」です。
"maxOccurs" is a nonnegative integer expressing the maximum permitted number of occurrences of this EBML Element within its Parent Element.
「maxOccurs」は、親要素内でのこのEBML要素の最大許容出現回数を表す非負の整数です。
Each instance of the Parent Element MUST contain at most this many instances of this EBML Element, including the unwritten mandatory element with a default value; see Section 11.1.19. If the EBML Element has an empty EBMLParentPath, then "maxOccurs" refers to constraints on the occurrence of the EBML Element within the EBML Document.
親要素の各インスタンスには、デフォルト値を持つ未記述の必須要素を含め、最大でこのEBML要素のこれだけのインスタンスを含める必要があります。セクション11.1.19を参照してください。 EBML要素に空のEBMLParentPathがある場合、「maxOccurs」は、EBMLドキュメント内のEBML要素の出現に対する制約を参照します。
The "maxOccurs" attribute is OPTIONAL. If the "maxOccurs" attribute is not present, then there is no upper bound for the permitted number of occurrences of this EBML Element within its Parent Element or within the EBML Document, depending on whether or not the EBMLParentPath of the EBML Element is empty.
「maxOccurs」属性はオプションです。 「maxOccurs」属性が存在しない場合、EBML要素のEBMLParentPathが空であるかどうかに応じて、親要素またはEBMLドキュメント内でのこのEBML要素の許可された発生回数に上限はありません。
The semantic meaning of "maxOccurs" within an EBML Schema is analogous to the meaning of "maxOccurs" within an XML Schema; when it is not present, it's similar to xml:maxOccurs="unbounded" in an XML Schema.
EBMLスキーマ内の「maxOccurs」の意味上の意味は、XMLスキーマ内の「maxOccurs」の意味に類似しています。存在しない場合、XMLスキーマのxml：maxOccurs = "unbounded"に似ています。
Within an EBML Schema, the XPath of the "@range" attribute is "/EBMLSchema/element/@range".
EBMLスキーマ内では、「@ range」属性のXPathは「/ EBMLSchema / element / @ range」です。
A numerical range for EBML Elements that are of numerical types (Unsigned Integer, Signed Integer, Float, and Date). If specified, the value of the EBML Element MUST be within the defined range. See Section 11.1.6.6.1 for rules applied to expression of range values.
数値タイプ（符号なし整数、符号付き整数、浮動小数点、および日付）であるEBML要素の数値範囲。指定する場合、EBML要素の値は定義された範囲内でなければなりません。範囲値の表現に適用されるルールについては、セクション11.1.6.6.1を参照してください。
The "range" attribute is OPTIONAL. If the "range" attribute is not present, then any value legal for the "type" attribute is valid.
「範囲」属性はオプションです。 「範囲」属性が存在しない場合、「タイプ」属性に有効な値はすべて有効です。
The "range" attribute MUST only be used with EBML Elements that are either signed integer, unsigned integer, float, or date. The expression defines the upper, lower, exact, or excluded value of the EBML Element and optionally an upper boundary value combined with a lower boundary. The range expression may contain whitespace (using the ASCII 0x20 character) for readability, but whitespace within a range expression MUST NOT convey meaning.
「範囲」属性は、符号付き整数、符号なし整数、浮動小数点数、または日付のいずれかであるEBML要素でのみ使用する必要があります。式は、EBML要素の上限値、下限値、正確値、または除外値を定義し、オプションで上限値と下限値を組み合わせたものを定義します。範囲式には、読みやすいように（ASCII 0x20文字を使用して）空白を含めることができますが、範囲式内の空白は意味を伝えてはなりません（MUST NOT）。
To set a fixed value for the range, the value is used as the attribute value. For example, "1234" means the EBML element always has the value 1234. The value can be prefixed with "not" to indicate that the fixed value MUST NOT be used for that Element. For example, "not 1234" means the Element can use all values of its type except 1234.
範囲に固定値を設定するには、その値を属性値として使用します。たとえば、「1234」は、EBML要素の値が常に1234であることを意味します。固定値をその要素に使用してはならないことを示すために、値の前に「not」を付けることができます。たとえば、「1234以外」は、要素が1234を除くそのタイプのすべての値を使用できることを意味します。
The ">" sign is used for an exclusive lower boundary, and the ">=" sign is used for an inclusive lower boundary. For example, ">3" means the Element value MUST be greater than 3, and ">=0x1p+0" means the Element value MUST be greater than or equal to the floating value 1.0; see Section 11.1.18.
">"記号は排他的な下限に使用され、 "> ="記号は包含的な下限に使用されます。たとえば、 "> 3"は要素の値が3より大きい必要があることを意味し、 "> = 0x1p + 0"は要素の値が浮動値1.0以上でなければならないことを意味します。セクション11.1.18を参照してください。
The "<" sign is used for an exclusive upper boundary, and the "<=" sign is used for an inclusive upper boundary. For example, "<-2" means the Element value MUST be less than -2, and "<=10" means the Element value MUST be less than or equal to 10.
「<」記号は排他的な上限に使用され、「<=」記号は包括的な上限に使用されます。たとえば、「<-2」は要素の値が-2未満でなければならないことを意味し、「<= 110」は要素の値が10以下でなければならないことを意味します。
The lower and upper bounds can be combined into an expression to form a closed boundary. The lower boundary comes first, followed by the upper boundary, separated by a comma. For example, ">3,<= 20" means the Element value MUST be greater than 3 and less than or equal to 20.
下限と上限を1つの式に組み合わせて、閉じた境界を形成できます。下限が最初に来て、コンマで区切られた上限が続きます。たとえば、「> 3、<= 20」は、要素の値が3より大きく20以下でなければならないことを意味します。
A special form of lower and upper bounds using the "-" separator is possible, meaning the Element value MUST be greater than, or equal to, the first value and MUST be less than or equal to the second value. For example, "1-10" is equivalent to ">=1,<=10". If the upper boundary is negative, the "range" attribute MUST only use the latter form.
"-"セパレータを使用した下限と上限の特別な形式が可能です。つまり、要素の値は最初の値以上でなければならず、2番目の値以下でなければなりません。たとえば、「1〜10」は「> = 1、<= 10」と同等です。上限が負の場合、「範囲」属性は後者の形式のみを使用する必要があります。
Within an EBML Schema, the XPath of the "@length" attribute is "/EBMLSchema/element/@length".
EBMLスキーマ内では、「@ length」属性のXPathは「/ EBMLSchema / element / @ length」です。
The "length" attribute is a value to express the valid length of the Element Data as written, measured in octets. The length provides a constraint in addition to the Length value of the definition of the corresponding EBML Element Type. This length MUST be expressed as either a nonnegative integer or a range (see Section 11.1.6.6.1) that consists of only nonnegative integers and valid operators.
「length」属性は、オクテットで測定された、記述されたとおりの要素データの有効な長さを表す値です。長さは、対応するEBML要素タイプの定義の長さの値に加えて、制約を提供します。この長さは、非負の整数、または非負の整数と有効な演算子のみで構成される範囲（セクション11.1.6.6.1を参照）として表現する必要があります。
The "length" attribute is OPTIONAL. If the "length" attribute is not present for that EBML Element, then that EBML Element is only limited in length by the definition of the associated EBML Element Type.
「長さ」属性はオプションです。 「長さ」属性がそのEBMLエレメントに存在しない場合、そのEBMLエレメントは、関連するEBMLエレメントタイプの定義によってのみ長さが制限されます。
Within an EBML Schema, the XPath of the "@default" attribute is "/EBMLSchema/element/@default".
EBMLスキーマ内では、「@ default」属性のXPathは「/ EBMLSchema / element / @ default」です。
If an Element is mandatory (has a "minOccurs" value greater than zero) but not written within its Parent Element or stored as an Empty Element, then the EBML Reader of the EBML Document MUST semantically interpret the EBML Element as present with this specified default value for the EBML Element. An unwritten mandatory Element with a declared default value is semantically equivalent to that Element if written with the default value stored as the Element Data. EBML Elements that are Master Elements MUST NOT declare a default value. EBML Elements with a "minOccurs" value greater than 1 MUST NOT declare a default value.
要素が必須（ "minOccurs"値がゼロより大きい）であるが、その親要素内に書き込まれていない、または空の要素として格納されていない場合、EBMLドキュメントのEBMLリーダーは、EBML要素をこの指定されたデフォルトで存在すると意味的に解釈しなければならない（MUST） EBML要素の値。宣言されたデフォルト値を持つ未記述の必須要素は、要素データとして保存されたデフォルト値で記述されている場合、その要素と意味的に同等です。マスター要素であるEBML要素は、デフォルト値を宣言してはなりません。 「minOccurs」値が1より大きいEBML要素は、デフォルト値を宣言してはなりません。
The default attribute is OPTIONAL.
デフォルトの属性はOPTIONALです。
Within an EBML Schema, the XPath of the "@type" attribute is "/EBMLSchema/element/@type".
EBMLスキーマ内では、「@ type」属性のXPathは「/ EBMLSchema / element / @ type」です。
The type MUST be set to one of the following values: "integer" (signed integer), "uinteger" (unsigned integer), "float", "string", "date", "utf-8", "master", or "binary". The content of each type is defined in Section 7.
タイプは、「整数」（符号付き整数）、「uinteger」（符号なし整数）、「float」、「string」、「date」、「utf-8」、「master」、のいずれかに設定する必要があります。または「バイナリ」。各タイプの内容はセクション7で定義されています。
The "type" attribute is REQUIRED.
「type」属性は必須です。
Within an EBML Schema, the XPath of the "@unknownsizeallowed" attribute is "/EBMLSchema/element/@unknownsizeallowed".
EBMLスキーマ内では、「@ unknownsizeallowed」属性のXPathは「/ EBMLSchema / element / @ unknownsizeallowed」です。
This attribute is a boolean to express whether an EBML Element is permitted to be an Unknown-Sized Element (having all VINT_DATA bits of Element Data Size set to 1). EBML Elements that are not Master Elements MUST NOT set "unknownsizeallowed" to true. An EBML Element that is defined with an "unknownsizeallowed" attribute set to 1 MUST also have the "unknownsizeallowed" attribute of its Parent Element set to 1.
この属性は、EBML要素がサイズ不明の要素（要素データサイズのすべてのVINT_DATAビットが1に設定されている）になることを許可するかどうかを表すブール値です。マスター要素ではないEBML要素は、「unknownsizeallowed」をtrueに設定してはなりません（MUST NOT）。 「unknownsizeallowed」属性を1に設定して定義されたEBML要素は、その親要素の「unknownsizeallowed」属性も1に設定する必要があります。
An EBML Element with the "unknownsizeallowed" attribute set to 1 MUST NOT have its "recursive" attribute set to 1.
「unknownsizeallowed」属性が1に設定されたEBML要素は、「再帰的」属性が1に設定されていてはなりません。
The "unknownsizeallowed" attribute is OPTIONAL. If the "unknownsizeallowed" attribute is not used, then that EBML Element is not allowed to use an unknown Element Data Size.
「unknownsizeallowed」属性はオプションです。 「unknownsizeallowed」属性が使用されていない場合、そのEBML要素は不明な要素のデータサイズを使用できません。
Within an EBML Schema, the XPath of the "@recursive" attribute is "/EBMLSchema/element/@recursive".
EBMLスキーマ内では、「@ recursive」属性のXPathは「/ EBMLSchema / element / @ recursive」です。
This attribute is a boolean to express whether an EBML Element is permitted to be stored recursively. If it is allowed, the EBML Element MAY be stored within another EBML Element that has the same Element ID, which itself can be stored in an EBML Element that has the same Element ID, and so on. EBML Elements that are not Master Elements MUST NOT set recursive to true.
この属性は、EBML要素を再帰的に格納できるかどうかを表すブール値です。許可されている場合、EBML要素は、同じ要素IDを持つ別のEBML要素内に格納できます。それ自体は、同じ要素IDを持つEBML要素に格納できます。マスター要素ではないEBML要素は、再帰をtrueに設定してはなりません。
If the EBMLElement part of the "@path" contains an IsRecursive part, then the "recursive" value MUST be true; otherwise, it MUST be false.
「@path」のEBMLElement部分にIsRecursive部分が含まれている場合、「再帰的」値はtrueでなければなりません。それ以外の場合は、falseにする必要があります。
An EBML Element with the "recursive" attribute set to 1 MUST NOT have its "unknownsizeallowed" attribute set to 1.
「recursive」属性が1に設定されているEBML要素は、「unknownsizeallowed」属性が1に設定されていてはなりません。
The "recursive" attribute is OPTIONAL. If the "recursive" attribute is not present, then the EBML Element MUST NOT be used recursively.
「再帰的」属性はオプションです。 「再帰的」属性が存在しない場合、EBML要素を再帰的に使用してはなりません（MUST NOT）。
Within an EBML Schema, the XPath of the "@recurring" attribute is "/EBMLSchema/element/@recurring".
EBMLスキーマ内では、「@ recurring」属性のXPathは「/ EBMLSchema / element / @ recurring」です。
This attribute is a boolean to express whether or not an EBML Element is defined as an Identically Recurring Element; see Section 11.1.17.
この属性は、EBML要素が同一反復要素として定義されているかどうかを表すブール値です。セクション11.1.17を参照してください。
The "recurring" attribute is OPTIONAL. If the "recurring" attribute is not present, then the EBML Element is not an Identically Recurring Element.
「繰り返し」属性はオプションです。 「繰り返し」属性が存在しない場合、EBML要素は同一の繰り返し要素ではありません。
Within an EBML Schema, the XPath of the "@minver" attribute is "/EBMLSchema/element/@minver".
EBMLスキーマ内では、「@ minver」属性のXPathは「/ EBMLSchema / element / @ minver」です。
The "minver" (minimum version) attribute stores a nonnegative integer that represents the first version of the docType to support the EBML Element.
「minver」（最小バージョン）属性には、EBML要素をサポートするdocTypeの最初のバージョンを表す負でない整数が格納されます。
The "minver" attribute is OPTIONAL. If the "minver" attribute is not present, then the EBML Element has a minimum version of "1".
「minver」属性はオプションです。 「minver」属性が存在しない場合、EBML要素の最小バージョンは「1」です。
Within an EBML Schema, the XPath of the "@maxver" attribute is "/EBMLSchema/element/@maxver".
EBMLスキーマ内では、「@ maxver」属性のXPathは「/ EBMLSchema / element / @ maxver」です。
The "maxver" (maximum version) attribute stores a nonnegative integer that represents the last or most recent version of the docType to support the element. "maxver" MUST be greater than or equal to "minver".
「maxver」（最大バージョン）属性には、要素をサポートするdocTypeの最新バージョンまたは最新バージョンを表す負でない整数が格納されます。 「maxver」は「minver」以上でなければなりません。
The "maxver" attribute is OPTIONAL. If the "maxver" attribute is not present, then the EBML Element has a maximum version equal to the value stored in the "version" attribute of "<EBMLSchema>".
「maxver」属性はオプションです。 「maxver」属性が存在しない場合、EBML要素の最大バージョンは、「<EBMLSchema>」の「version」属性に格納されている値と同じです。
Within an EBML Schema, the XPaths of the "<documentation>" elements are "/EBMLSchema/element/documentation" and "/EBMLSchema/element/restriction/enum/documentation".
EBMLスキーマ内では、「<documentation>」要素のXPathは「/ EBMLSchema / element / documentation」および「/ EBMLSchema / element / restriction / enum / documentation」です。
The "<documentation>" element provides additional information about EBML Elements or enumeration values. Within the "<documentation>" element, the following XHTML [XHTML] elements MAY be used: "<a>", "<br>", and "<strong>".
「<documentation>」要素は、EBML要素または列挙値に関する追加情報を提供します。 「<documentation>」要素内では、「<a>」、「<br>」、「<strong>」のXHTML [XHTML]要素を使用できます。
Within an EBML Schema, the XPath of the "@lang" attribute is "/EBMLSchema/element/documentation/@lang".
EBMLスキーマ内では、「@ lang」属性のXPathは「/ EBMLSchema / element / documentation / @ lang」です。
The "lang" attribute is set to the value from [RFC5646] of the language of the element's documentation.
「lang」属性は、要素のドキュメントの言語の[RFC5646]からの値に設定されます。
The "lang" attribute is OPTIONAL.
「lang」属性はオプションです。
Within an EBML Schema, the XPath of the "@purpose" attribute is "/EBMLSchema/element/documentation/@purpose".
EBMLスキーマ内では、「@ purpose」属性のXPathは「/ EBMLSchema / element / documentation / @ purpose」です。
A "purpose" attribute distinguishes the meaning of the documentation. Values for the "<documentation>" subelement's "purpose" attribute MUST include one of the values listed in Table 8.
「目的」属性は、ドキュメントの意味を区別します。 "<documentation>"サブ要素の "purpose"属性の値には、表8にリストされている値の1つを含める必要があります。
+============+=================================================+
| value of | definition |
| "purpose" | |
| attribute | |
+============+=================================================+
| definition | A "definition" is recommended for every defined |
| | EBML Element. This documentation explains the |
| | semantic meaning of the EBML Element. |
+------------+-------------------------------------------------+
| rationale | An explanation about the reason or catalyst for |
| | the definition of the Element. |
+------------+-------------------------------------------------+
| usage | Recommended practices or guidelines for both |
| notes | reading, writing, or interpreting the Element. |
+------------+-------------------------------------------------+
| references | Informational references to support the |
| | contextualization and understanding of the |
| | value of the Element. |
+------------+-------------------------------------------------+
Table 8: Definitions of the permitted values for the "purpose" attribute of the documentation Element
表8：ドキュメント要素の「purpose」属性に許可されている値の定義
The "purpose" attribute is REQUIRED.
「目的」属性は必須です。
Within an EBML Schema, the XPath of the "<implementation_note>" element is "/EBMLSchema/element/implementation_note".
EBMLスキーマ内では、「<implementation_note>」要素のXPathは「/ EBMLSchema / element / implementation_note」です。
In some cases within an EBML Document Type, the attributes of the "<element>" element are not sufficient to clearly communicate how the defined EBML Element is intended to be implemented. For instance, one EBML Element might only be mandatory if another EBML Element is present. As another example, the default value of an EBML Element might be derived from a related Element's content. In these cases where the Element's definition is conditional or advanced implementation notes are needed, one or many "<implementation_note>" elements can be used to store that information. The "<implementation_note>" refers to a specific attribute of the parent "<element>" as expressed by the "note_attribute" attribute (see Section 11.1.10.1).
EBMLドキュメントタイプ内の一部のケースでは、「<element>」要素の属性は、定義されたEBML要素の実装方法を明確に伝えるには不十分です。たとえば、1つのEBML要素は、別のEBML要素が存在する場合にのみ必須になる場合があります。別の例として、EBML要素のデフォルト値は、関連する要素のコンテンツから派生する場合があります。要素の定義が条件付きまたは高度な実装ノートが必要なこれらの場合、1つまたは複数の「<implementation_note>」要素を使用して、その情報を格納できます。 「<implementation_note>」は、「note_attribute」属性（セクション11.1.10.1を参照）で表される、親「<element>」の特定の属性を指します。
Within an EBML Schema, the XPath of the "@note_attribute" attribute is "/EBMLSchema/element/implementation_note/@note_attribute".
EBMLスキーマ内では、「@ note_attribute」属性のXPathは「/ EBMLSchema / element / implementation_note / @ note_attribute」です。
The "note_attribute" attribute references which of the attributes of the "<element>" the "<implementation_note>" relates to. The "note_attribute" attribute MUST be set to one of the following values (corresponding to that attribute of the parent "<element>"): "minOccurs", "maxOccurs", "range", "length", "default", "minver", or "maxver". The "<implementation_note>" SHALL supersede the parent "<element>"'s attribute that is named in the "note_attribute" attribute. An "<element>" SHALL NOT have more than one "<implementation_note>" of the same "note_attribute".
「note_attribute」属性は、「<implementation_note>」が「<element>」のどの属性に関連しているかを参照します。 「note_attribute」属性は、次の値のいずれかに設定する必要があります（親「<element>」のその属性に対応）：「minOccurs」、「maxOccurs」、「range」、「length」、「default」、「 minver」または「maxver」。 「<implementation_note>」は、「note_attribute」属性で指定された親「<element>」の属性に優先します。 "<element>"は、同じ "note_attribute"の複数の "<implementation_note>"を持つことはできません。
The "note_attribute" attribute is REQUIRED.
「note_attribute」属性は必須です。
The following fragment of an EBML Schema demonstrates how an "<implementation_note>" is used. In this case, an EBML Schema documents a list of items that are described with an optional cost. The Currency Element uses an "<implementation_note>" to say that the Currency Element is REQUIRED if the Cost Element is set, otherwise not.
EBMLスキーマの次のフラグメントは、「<implementation_note>」の使用方法を示しています。この場合、EBMLスキーマは、オプションのコストで記述されるアイテムのリストを文書化します。 Currency要素は "<implementation_note>"を使用して、Cost要素が設定されている場合はCurrency要素が必須であり、そうでない場合は必須であることを示します。
<element name="Items" path="\Items" id="0x4025" type="master"
minOccurs="1" maxOccurs="1">
<documentation lang="en" purpose="definition">
A set of items.
</documentation>
</element>
<element name="Item" path="\Items\Item" id="0x4026"
type="master">
<documentation lang="en" purpose="definition">
An item.
</documentation>
</element>
<element name="Cost" path="\Items\Item\Cost" id="0x4024"
type="float" maxOccurs="1">
<documentation lang="en" purpose="definition">
The cost of the item, if any.
</documentation>
</element>
<element name="Currency" path="\Items\Item\Currency" id="0x403F"
type="string" maxOccurs="1">
<documentation lang="en" purpose="definition">
The currency of the item's cost.
</documentation>
<implementation_note note_attribute="minOccurs">
Currency MUST be set (minOccurs=1) if the associated Item stores
a Cost, else Currency MAY be unset (minOccurs=0).
</implementation_note>
</element>
Within an EBML Schema, the XPath of the "<restriction>" element is "/EBMLSchema/element/restriction".
EBMLスキーマ内では、「<restriction>」要素のXPathは「/ EBMLSchema / element / restriction」です。
The "<restriction>" element provides information about restrictions to the allowable values for the EBML Element, which are listed in "<enum>" elements.
"<restriction>"要素は、EBML要素の許容値の制限に関する情報を提供します。これは "<enum>"要素にリストされています。
Within an EBML Schema, the XPath of the "<enum>" element is "/EBMLSchema/element/restriction/enum".
EBMLスキーマ内では、「<enum>」要素のXPathは「/ EBMLSchema / element / restriction / enum」です。
The "<enum>" element stores a list of values allowed for storage in the EBML Element. The values MUST match the type of the EBML Element (for example, "<enum value="Yes">" cannot be a valid value for an EBML Element that is defined as an unsigned integer). An "<enum>" element MAY also store "<documentation>" elements to further describe the "<enum>".
「<enum>」要素は、EBML要素への格納が許可されている値のリストを格納します。値はEBML要素のタイプと一致する必要があります（たとえば、「<enum value = "Yes">」は、符号なし整数として定義されているEBML要素の有効な値であってはなりません）。 "<enum>"要素は、 "<enum>"をさらに説明するために "<documentation>"要素も格納してもよい（MAY）。
Within an EBML Schema, the XPath of the "@label" attribute is "/EBMLSchema/element/restriction/enum/@label".
EBMLスキーマ内では、「@ label」属性のXPathは「/ EBMLSchema / element / restriction / enum / @ label」です。
The label provides a concise expression for human consumption that describes what the value of "<enum>" represents.
ラベルは、「<enum>」の値が何を表すかを説明する、人間による消費の簡潔な表現を提供します。
The "label" attribute is OPTIONAL.
「ラベル」属性はオプションです。
Within an EBML Schema, the XPath of the "@value" attribute is "/EBMLSchema/element/restriction/enum/@value".
EBMLスキーマ内では、「@ value」属性のXPathは「/ EBMLSchema / element / restriction / enum / @ value」です。
The value represents data that MAY be stored within the EBML Element.
この値は、EBML要素内に格納できるデータを表します。
The "value" attribute is REQUIRED.
「値」属性は必須です。
Within an EBML Schema, the XPath of the "<extension>" element is "/EBMLSchema/element/extension".
EBMLスキーマ内では、「<extension>」要素のXPathは「/ EBMLSchema / element / extension」です。
The "<extension>" element provides an unconstrained element to contain information about the associated EBML "<element>", which is undefined by this document but MAY be defined by the associated EBML Document Type. The "<extension>" element MUST contain a "type" attribute and also MAY contain any other attribute or subelement as long as the EBML Schema remains as a well-formed XML Document. All "<extension>" elements MUST be subelements of the "<element>".
"<extension>"要素は、関連するEBML "<element>"に関する情報を含むための制約のない要素を提供します。これは、このドキュメントでは定義されていませんが、関連するEBMLドキュメントタイプによって定義される場合があります。 EBMLスキーマが整形式のXMLドキュメントのままである限り、「<extension>」要素には「type」属性を含める必要があり、他の属性またはサブ要素を含めることもできます（MAY）。すべての「<extension>」要素は、「<element>」のサブ要素である必要があります。
Within an EBML Schema, the XPath of the "@type" attribute is "/EBMLSchema/element/extension/@type".
EBMLスキーマ内では、「@ type」属性のXPathは「/ EBMLSchema / element / extension / @ type」です。
The "type" attribute should reference a name or identifier of the project or authority associated with the contents of the "<extension>" element.
「type」属性は、「<extension>」要素のコンテンツに関連付けられたプロジェクトまたは権限の名前または識別子を参照する必要があります。
The "type" attribute is REQUIRED.
「type」属性は必須です。
The following provides an XML Schema [XML-SCHEMA] for facilitating verification of an EBML Schema described in Section 11.1.
以下は、セクション11.1で説明されているEBMLスキーマの検証を容易にするためのXMLスキーマ[XML-SCHEMA]を提供します。
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns="urn:ietf:rfc:8794"
targetNamespace="urn:ietf:rfc:8794"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:xhtml="http://www.w3.org/1999/xhtml"
elementFormDefault="qualified" version="01">
<!-- for HTML in comments -->
<xs:import namespace="http://www.w3.org/1999/xhtml"
schemaLocation="http://www.w3.org/MarkUp/SCHEMA/xhtml11.xsd"/>
<xs:element name="EBMLSchema" type="EBMLSchemaType"/>
<xs:complexType name="EBMLSchemaType">
<xs:sequence>
<xs:element name="element" type="elementType"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="docType" use="required"/>
<xs:attribute name="version" use="required" type="xs:integer"/>
<xs:attribute name="ebml" type="xs:positiveInteger"
default="1"/>
</xs:complexType>
<xs:complexType name="elementType">
<xs:sequence>
<xs:element name="documentation" type="documentationType"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="implementation_note" type="noteType"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="restriction" type="restrictionType"
minOccurs="0" maxOccurs="1"/>
<xs:element name="extension" type="extensionType"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="name" use="required">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:pattern value="[0-9A-Za-z.-]([0-9A-Za-z.-])*"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="path" use="required">
<!-- <xs:simpleType>
<xs:restriction base="xs:integer">
<xs:pattern value="[0-9]*\*[0-9]*()"/>
</xs:restriction>
</xs:simpleType> -->
</xs:attribute>
<xs:attribute name="id" use="required">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:pattern value="0x([0-9A-F][0-9A-F])+"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="minOccurs" default="0">
<xs:simpleType>
<xs:restriction base="xs:integer">
<xs:minInclusive value="0"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="maxOccurs" default="1">
<xs:simpleType>
<xs:restriction base="xs:integer">
<xs:minInclusive value="0"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="range"/>
<xs:attribute name="length"/>
<xs:attribute name="default"/>
<xs:attribute name="type" use="required">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="integer"/>
<xs:enumeration value="uinteger"/>
<xs:enumeration value="float"/>
<xs:enumeration value="string"/>
<xs:enumeration value="date"/>
<xs:enumeration value="utf-8"/>
<xs:enumeration value="master"/>
<xs:enumeration value="binary"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="unknownsizeallowed" type="xs:boolean"
default="false"/>
<xs:attribute name="recursive" type="xs:boolean"
default="false"/>
<xs:attribute name="recurring" type="xs:boolean"
default="false"/>
<xs:attribute name="minver" default="1">
<xs:simpleType>
<xs:restriction base="xs:integer">
<xs:minInclusive value="0"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="maxver">
<xs:simpleType>
<xs:restriction base="xs:integer">
<xs:minInclusive value="0"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
<xs:complexType name="restrictionType">
<xs:sequence>
<xs:element name="enum" type="enumType"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="extensionType">
<xs:sequence>
<xs:any processContents="skip"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="type" use="required"/>
<xs:anyAttribute processContents="skip"/>
</xs:complexType>
<xs:complexType name="enumType">
<xs:sequence>
<xs:element name="documentation" type="documentationType"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="label"/>
<xs:attribute name="value" use="required"/>
</xs:complexType>
<xs:complexType name="documentationType" mixed="true">
<xs:sequence>
<xs:element name="a" type="xhtml:xhtml.a.type"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="br" type="xhtml:xhtml.br.type"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="strong" type="xhtml:xhtml.strong.type"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="lang"/>
<xs:attribute name="purpose" use="required">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="definition"/>
<xs:enumeration value="rationale"/>
<xs:enumeration value="references"/>
<xs:enumeration value="usage notes"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
<xs:complexType name="noteType">
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="note_attribute" use="required">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="minOccurs"/>
<xs:enumeration value="maxOccurs"/>
<xs:enumeration value="range"/>
<xs:enumeration value="length"/>
<xs:enumeration value="default"/>
<xs:enumeration value="minver"/>
<xs:enumeration value="maxver"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:schema>
An Identically Recurring Element is an EBML Element that MAY occur within its Parent Element more than once, but each recurrence of it within that Parent Element MUST be identical both in storage and semantics. Identically Recurring Elements are permitted to be stored multiple times within the same Parent Element in order to increase data resilience and optimize the use of EBML in transmission. For instance, a pertinent Top-Level Element could be periodically resent within a datastream so that an EBML Reader that starts reading the stream from the middle could better interpret the contents. Identically Recurring Elements SHOULD include a CRC-32 Element as a Child Element; this is especially recommended when EBML is used for long-term storage or transmission. If a Parent Element contains more than one copy of an Identically Recurring Element that includes a CRC-32 Element as a Child Element, then the first instance of the Identically Recurring Element with a valid CRC-32 value should be used for interpretation. If a Parent Element contains more than one copy of an Identically Recurring Element that does not contain a CRC-32 Element, or if CRC-32 Elements are present but none are valid, then the first instance of the Identically Recurring Element should be used for interpretation.
Identically Recurring Elementは、その親要素内で2回以上発生する可能性があるEBML要素ですが、その親要素内での各繰り返しは、ストレージとセマンティクスの両方で同一でなければなりません。データの回復力を高め、送信でのEBMLの使用を最適化するために、同一の繰り返し要素を同じ親要素内に複数回保存することが許可されています。たとえば、適切な最上位要素をデータストリーム内で定期的に再送信して、途中からストリームの読み取りを開始するEBMLリーダーがコンテンツをより適切に解釈できるようにすることができます。同一に繰り返される要素には、子要素としてCRC-32要素を含める必要があります。これは、EBMLを長期間の保存または送信に使用する場合に特に推奨されます。親要素に、CRC-32要素を子要素として含む同一反復要素の複数のコピーが含まれている場合、有効なCRC-32値を持つ同一反復要素の最初のインスタンスを解釈に使用する必要があります。親要素に、CRC-32要素を含まない同一反復要素の複数のコピーが含まれる場合、またはCRC-32要素は存在するが有効な要素がない場合は、同一反復要素の最初のインスタンスを解釈。
When a float value is represented textually in an EBML Schema, such as within a default or range value, the float values MUST be expressed as Hexadecimal Floating-Point Constants as defined in the C11 standard [ISO9899] (see Section 6.4.4.2 on Floating Constants). Table 9 provides examples of expressions of float ranges.
デフォルトまたは範囲値内など、EBMLスキーマで浮動小数点値をテキストで表す場合、浮動小数点値は、C11標準[ISO9899]で定義されている16進浮動小数点定数として表現する必要があります（浮動小数点に関するセクション6.4.4.2を参照）。定数）。表9に、float範囲の式の例を示します。
+===================+=========================================+
| as decimal | as Hexadecimal Floating-Point Constants |
+===================+=========================================+
| 0.0 | 0x0p+1 |
+-------------------+-----------------------------------------+
| 0.0-1.0 | 0x0p+1-0x1p+0 |
+-------------------+-----------------------------------------+
| 1.0-256.0 | 0x1p+0-0x1p+8 |
+-------------------+-----------------------------------------+
| 0.857421875 | 0x1.b7p-1 |
+-------------------+-----------------------------------------+
| -1.0--0.857421875 | -0x1p+0--0x1.b7p-1 |
+-------------------+-----------------------------------------+
Table 9: Example of Floating-Point values and ranges as decimal and Hexadecimal Floating-Point Constants
表9：10進および16進浮動小数点定数としての浮動小数点値と範囲の例
Within an expression of a float range, as in an integer range, the - (hyphen) character is the separator between the minimum and maximum values permitted by the range. Hexadecimal Floating-Point Constants also use a - (hyphen) when indicating a negative binary power. Within a float range, when a - (hyphen) is immediately preceded by a letter p, then the - (hyphen) is a part of the Hexadecimal Floating-Point Constant that notes negative binary power. Within a float range, when a - (hyphen) is not immediately preceded by a letter p, then the - (hyphen) represents the separator between the minimum and maximum values permitted by the range.
整数範囲と同様に、浮動小数点範囲の式内では、-（ハイフン）文字は、範囲で許可される最小値と最大値の間の区切り文字です。 16進浮動小数点定数は、負の2の累乗を示す場合も-（ハイフン）を使用します。 floatの範囲内で、-（ハイフン）の直後に文字pが付いている場合、-（ハイフン）は、負の2進数の累乗を示す16進浮動小数点定数の一部です。 float範囲内で、-（ハイフン）の前に文字pがない場合、-（ハイフン）は、範囲で許可される最小値と最大値の間のセパレーターを表します。
11.1.19. Note on the use of default attributes to define Mandatory EBML Elements
11.1.19. デフォルトの属性を使用して必須のEBML要素を定義することに関する注意
If a Mandatory EBML Element has a default value declared by an EBML Schema and the value of the EBML Element is equal to the declared default value, then that EBML Element is not required to be present within the EBML Document if its Parent Element is present. In this case, the default value of the Mandatory EBML Element MUST be read by the EBML Reader, although the EBML Element is not present within its Parent Element.
必須EBML要素にEBMLスキーマによって宣言されたデフォルト値があり、EBML要素の値が宣言されたデフォルト値と等しい場合、そのEBML要素は、その親要素が存在する場合、EBMLドキュメント内に存在する必要はありません。この場合、EBML要素はその親要素内に存在しませんが、必須EBML要素のデフォルト値をEBMLリーダーで読み取る必要があります。
If a Mandatory EBML Element has no default value declared by an EBML Schema and its Parent Element is present, then the EBML Element MUST be present, as well. If a Mandatory EBML Element has a default value declared by an EBML Schema, and its Parent Element is present, and the value of the EBML Element is NOT equal to the declared default value, then the EBML Element MUST be present.
必須のEBML要素にEBMLスキーマによって宣言されたデフォルト値がなく、その親要素が存在する場合、EBML要素も存在する必要があります。必須のEBML要素にEBMLスキーマによって宣言されたデフォルト値があり、その親要素が存在し、EBML要素の値が宣言されたデフォルト値と等しくない場合、EBML要素が存在しなければなりません（MUST）。
Table 10 clarifies whether a Mandatory EBML Element MUST be written, according to whether the default value is declared, the value of the EBML Element is equal to the declared default value, and/or the Parent Element is used.
表10は、デフォルト値が宣言されているか、EBML要素の値が宣言されたデフォルト値と等しいか、親要素が使用されているかに従って、必須のEBML要素を記述しなければならないかどうかを示しています。
+=================+=============+===============+==================+
| Is the default | Is the | Is the Parent | Then is storing |
| value declared? | value equal | Element | the EBML Element |
| | to default? | present? | REQUIRED? |
+=================+=============+===============+==================+
| Yes | Yes | Yes | No |
+-----------------+-------------+---------------+------------------+
| Yes | Yes | No | No |
+-----------------+-------------+---------------+------------------+
| Yes | No | Yes | Yes |
+-----------------+-------------+---------------+------------------+
| Yes | No | No | No |
+-----------------+-------------+---------------+------------------+
| No | n/a | Yes | Yes |
+-----------------+-------------+---------------+------------------+
| No | n/a | No | No |
+-----------------+-------------+---------------+------------------+
Table 10: Demonstration of the conditional requirements of VINT Storage
表10：VINTストレージの条件付き要件のデモ
This document contains definitions of all EBML Elements of the EBML Header.
このドキュメントには、EBMLヘッダーのすべてのEBML要素の定義が含まれています。
name: EBML
名前：EBML
path: "\EBML"
パス： "\ EBML"
id: 0x1A45DFA3
id：0x1A45DFA3
minOccurs: 1
minOccurs：1
maxOccurs: 1
maxOccurs：1
type: Master Element
タイプ：マスター要素
description: Set the EBML characteristics of the data to follow. Each EBML Document has to start with this.
説明：従うデータのEBML特性を設定します。各EBMLドキュメントはこれから始める必要があります。
name: EBMLVersion
名前：EBMLVersion
path: "\EBML\EBMLVersion"
パス：「\ EBML \ EBMLVersion」
id: 0x4286
id：0x4286
minOccurs: 1
minOccurs：1
maxOccurs: 1
maxOccurs：1
range: not 0
範囲：0以外
default: 1
デフォルト：1
type: Unsigned Integer
タイプ：符号なし整数
description: The version of EBML specifications used to create the EBML Document. The version of EBML defined in this document is 1, so EBMLVersion SHOULD be 1.
説明：EBMLドキュメントの作成に使用されるEBML仕様のバージョン。このドキュメントで定義されているEBMLのバージョンは1であるため、EBMLVersionは1である必要があります。
name: EBMLReadVersion
名前：EBMLReadVersion
path: "\EBML\EBMLReadVersion"
パス：「\ EBML \ EBMLReadVersion」
id: 0x42F7
id：0x42F7
minOccurs: 1
minOccurs：1
maxOccurs: 1
maxOccurs：1
range: 1
範囲：1
default: 1
デフォルト：1
type: Unsigned Integer
タイプ：符号なし整数
description: The minimum EBML version an EBML Reader has to support to read this EBML Document. The EBMLReadVersion Element MUST be less than or equal to EBMLVersion.
説明：EBMLリーダーがこのEBMLドキュメントを読み取るためにサポートする必要があるEBMLの最小バージョン。 EBMLReadVersion要素は、EBMLVersion以下でなければなりません。
name: EBMLMaxIDLength
名前：EBMLMaxIDLength
path: "\EBML\EBMLMaxIDLength"
パス：「\ EBML \ EBMLMaxIDLength」
id: 0x42F2
id：0x42F2
minOccurs: 1
minOccurs：1
maxOccurs: 1
maxOccurs：1
range: >=4
default: 4
デフォルト：4
type: Unsigned Integer
タイプ：符号なし整数
description: The EBMLMaxIDLength Element stores the maximum permitted length in octets of the Element IDs to be found within the EBML Body. An EBMLMaxIDLength Element value of four is RECOMMENDED, though larger values are allowed.
説明：EBMLMaxIDLengthエレメントは、EBMLボディ内で検出されるエレメントIDのオクテット単位の最大許容長を格納します。 EBMLMaxIDLength要素の値4は推奨されますが、これより大きな値も許可されます。
name: EBMLMaxSizeLength
名前：EBMLMaxSizeLength
path: "\EBML\EBMLMaxSizeLength"
パス：「\ EBML \ EBMLMaxSizeLength」
id: 0x42F3
id：0x42F3
minOccurs: 1
minOccurs：1
maxOccurs: 1
maxOccurs：1
range: not 0
範囲：0以外
default: 8
デフォルト：8
type: Unsigned Integer
タイプ：符号なし整数
description: The EBMLMaxSizeLength Element stores the maximum permitted length in octets of the expressions of all Element Data Sizes to be found within the EBML Body. The EBMLMaxSizeLength Element documents an upper bound for the "length" of all Element Data Size expressions within the EBML Body and not an upper bound for the "value" of all Element Data Size expressions within the EBML Body. EBML Elements that have an Element Data Size expression that is larger in octets than what is expressed by EBMLMaxSizeLength Element are invalid.
説明：EBMLMaxSizeLengthエレメントは、EBMLボディ内で検出されるすべてのエレメントデータサイズの式の最大許容長をオクテットで格納します。 EBMLMaxSizeLength要素は、EBML本体内のすべての要素データサイズ式の「値」の上限ではなく、EBML本体内のすべての要素データサイズ式の「長さ」の上限を文書化します。 EBMLMaxSizeLength要素で表されるものよりもオクテットが大きい要素データサイズ式を持つEBML要素は無効です。
name: DocType
名前：DocType
path: "\EBML\DocType"
パス：「\ EBML \ DocType」
id: 0x4282
id：0x4282
minOccurs: 1
minOccurs：1
maxOccurs: 1
maxOccurs：1
length: >0
長さ：> 0
type: String
タイプ：文字列
description: A string that describes and identifies the content of the EBML Body that follows this EBML Header.
description：このEBMLヘッダーに続くEBML本文のコンテンツを説明および識別する文字列。
name: DocTypeVersion
名前：DocTypeVersion
path: "\EBML\DocTypeVersion"
パス：「\ EBML \ DocTypeVersion」
id: 0x4287
id：0x4287
minOccurs: 1
minOccurs：1
maxOccurs: 1
maxOccurs：1
range: not 0
範囲：0以外
default: 1
デフォルト：1
type: Unsigned Integer
タイプ：符号なし整数
description: The version of DocType interpreter used to create the EBML Document.
説明：EBMLドキュメントの作成に使用されるDocTypeインタープリターのバージョン。
name: DocTypeReadVersion
名前：DocTypeReadVersion
path: "\EBML\DocTypeReadVersion"
パス：「\ EBML \ DocTypeReadVersion」
id: 0x4285
id：0x4285
minOccurs: 1
minOccurs：1
maxOccurs: 1
maxOccurs：1
range: not 0
範囲：0以外
default: 1
デフォルト：1
type: Unsigned Integer
タイプ：符号なし整数
description: The minimum DocType version an EBML Reader has to support to read this EBML Document. The value of the DocTypeReadVersion Element MUST be less than or equal to the value of the DocTypeVersion Element.
説明：EBMLリーダーがこのEBMLドキュメントを読み取るためにサポートする必要があるDocTypeの最小バージョン。 DocTypeReadVersion要素の値は、DocTypeVersion要素の値以下でなければなりません。
name: DocTypeExtension
名前：DocTypeExtension
path: "\EBML\DocTypeExtension"
パス：「\ EBML \ DocTypeExtension」
id: 0x4281
id：0x4281
minOccurs: 0
minOccurs：0
type: Master Element
タイプ：マスター要素
description: A DocTypeExtension adds extra Elements to the main DocType+DocTypeVersion tuple it's attached to. An EBML Reader MAY know these extra Elements and how to use them. A DocTypeExtension MAY be used to iterate between experimental Elements before they are integrated into a regular DocTypeVersion. Reading one DocTypeExtension version of a DocType+DocTypeVersion tuple doesn't imply one should be able to read upper versions of this DocTypeExtension.
説明：DocTypeExtensionは、アタッチされているメインのDocType + DocTypeVersionタプルに追加の要素を追加します。 EBMLリーダーは、これらの追加の要素とその使用方法を知っている場合があります。 DocTypeExtensionを使用して、通常のDocTypeVersionに統合される前に実験的な要素間を反復できます。 DocType + DocTypeVersionタプルの1つのDocTypeExtensionバージョンを読み取ることは、このDocTypeExtensionの上位バージョンを読み取ることができる必要があることを意味しません。
name: DocTypeExtensionName
名前：DocTypeExtensionName
path: "\EBML\DocTypeExtension\DocTypeExtensionName"
パス：「\ EBML \ DocTypeExtension \ DocTypeExtensionName」
id: 0x4283
id：0x4283
minOccurs: 1
minOccurs：1
maxOccurs: 1
maxOccurs：1
length: >0
長さ：> 0
type: String
タイプ：文字列
description: The name of the DocTypeExtension to differentiate it from other DocTypeExtensions of the same DocType+DocTypeVersion tuple. A DocTypeExtensionName value MUST be unique within the EBML Header.
説明：同じDocType + DocTypeVersionタプルの他のDocTypeExtensionsと区別するためのDocTypeExtensionの名前。 DocTypeExtensionName値は、EBMLヘッダー内で一意である必要があります。
name: DocTypeExtensionVersion
名前：DocTypeExtensionVersion
path: "\EBML\DocTypeExtension\DocTypeExtensionVersion"
パス：「\ EBML \ DocTypeExtension \ DocTypeExtensionVersion」
id: 0x4284
id：0x4284
minOccurs: 1
minOccurs：1
maxOccurs: 1
maxOccurs：1
range: not 0
範囲：0以外
type: Unsigned Integer
タイプ：符号なし整数
description: The version of the DocTypeExtension. Different DocTypeExtensionVersion values of the same DocType + DocTypeVersion + DocTypeExtensionName tuple MAY contain completely different sets of extra Elements. An EBML Reader MAY support multiple versions of the same tuple, only one version of the tuple, or not support the tuple at all.
説明：DocTypeExtensionのバージョン。同じDocType + DocTypeVersion + DocTypeExtensionNameタプルの異なるDocTypeExtensionVersion値には、完全に異なる追加要素のセットが含まれる場合があります。 EBMLリーダーは、同じタプルの複数のバージョンをサポートしても、タプルの1つのバージョンのみをサポートしても、タプルをまったくサポートしなくてもかまいません（MAY）。
EBML allows some special Elements to be found within more than one parent in an EBML Document or optionally at the Root Level of an EBML Body. These Elements are called Global Elements. There are two Global Elements that can be found in any EBML Document: the CRC-32 Element and the Void Element. An EBML Schema MAY add other Global Elements to the format it defines. These extra elements apply only to the EBML Body, not the EBML Header.
EBMLでは、EBMLドキュメントの複数の親内に、またはオプションでEBMLボディのルートレベルに、いくつかの特別な要素を見つけることができます。これらの要素はグローバル要素と呼ばれます。どのEBMLドキュメントでも見つかる2つのグローバル要素があります。CRC-32要素とVoid要素です。 EBMLスキーマは、定義するフォーマットに他のグローバル要素を追加する場合があります。これらの追加の要素は、EBMLヘッダーではなく、EBML本文にのみ適用されます。
Global Elements are EBML Elements whose EBMLLastParent part of the path has a GlobalPlaceholder. Because it is the last Parent part of the path, a Global Element might also have EBMLParentPath parts in its path. In this case, the Global Element can only be found within this EBMLParentPath path -- i.e., it's not fully "global".
グローバル要素は、パスのEBMLLastParent部分にGlobalPlaceholderがあるEBML要素です。これはパスの最後の親部分であるため、グローバル要素もそのパスにEBMLParentPath部分がある場合があります。この場合、グローバル要素はこのEBMLParentPathパス内でのみ見つかります。つまり、完全に「グローバル」ではありません。
A Global Element can be found in many Parent Elements, allowing the same number of occurrences in each Parent where this Element is found.
グローバル要素は多くの親要素で見つけることができ、この要素が見つかった各親で同じ数の出現を許可します。
name: CRC-32
名前：CRC-32
path: "\(1-\)CRC-32"
id: 0xBF
id：0xBF
minOccurs: 0
minOccurs：0
maxOccurs: 1
maxOccurs：1
length: 4
長さ：4
type: Binary
タイプ：バイナリ
description: The CRC-32 Element contains a 32-bit Cyclic Redundancy Check value of all the Element Data of the Parent Element as stored except for the CRC-32 Element itself. When the CRC-32 Element is present, the CRC-32 Element MUST be the first ordered EBML Element within its Parent Element for easier reading. All Top-Level Elements of an EBML Document that are Master Elements SHOULD include a CRC-32 Element as a Child Element. The CRC in use is the IEEE-CRC-32 algorithm as used in the [ISO3309] standard and in Section 8.1.1.6.2 of [ITU.V42], with initial value of 0xFFFFFFFF. The CRC value MUST be computed on a little-endian bytestream and MUST use little-endian storage.
説明：CRC-32エレメントには、CRC-32エレメント自体を除く、保存されている親エレメントのすべてのエレメントデータの32ビット巡回冗長検査値が含まれています。 CRC-32要素が存在する場合、読みやすくするために、CRC-32要素はその親要素内で最初に順序付けられたEBML要素でなければなりません。マスター要素であるEBMLドキュメントのすべての最上位要素には、子要素としてCRC-32要素を含める必要があります。使用中のCRCは、[ISO3309]標準および[ITU.V42]のセクション8.1.1.6.2で使用されるIEEE-CRC-32アルゴリズムであり、初期値は0xFFFFFFFFです。 CRC値はリトルエンディアンバイトストリームで計算する必要があり、リトルエンディアンストレージを使用する必要があります。
name: Void
名前：Void
path: "\(-\)Void"
id: 0xEC
id：0xEC
minOccurs: 0
minOccurs：0
type: Binary
タイプ：バイナリ
description: Used to void data or to avoid unexpected behaviors when using damaged data. The content is discarded. Also used to reserve space in a subelement for later use.
説明：データを無効にするか、破損したデータを使用するときに予期しない動作を回避するために使用されます。コンテンツは破棄されます。後で使用するためにサブエレメントのスペースを予約するためにも使用されます。
The following scenarios describe events to consider when reading EBML Documents, as well as the recommended design of an EBML Reader.
次のシナリオでは、EBMLドキュメントを読み取るときに考慮する必要があるイベントと、EBMLリーダーの推奨設計について説明します。
If a Master Element contains a CRC-32 Element that doesn't validate, then the EBML Reader MAY ignore all contained data except for Descendant Elements that contain their own valid CRC-32 Element.
検証されないCRC-32要素がマスター要素に含まれている場合、EBMLリーダーは、独自の有効なCRC-32要素を含む子孫要素を除いて、含まれているすべてのデータを無視してもよい（MAY）。
In the following XML representation of a simple, hypothetical EBML fragment, a Master Element called CONTACT contains two Child Elements, NAME and ADDRESS. In this example, some data within the NAME Element had been altered so that the CRC-32 of the NAME Element does not validate, and thus any Ancestor Element with a CRC-32 would therefore also no longer validate. However, even though the CONTACT Element has a CRC-32 that does not validate (because of the changed data within the NAME Element), the CRC-32 of the ADDRESS Element does validate, and thus the contents and semantics of the ADDRESS Element MAY be used.
次の単純な架空のEBMLフラグメントのXML表現では、CONTACTというマスター要素に、NAMEとADDRESSという2つの子要素が含まれています。この例では、NAME要素内の一部のデータが変更され、NAME要素のCRC-32が検証されないため、CRC-32を持つ祖先要素も検証されなくなりました。ただし、CONTACT要素に検証されないCRC-32が含まれていても（NAME要素内のデータが変更されたため）、ADDRESS要素のCRC-32は検証されるため、ADDRESS要素の内容とセマンティクスが利用される。
<CONTACT>
<CRC-32>c119a69b</CRC-32><!-- does not validate -->
<NAME>
<CRC-32>1f59ee2b</CRC-32><!-- does not validate -->
<FIRST-NAME>invalid data</FIRST-NAME>
<LAST-NAME>invalid data</LAST-NAME>
</NAME>
<ADDRESS>
<CRC-32>df941cc9</CRC-32><!-- validates -->
<STREET>valid data</STREET>
<CITY>valid data</CITY>
</ADDRESS>
</CONTACT>
If a Master Element contains more occurrences of a Child Master Element than permitted according to the "maxOccurs" and "recurring" attributes of the definition of that Element, then the occurrences in addition to "maxOccurs" MAY be ignored.
マスター要素に、その要素の定義の「maxOccurs」および「recurring」属性で許可されているよりも多くの子マスター要素のオカレンスが含まれている場合、「maxOccurs」に加えてオカレンスは無視される場合があります。
If a Master Element contains more occurrences of a Child Element than permitted according to the "maxOccurs" attribute of the definition of that Element, then all instances of that Element after the first "maxOccurs" occurrences from the beginning of its Parent Element SHOULD be ignored.
マスター要素に、その要素の定義の「maxOccurs」属性で許可されているよりも多くの子要素のオカレンスが含まれている場合、親要素の最初から最初の「maxOccurs」オカレンスの後のその要素のすべてのインスタンスを無視する必要があります（SHOULD） 。
Null Octets, which are octets with all bits set to zero, MAY follow the value of a String Element or UTF-8 Element to serve as a terminator. An EBML Writer MAY terminate a String Element or UTF-8 Element with Null Octets in order to overwrite a stored value with a new value of lesser length while maintaining the same Element Data Size; this can prevent the need to rewrite large portions of an EBML Document. Otherwise, the use of Null Octets within a String Element or UTF-8 Element is NOT RECOMMENDED. The Element Data of a UTF-8 Element MUST be a valid UTF-8 string up to whichever comes first: the end of the Element or the first occurring Null octet. Within the Element Data of a String or UTF-8 Element, any Null octet itself and any following data within that Element SHOULD be ignored. A string value and a copy of that string value terminated by one or more Null Octets are semantically equal.
すべてのビットが0に設定されたオクテットであるヌルオクテットは、文字列要素またはUTF-8要素の値に従ってターミネーターとして機能する場合があります。 EBMLライターは、格納されている値を同じ長さの新しい値で上書きしながら、同じ要素のデータサイズを維持するために、文字列要素またはUTF-8要素をヌルオクテットで終了する場合があります。これにより、EBMLドキュメントの大部分を書き換える必要がなくなります。それ以外の場合、文字列要素またはUTF-8要素内でのNullオクテットの使用は推奨されません。 UTF-8要素の要素データは、要素の終わりまたは最初に発生するNullオクテットのうち、最初に来る方まで有効なUTF-8文字列である必要があります。文字列またはUTF-8要素の要素データ内では、Nullオクテット自体とその要素内の後続のデータはすべて無視する必要があります（SHOULD）。文字列値と、1つ以上のNullオクテットで終了する文字列値のコピーは、意味的に同じです。
Table 11 shows examples of semantics and validation for the use of Null Octets. Values to represent Stored Values and the Semantic Meaning as represented as hexadecimal values.
表11は、ヌルオクテットの使用に関するセマンティクスと検証の例を示しています。保存された値を表す値と、16進値として表される意味の意味。
+=====================+=====================+
| Stored Value | Semantic Meaning |
+=====================+=====================+
| 0x65 0x62 0x6D 0x6C | 0x65 0x62 0x6D 0x6C |
+---------------------+---------------------+
| 0x65 0x62 0x00 0x6C | 0x65 0x62 |
+---------------------+---------------------+
| 0x65 0x62 0x00 0x00 | 0x65 0x62 |
+---------------------+---------------------+
| 0x65 0x62 | 0x65 0x62 |
+---------------------+---------------------+
Table 11: Examples of semantics for Null Octets in VINT_DATA
表11：VINT_DATAのNullオクテットのセマンティクスの例
An EBML Document can be updated without requiring that the entire EBML Document be rewritten. These recommendations describe strategies for changing the Element Data of a written EBML Element with minimal disruption to the rest of the EBML Document.
EBMLドキュメント全体を書き直さなくても、EBMLドキュメントを更新できます。これらの推奨事項は、残りのEBMLドキュメントへの混乱を最小限に抑えて、書き込まれたEBML要素の要素データを変更するための戦略を説明しています。
There are three methods to reduce the size of Element Data of a written EBML Element.
書き込まれたEBML要素の要素データのサイズを削減するには、3つの方法があります。
When an EBML Element is changed to reduce its total length by more than one octet, an EBML Writer SHOULD fill the freed space with a Void Element.
EBML要素が変更されてその全体の長さが1オクテット以上短くなった場合、EBMLライターは、解放されたスペースをVoid要素で埋める必要があります（SHOULD）。
The same value for Element Data Size MAY be written in various lengths, so for minor reductions of the Element Data, the Element Size MAY be written to a longer octet length to fill the freed space.
要素データサイズに同じ値をさまざまな長さで書き込むことができるため、要素データを少し削減するために、解放されたスペースを埋めるために、要素サイズをより長いオクテット長に書き込むことができます。
For example, the first row of Table 12 depicts a String Element that stores an Element ID (3 octets), Element Data Size (1 octet), and Element Data (4 octets). If the Element Data is changed to reduce the length by one octet, and if the current length of the Element Data Size is less than its maximum permitted length, then the Element Data Size of that Element MAY be rewritten to increase its length by one octet. Thus, before and after the change, the EBML Element maintains the same length of 8 octets, and data around the Element does not need to be moved.
たとえば、表12の最初の行は、要素ID（3オクテット）、要素データサイズ（1オクテット）、および要素データ（4オクテット）を格納する文字列要素を示しています。要素データを変更して長さを1オクテット減らし、要素データサイズの現在の長さがその最大許容長さよりも短い場合、その要素の要素データサイズを書き換えて、長さを1オクテット増やすことができます。 。したがって、変更の前後で、EBML要素は8オクテットの同じ長さを維持し、要素の周りのデータを移動する必要はありません。
+=============+============+===================+==============+
| Status | Element ID | Element Data Size | Element Data |
+=============+============+===================+==============+
| Before edit | 0x3B4040 | 0x84 | 0x65626D6C |
+-------------+------------+-------------------+--------------+
| After edit | 0x3B4040 | 0x4003 | 0x6D6B76 |
+-------------+------------+-------------------+--------------+
Table 12: Example of editing a VINT to reduce VINT_DATA length by one octet
表12：VINTを編集してVINT_DATAの長さを1オクテット減らす例
This method is RECOMMENDED when the Element Data is reduced by a single octet; for reductions by two or more octets, it is RECOMMENDED to fill the freed space with a Void Element.
このメソッドは、要素データが1オクテット削減される場合に推奨されます。 2オクテット以上の削減の場合、解放されたスペースをVoid要素で埋めることをお勧めします。
Note that if the Element Data length needs to be rewritten as shortened by one octet and the Element Data Size could be rewritten as a shorter VINT, then it is RECOMMENDED to rewrite the Element Data Size as one octet shorter, shorten the Element Data by one octet, and follow that Element with a Void Element. For example, Table 13 depicts a String Element that stores an Element ID (3 octets), Element Data Size (2 octets, but could be rewritten in one octet), and Element Data (3 octets). If the Element Data is to be rewritten to a two-octet length, then another octet can be taken from Element Data Size so that there is enough space to add a two-octet Void Element.
要素データの長さを1オクテット短縮して書き換える必要があり、要素データサイズを短いVINTとして書き換えることができる場合は、要素データサイズを1オクテット短く書き換えて、要素データを1短くすることをお勧めします。オクテット、その要素の後にVoid要素を続けます。たとえば、表13は、要素ID（3オクテット）、要素データサイズ（2オクテットですが、1オクテットに書き換えることができます）、および要素データ（3オクテット）を格納する文字列要素を示しています。要素データを2オクテットの長さに書き換える場合は、要素データサイズから別のオクテットを取得して、2オクテットのVoid要素を追加するのに十分なスペースを確保できます。
+========+============+===================+==============+=========+
| Status | Element ID | Element Data Size | Element Data | Void |
| | | | | Element |
+========+============+===================+==============+=========+
| Before | 0x3B4040 | 0x4003 | 0x6D6B76 | |
+--------+------------+-------------------+--------------+---------+
| After | 0x3B4040 | 0x82 | 0x6869 | 0xEC80 |
+--------+------------+-------------------+--------------+---------+
Table 13: Example of editing a VINT to reduce VINT_DATA length by more than one octet
表13：VINTを編集してVINT_DATAの長さを1オクテット以上削減する例
For String Elements and UTF-8 Elements, the length of Element Data could be reduced by adding Null Octets to terminate the Element Data (see Section 13).
文字列要素とUTF-8要素の場合、要素データを終了するためにNullオクテットを追加することにより、要素データの長さを減らすことができます（セクション13を参照）。
In Table 14, Element Data four octets long is changed to a value three octets long, followed by a Null Octet; the Element Data Size includes any Null Octets used to terminate Element Data and therefore remains unchanged.
表14では、4オクテット長の要素データが3オクテット長の値に変更され、その後にヌルオクテットが続きます。要素データサイズには、要素データを終了するために使用されるすべてのヌルオクテットが含まれるため、変更されません。
+=============+============+===================+==============+
| Status | Element ID | Element Data Size | Element Data |
+=============+============+===================+==============+
| Before edit | 0x3B4040 | 0x84 | 0x65626D6C |
+-------------+------------+-------------------+--------------+
| After edit | 0x3B4040 | 0x84 | 0x6D6B7600 |
+-------------+------------+-------------------+--------------+
Table 14: Example of terminating VINT_DATA with a Null Octet when reducing VINT length during an edit
表14：編集中にVINTの長さを削減するときにヌルオクテットでVINT_DATAを終了する例
Note that this method is NOT RECOMMENDED. For reductions of one octet, the method for Extending the Element Data Size SHOULD be used. For reduction by more than one octet, the method for Adding a Void Element SHOULD be used.
この方法は推奨されないことに注意してください。 1オクテットの削減には、要素データサイズを拡張する方法を使用する必要があります（SHOULD）。複数のオクテットによる削減のために、ボイド要素を追加する方法を使用する必要があります。
14.2. Considerations when Updating Elements with Cyclic Redundancy Check (CRC)
14.2. 巡回冗長検査（CRC）で要素を更新する際の考慮事項
If the Element to be changed is a Descendant Element of any Master Element that contains a CRC-32 Element (see Section 11.3.1), then the CRC-32 Element MUST be verified before permitting the change. Additionally, the CRC-32 Element value MUST be subsequently updated to reflect the changed data.
変更する要素がCRC-32要素を含むマスター要素の子孫要素である場合（セクション11.3.1を参照）、変更を許可する前にCRC-32要素を検証する必要があります。さらに、CRC-32要素の値は、変更されたデータを反映するように後で更新する必要があります。
Elements of an EBML format SHOULD be designed with backward and forward compatibility in mind.
EBMLフォーマットの要素は、後方互換性と前方互換性を考慮して設計する必要があります（SHOULD）。
Backward compatibility of new EBML Elements can be achieved by using default values for mandatory elements. The default value MUST represent the state that was assumed for previous versions of the EBML Schema, without this new EBML Element. If such a state doesn't make sense for previous versions, then the new EBML Element SHOULD NOT be mandatory.
新しいEBML要素の下位互換性は、必須要素のデフォルト値を使用することで実現できます。デフォルト値は、この新しいEBML要素なしで、以前のバージョンのEBMLスキーマで想定されていた状態を表す必要があります。このような状態が以前のバージョンで意味をなさない場合、新しいEBML要素は必須ではありません（SHOULD NOT）。
Non-mandatory EBML Elements can be added in a new EBMLDocTypeVersion. Since they are not mandatory, they won't be found in older versions of the EBMLDocTypeVersion, just as they might not be found in newer versions. This causes no compatibility issue.
必須ではないEBML要素を新しいEBMLDocTypeVersionに追加できます。これらは必須ではないため、新しいバージョンでは見られない可能性があるのと同様に、EBMLDocTypeVersionの古いバージョンでは見られません。これにより、互換性の問題は発生しません。
EBML Elements MAY be marked as deprecated in a new EBMLDocTypeVersion using the "maxver" attribute of the EBML Schema. If such an Element is found in an EBML Document with a newer version of the EBMLDocTypeVersion, it SHOULD be discarded.
EBML要素は、EBMLスキーマの「maxver」属性を使用して、新しいEBMLDocTypeVersionで非推奨とマークされる場合があります。そのようなElementがEBMLDocTypeVersionの新しいバージョンのEBMLドキュメントで見つかった場合、それは破棄されるべきです（SHOULD）。
EBML itself does not offer any kind of security and does not provide confidentiality. EBML does not provide any kind of authorization. EBML only offers marginally useful and effective data integrity options, such as CRC elements.
EBML自体は、いかなる種類のセキュリティも提供せず、機密性も提供しません。 EBMLは、いかなる種類の承認も提供しません。 EBMLは、CRC要素など、わずかに有用で効果的なデータ整合性オプションのみを提供します。
Even if the semantic layer offers any kind of encryption, EBML itself could leak information at both the semantic layer (as declared via the DocType Element) and within the EBML structure (the presence of EBML Elements can be derived even with an unknown semantic layer using a heuristic approach -- not without errors, of course, but with a certain degree of confidence).
セマンティックレイヤーが何らかの種類の暗号化を提供している場合でも、EBML自体がセマンティックレイヤー（DocType要素を介して宣言されたもの）とEBML構造内（EBML要素の存在は、ヒューリスティックなアプローチ-もちろん、エラーがないわけではありませんが、ある程度の自信があります）。
An EBML Document that has the following issues may still be handled by the EBML Reader and the data accepted as such, depending on how strict the EBML Reader wants to be:
次の問題があるEBMLドキュメントは、EBMLリーダーがどの程度厳密になりたいかに応じて、EBMLリーダーおよびそのように受け入れられたデータによって引き続き処理される場合があります。
* Invalid Element IDs that are longer than the limit stated in the EBMLMaxIDLength Element of the EBML Header.
* EBMLヘッダーのEBMLMaxIDLength要素に記載されている制限よりも長い無効な要素ID。
* Invalid Element IDs that are not encoded in the shortest-possible way.
* 最短の方法でエンコードされていない無効なエレメントID。
* Invalid Element Data Size values that are longer than the limit stated in the EBMLMaxSizeLength Element of the EBML Header.
* EBMLヘッダーのEBMLMaxSizeLength要素に記載されている制限よりも長い無効な要素データサイズ値。
Element IDs that are unknown to the EBML Reader MAY be accepted as valid EBML IDs in order to skip such elements.
EBMLリーダーにとって未知の要素IDは、そのような要素をスキップするために、有効なEBML IDとして受け入れられる場合があります。
EBML Elements with a string type may contain extra data after the first 0x00. These data MUST be discarded according to the Section 13 rules.
文字列タイプのEBML要素には、最初の0x00の後に追加のデータが含まれる場合があります。これらのデータは、セクション13の規則に従って破棄する必要があります。
An EBML Reader may discard some or all data if the following errors are found in the EBML Document:
EBMLドキュメントで次のエラーが見つかった場合、EBMLリーダーは一部またはすべてのデータを破棄することがあります。
* Invalid Element Data Size values (e.g., extending the length of the EBML Element beyond the scope of the Parent Element, possibly triggering access-out-of-bounds issues).
* 無効な要素データサイズ値（例：EBML要素の長さを親要素の範囲を超えて拡張し、境界外のアクセスの問題を引き起こす可能性があります）。
* Very high lengths in order to force out-of-memory situations resulting in a denial of service, access-out-of-bounds issues, etc.
* メモリー不足の状況を引き起こしてサービス拒否や境界外のアクセスの問題などを引き起こすために非常に長い長さ
* Missing EBML Elements that are mandatory in a Master Element and have no declared default value, making the semantic invalid at that Master Element level.
* マスター要素で必須であり、宣言されたデフォルト値がないEBML要素がないため、そのマスター要素レベルではセマンティックが無効になります。
* Usage of invalid UTF-8 encoding in EBML Elements of UTF-8 type (e.g., in order to trigger access-out-of-bounds or buffer-overflow issues).
* UTF-8タイプのEBML要素での無効なUTF-8エンコーディングの使用（たとえば、範囲外のアクセスまたはバッファーオーバーフローの問題をトリガーするため）。
* Usage of invalid data in EBML Elements with a date type, triggering bogus date accesses.
* 日付タイプを持つEBML要素での無効なデータの使用により、偽の日付アクセスがトリガーされます。
* The CRC-32 Element (see Section 11.3.1) of a Master Element doesn't match the rest of the content of that Master Element.
* マスターエレメントのCRC-32エレメント（セクション11.3.1を参照）が、そのマスターエレメントの残りのコンテンツと一致しません。
Side-channel attacks could exploit:
サイドチャネル攻撃は、以下を悪用する可能性があります。
* The semantic equivalence of the same string stored in a String Element or UTF-8 Element with and without zero-bit padding, making comparison at the semantic level invalid.
* 文字列要素またはUTF-8要素に格納された同じ文字列の意味論的同等性。ゼロビットパディングありとなしで、意味論レベルでの比較を無効にします。
* The semantic equivalence of VINT_DATA within Element Data Size with two different lengths due to left-padding zero bits, making comparison at the semantic level invalid.
* 左パディングのゼロビットによる2つの異なる長さのElement Data Size内のVINT_DATAのセマンティック同等性。セマンティックレベルでの比較を無効にします。
* Data contained within a Master Element that is not itself part of a Child Element, which can trigger incorrect parsing behavior in EBML Readers.
* それ自体が子要素の一部ではないマスター要素内に含まれるデータ。EBMLリーダーで誤った解析動作をトリガーする可能性があります。
* Extraneous copies of Identically Recurring Element, making parsing unnecessarily slow to the point of not being usable.
* Identically Recurring Elementの余分なコピー。解析が不必要に遅くなり、使用できなくなります。
* Copies of Identically Recurring Element within a Parent Element that contain invalid CRC-32 Elements. EBML Readers not checking the CRC-32 might use the version of the element with mismatching CRC-32s.
* 無効なCRC-32要素を含む親要素内の同一に繰り返される要素のコピー。 CRC-32をチェックしないEBMLリーダーは、CRC-32が一致しない要素のバージョンを使用する場合があります。
* Use of Void Elements that could be used to hide content or create bogus resynchronization points seen by some EBML Readers and not others.
* コンテンツを非表示にしたり、一部のEBMLリーダーで見られる偽の再同期ポイントを作成したりするために使用できるVoid要素の使用。
This document creates a new IANA registry called the "EBML Element IDs" registry.
このドキュメントは、「EBML Element IDs」レジストリと呼ばれる新しいIANAレジストリを作成します。
Element IDs are described in Section 5. Element IDs are encoded using the VINT mechanism described in Section 4 and can be between one and five octets long. Five-octet-long Element IDs are possible only if declared in the header.
要素IDについては、セクション5で説明します。要素IDは、セクション4で説明したVINTメカニズムを使用してエンコードされ、1〜5オクテットの長さにできます。 5オクテット長のエレメントIDは、ヘッダーで宣言されている場合にのみ可能です。
This IANA registry only applies to Elements that can be contained in the EBML Header, thus including Global Elements. Elements only found in the EBML Body have their own set of independent Element IDs and are not part of this IANA registry.
このIANAレジストリは、EBMLヘッダーに含めることができる要素にのみ適用されるため、グローバル要素が含まれます。 EBML本体でのみ見つかる要素には、独自の独立した要素IDのセットがあり、このIANAレジストリの一部ではありません。
One-octet Element IDs MUST be between 0x81 and 0xFE. These items are valuable because they are short, and they need to be used for commonly repeated elements. Element IDs are to be allocated within this range according to the "RFC Required" policy [RFC8126].
1オクテットの要素IDは0x81から0xFEの間でなければなりません。これらのアイテムは短いので価値があり、一般的に繰り返される要素に使用する必要があります。エレメントIDは、「RFC必須」ポリシー[RFC8126]に従って、この範囲内で割り当てられます。
The following one-octet Element IDs are RESERVED: 0xFF and 0x80.
次の1オクテットの要素IDが予約されています：0xFFおよび0x80。
Values in the one-octet range of 0x00 to 0x7F are not valid for use as an Element ID.
1オクテットの範囲0x00〜0x7Fの値は、要素IDとしての使用には無効です。
Two-octet Element IDs MUST be between 0x407F and 0x7FFE. Element IDs are to be allocated within this range according to the "Specification Required" policy [RFC8126].
2オクテットの要素IDは0x407Fと0x7FFEの間でなければなりません。要素IDは、「Specification Required」ポリシー[RFC8126]に従ってこの範囲内で割り当てられます。
The following two-octet Element IDs are RESERVED: 0x7FFF and 0x4000.
次の2オクテットの要素IDが予約されています：0x7FFFおよび0x4000。
Values in the two-octet ranges of 0x0000 to 0x3FFF and 0x8000 to 0xFFFF are not valid for use as an Element ID.
2オクテットの範囲0x0000〜0x3FFFおよび0x8000〜0xFFFFの値は、要素IDとしての使用には無効です。
Three-octet Element IDs MUST be between 0x203FFF and 0x3FFFFE. Element IDs are to be allocated within this range according to the "First Come First Served" policy [RFC8126].
3オクテットの要素IDは0x203FFFと0x3FFFFEの間でなければなりません。要素IDは、「先着順」ポリシー[RFC8126]に従って、この範囲内で割り当てられます。
The following three-octet Element IDs are RESERVED: 0x3FFFFF and 0x200000.
次の3オクテットの要素IDが予約されています：0x3FFFFFおよび0x200000。
Values in the three-octet ranges of 0x000000 to 0x1FFFFF and 0x400000 to 0xFFFFFF are not valid for use as an Element ID.
3オクテットの範囲0x000000〜0x1FFFFFおよび0x400000〜0xFFFFFFの値は、要素IDとしての使用には無効です。
Four-octet Element IDs MUST be between 0x101FFFFF and 0x1FFFFFFE. Four-octet Element IDs are somewhat special in that they are useful for resynchronizing to major structures in the event of data corruption or loss. As such, four-octet Element IDs are split into two categories. Four-octet Element IDs whose lower three octets (as encoded) would make printable 7-bit ASCII values (0x20 to 0x7E, inclusive) MUST be allocated by the "Specification Required" policy. Sequential allocation of values is not required: specifications SHOULD include a specific request and are encouraged to do early allocations.
4オクテットの要素IDは0x101FFFFFと0x1FFFFFFEの間でなければなりません。 4オクテットのエレメントIDは、データが破損または損失した場合に主要な構造に再同期するのに役立つという点で、やや特殊です。そのため、4オクテットの要素IDは2つのカテゴリに分割されます。下位3オクテット（エンコードされた状態）が印刷可能な7ビットASCII値（0x20〜0x7Eを含む）となる4オクテットの要素IDは、「Specification Required」ポリシーによって割り当てられる必要があります。値の順次割り当ては必要ありません。仕様には特定のリクエストを含める必要があり（SHOULD）、早期割り当てを行うことをお勧めします。
To be clear about the above category: four-octet Element IDs always start with hex 0x10 to 0x1F, and that octet may be chosen so that the entire VINT has some desirable property, such as a specific CRC. The other three octets, when ALL having values between 0x20 (32, ASCII Space) and 0x7E (126, ASCII "~"), fall into this category.
上記のカテゴリを明確にするために、4オクテットの要素IDは常に16進数の0x10から0x1Fで始まり、そのオクテットは、VINT全体が特定のCRCなどの望ましいプロパティを持つように選択できます。他の3つのオクテットは、ALLが0x20（32、ASCIIスペース）と0x7E（126、ASCII "〜"）の間の値を持つ場合、このカテゴリに分類されます。
Other four-octet Element IDs may be allocated by the "First Come First Served" policy.
他の4オクテットの要素IDは、「先着順」ポリシーによって割り当てられます。
The following four-octet Element IDs are RESERVED: 0x1FFFFFFF and 0x10000000.
次の4オクテットの要素IDが予約されています：0x1FFFFFFFおよび0x10000000。
Values in the four-octet ranges of 0x00000000 to 0x0FFFFFFF and 0x20000000 to 0xFFFFFFFF are not valid for use as an Element ID.
0x00000000〜0x0FFFFFFFおよび0x20000000〜0xFFFFFFFFの4オクテット範囲の値は、要素IDとしての使用には無効です。
Five-octet Element IDs (values from 0x080FFFFFFF to 0x0FFFFFFFFE) are RESERVED according to the "Experimental Use" policy [RFC8126]: they may be used by anyone at any time, but there is no coordination.
5オクテットの要素ID（値0x080FFFFFFF〜0x0FFFFFFFFE）は、「実験的使用」ポリシー[RFC8126]に従って予約されています。これらはいつでも誰でも使用できますが、調整はありません。
ID Values found in this document are assigned as initial values as follows:
このドキュメントにあるID値は、次のように初期値として割り当てられます。
+============+=========================+=================+
| Element ID | Element Name | Reference |
+============+=========================+=================+
| 0x1A45DFA3 | EBML | Described in |
| | | Section 11.2.1 |
+------------+-------------------------+-----------------+
| 0x4286 | EBMLVersion | Described in |
| | | Section 11.2.2 |
+------------+-------------------------+-----------------+
| 0x42F7 | EBMLReadVersion | Described in |
| | | Section 11.2.3 |
+------------+-------------------------+-----------------+
| 0x42F2 | EBMLMaxIDLength | Described in |
| | | Section 11.2.4 |
+------------+-------------------------+-----------------+
| 0x42F3 | EBMLMaxSizeLength | Described in |
| | | Section 11.2.5 |
+------------+-------------------------+-----------------+
| 0x4282 | DocType | Described in |
| | | Section 11.2.6 |
+------------+-------------------------+-----------------+
| 0x4287 | DocTypeVersion | Described in |
| | | Section 11.2.7 |
+------------+-------------------------+-----------------+
| 0x4285 | DocTypeReadVersion | Described in |
| | | Section 11.2.8 |
+------------+-------------------------+-----------------+
| 0x4281 | DocTypeExtension | Described in |
| | | Section 11.2.9 |
+------------+-------------------------+-----------------+
| 0x4283 | DocTypeExtensionName | Described in |
| | | Section 11.2.10 |
+------------+-------------------------+-----------------+
| 0x4284 | DocTypeExtensionVersion | Described in |
| | | Section 11.2.11 |
+------------+-------------------------+-----------------+
| 0xBF | CRC-32 | Described in |
| | | Section 11.3.1 |
+------------+-------------------------+-----------------+
| 0xEC | Void | Described in |
| | | Section 11.3.2 |
+------------+-------------------------+-----------------+
Table 15: IDs and Names for EBML Elements assigned by this document
表15：このドキュメントによって割り当てられたEBML要素のIDと名前
This document creates a new IANA registry called the "EBML DocTypes" registry.
このドキュメントは、「EBML DocTypes」レジストリと呼ばれる新しいIANAレジストリを作成します。
To register a new DocType in this registry, one needs a DocType name, a Description of the DocType, a Change Controller (IESG or email of registrant), and an optional Reference to a document describing the DocType.
このレジストリに新しいDocTypeを登録するには、DocType名、DocTypeの説明、変更コントローラ（IESGまたは登録者の電子メール）、およびDocTypeを説明するドキュメントへのオプションの参照が必要です。
DocType values are described in Section 11.1.4.1. DocTypes are ASCII strings, defined in Section 7.4, which label the official name of the EBML Document Type. The strings may be allocated according to the "First Come First Served" policy.
DocType値については、11.1.4.1項で説明しています。 DocTypeは、セクション7.4で定義されているASCII文字列で、EBMLドキュメントタイプの正式名を示します。文字列は、「先着順」ポリシーに従って割り当てられます。
The use of ASCII corresponds to the types and code already in use; the value is not meant to be visible to the user.
ASCIIの使用は、すでに使用されているタイプとコードに対応しています。この値は、ユーザーに表示されることを意図していません。
DocType string values of "matroska" and "webm" are RESERVED to the IETF for future use. These can be assigned via the "IESG Approval" or "RFC Required" policies [RFC8126].
「matroska」および「webm」のDocType文字列値は、将来の使用のためにIETFに予約されています。これらは、「IESG承認」または「RFC必須」ポリシー[RFC8126]を介して割り当てることができます。
[IEEE.754] IEEE, "IEEE Standard for Binary Floating-Point Arithmetic", 13 June 2019, <https://standards.ieee.org/standard/754-2019.html>.
[IEEE.754] IEEE、「バイナリ浮動小数点演算のIEEE標準」、2019年6月13日、<https://standards.ieee.org/standard/754-2019.html>。
[ISO3309] International Organization for Standardization, "Data communication -- High-level data link control procedures -- Frame structure", ISO 3309, 3rd Edition, October 1984, <https://www.iso.org/standard/8558.html>.
[ISO3309]国際標準化機構、「データ通信-高レベルデータリンク制御手順-フレーム構造」、ISO 3309、第3版、1984年10月、<https://www.iso.org/standard/8558。 html>。
[ISO9899] International Organization for Standardization, "Information technology -- Programming languages -- C", ISO/IEC 9899:2011, 2011, <https://www.iso.org/standard/57853.html>.
[ISO9899]国際標準化機構、「情報技術-プログラミング言語-C」、ISO / IEC 9899：2011、2011、<https://www.iso.org/standard/57853.html>。
[ITU.V42] International Telecommunications Union, "Error-correcting procedures for DCEs using asynchronous-to-synchronous conversion", ITU-T Recommendation V.42, March 2002, <https://www.itu.int/rec/T-REC-V.42>.
[ITU.V42]国際電気通信連合、「非同期から同期への変換を使用したDCEのエラー修正手順」、ITU-T勧告V.42、2002年3月、<https://www.itu.int/rec/T -REC-V.42>。
[RFC0020] Cerf, V., "ASCII format for network interchange", STD 80, RFC 20, DOI 10.17487/RFC0020, October 1969, <https://www.rfc-editor.org/info/rfc20>.
[RFC0020] Cerf、V。、「ネットワーク交換用のASCII形式」、STD 80、RFC 20、DOI 10.17487 / RFC0020、1969年10月、<https://www.rfc-editor.org/info/rfc20>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC2648] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, DOI 10.17487/RFC2648, August 1999, <https://www.rfc-editor.org/info/rfc2648>.
[RFC2648] Moats、R。、「IETFドキュメントのURN名前空間」、RFC 2648、DOI 10.17487 / RFC2648、1999年8月、<https://www.rfc-editor.org/info/rfc2648>。
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, <https://www.rfc-editor.org/info/rfc3339>.
[RFC3339]クライン、G、およびC.ニューマン、「インターネット上の日付と時刻：タイムスタンプ」、RFC 3339、DOI 10.17487 / RFC3339、2002年7月、<https://www.rfc-editor.org/info/rfc3339 >。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <https://www.rfc-editor.org/info/rfc3629>.
[RFC3629] Yergeau、F。、「UTF-8、ISO 10646の変換フォーマット」、STD 63、RFC 3629、DOI 10.17487 / RFC3629、2003年11月、<https://www.rfc-editor.org/info/ rfc3629>。
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, <https://www.rfc-editor.org/info/rfc3688>.
[RFC3688] Mealling、M。、「The IETF XML Registry」、BCP 81、RFC 3688、DOI 10.17487 / RFC3688、2004年1月、<https://www.rfc-editor.org/info/rfc3688>。
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.
[RFC5234]クロッカー、D。、エド。およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、DOI 10.17487 / RFC5234、2008年1月、<https://www.rfc-editor.org/info/rfc5234>。
[RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, September 2009, <https://www.rfc-editor.org/info/rfc5646>.
[RFC5646]フィリップス、A。、エド。 M.デイビス編、「言語を識別するためのタグ」、BCP 47、RFC 5646、DOI 10.17487 / RFC5646、2009年9月、<https://www.rfc-editor.org/info/rfc5646>。
[RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", RFC 7405, DOI 10.17487/RFC7405, December 2014, <https://www.rfc-editor.org/info/rfc7405>.
[RFC7405] Kyzivat、P。、「ABNFでの大文字と小文字を区別する文字列のサポート」、RFC 7405、DOI 10.17487 / RFC7405、2014年12月、<https://www.rfc-editor.org/info/rfc7405>。
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]コットン、M。、レイバ、B。、およびT.ナルテン、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<https：// www .rfc-editor.org / info / rfc8126>。
[RFC8141] Saint-Andre, P. and J. Klensin, "Uniform Resource Names (URNs)", RFC 8141, DOI 10.17487/RFC8141, April 2017, <https://www.rfc-editor.org/info/rfc8141>.
[RFC8141] Saint-Andre、P。およびJ. Klensin、「Uniform Resource Names（URNs）」、RFC 8141、DOI 10.17487 / RFC8141、2017年4月、<https://www.rfc-editor.org/info/rfc8141 >。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[XHTML] McCarron, S., "XHTML(tm) Basic 1.1 -- Second Edition", Latest version available at https://www.w3.org/TR/xhtml-basic, 27 March 2018, <https://www.w3.org/TR/2018/SPSD-xhtml-basic-20180327/>.
[XHTML] McCarron、S。、「XHTML（tm）Basic 1.1-Second Edition」、最新バージョンはhttps://www.w3.org/TR/xhtml-basicで入手可能、2018年3月27日、<https：// www.w3.org/TR/2018/SPSD-xhtml-basic-20180327/>。
[XML] Bray, T., Ed., Paoli, J., Ed., Sperberg-McQueen, C.M., Ed., Maler, E., Ed., and F. Yergeau, Ed., "Extensible Markup Language (XML) 1.0 (Fifth Edition)", Latest version available at https://www.w3.org/TR/xml/, 26 November 2008, <https://www.w3.org/TR/2008/REC-xml-20081126/>.
[XML] Bray、T。、編、Paoli、J。、編、Sperberg-McQueen、CM、編、Maler、編、およびF. Yergeau、編、「Extensible Markup Language（XML ）1.0（第5版）」、最新バージョンはhttps://www.w3.org/TR/xml/、2008年11月26日、<https://www.w3.org/TR/2008/REC-xml-で入手可能20081126 />。
[XML-SCHEMA] Fallside, D.C. and P. Walmsley, "XML Schema Part 0: Primer Second Edition", Latest version available at http://www.w3.org/TR/xmlschema-0/, 28 October 2004, <https://www.w3.org/TR/2004/REC-xmlschema-0-20041028/>.
[XML-SCHEMA] Fallside、DC and P. Walmsley、 "XML Schema Part 0：Primer Second Edition"、http://www.w3.org/TR/xmlschema-0/で入手可能な最新バージョン、2004年10月28日、< https://www.w3.org/TR/2004/REC-xmlschema-0-20041028/>。
[Matroska] Lhomme, S., Bunkus, M., and D. Rice, "Matroska Media Container Format Specifications", Work in Progress, Internet-Draft, draft-ietf-cellar-matroska-05, 17 April 2020, <https://tools.ietf.org/html/draft-ietf-cellar-matroska-05>.
[Matroska] Lhomme、S.、Bunkus、M。、およびD. Rice、「Matroska Media Container Format Specifications」、Work in Progress、Internet-Draft、draft-ietf-cellar-matroska-05、2020年4月17日、<https ：//tools.ietf.org/html/draft-ietf-cellar-matroska-05>。
[WebM] The WebM Project, "WebM Container Guidelines", 28 November 2017, <https://www.webmproject.org/docs/container/>.
[WebM] WebMプロジェクト、「WebMコンテナガイドライン」、2017年11月28日、<https://www.webmproject.org/docs/container/>。
[XPath] Clark, J., Ed. and S. DeRose, "XML Path Language (XPath) Version 1.0", Latest version available at https://www.w3.org/TR/xpath, 16 November 1999, <https://www.w3.org/TR/1999/REC-xpath-19991116>.
[XPath]クラーク、J、エド。およびS. DeRose、「XML Path Language（XPath）Version 1.0」、https：//www.w3.org/TR/xpath、1999年11月16日、<https://www.w3.org/TRで入手可能な最新バージョン/ 1999 / REC-xpath-19991116>。
Authors' Addresses
著者のアドレス
Steve Lhomme
スティーブ・ロム
Email: slhomme@matroska.org
Dave Rice
デイブ・ライス
Email: dave@dericed.com
Moritz Bunkus
モリッツ・ブンクス
Email: moritz@bunkus.org