[要約] RFC 6110は、YANGデータモデルをドキュメントスキーマ定義言語にマッピングし、NETCONFコンテンツを検証するためのガイドラインを提供しています。目的は、YANGデータモデルのドキュメント化と検証のための標準的な手法を提供することです。
Internet Engineering Task Force (IETF) L. Lhotka, Ed.
Request for Comments: 6110 CESNET
Category: Standards Track February 2011
ISSN: 2070-1721
Mapping YANG to Document Schema Definition Languages and Validating NETCONF Content
スキーマ定義言語を文書化するためのYangのマッピングとNetConfコンテンツの検証
Abstract
概要
This document specifies the mapping rules for translating YANG data models into Document Schema Definition Languages (DSDL), a coordinated set of XML schema languages standardized as ISO/IEC 19757. The following DSDL schema languages are addressed by the mapping: Regular Language for XML Next Generation (RELAX NG), Schematron, and Schematron and Document Schema Renaming Language (DSRL). The mapping takes one or more YANG modules and produces a set of DSDL schemas for a selected target document type -- datastore content, Network Configuration Protocol (NETCONF) messages, etc. Procedures for schema-based validation of such documents are also discussed.
このドキュメントは、YangデータモデルをISO/IEC 19757として標準化されたXMLスキーマ言語の調整されたセットであるドキュメントスキーマ定義言語（DSDL）に変換するためのマッピングルールを指定しています。ジェネレーション（リラックスNG）、スキーマトロン、およびスキーマトロンおよび文書スキーマの名前を変更する言語（DSRL）。マッピングは、1つ以上のYangモジュールを採取し、選択したターゲットドキュメントタイプ（データストアコンテンツ、ネットワーク構成プロトコル（NetConf）メッセージなどのDSDLスキーマのセットを生成します。このようなドキュメントのスキーマベースの検証の手順についても説明します。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
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 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 5741のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6110.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6110で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction ....................................................5
2. Terminology and Notation ........................................6
2.1. Glossary of New Terms ......................................9
3. Objectives and Motivation ......................................10
4. DSDL Schema Languages ..........................................11
4.1. RELAX NG ..................................................11
4.2. Schematron ................................................12
4.3. Document Semantics Renaming Language (DSRL) ...............13
5. Additional Annotations .........................................14
5.1. Dublin Core Metadata Elements .............................14
5.2. RELAX NG DTD Compatibility Annotations ....................14
5.3. NETMOD-Specific Annotations ...............................15
6. Overview of the Mapping ........................................16
7. NETCONF Content Validation .....................................18
8. Design Considerations ..........................................19
8.1. Hybrid Schema .............................................19
8.2. Modularity ................................................22
8.3. Granularity ...............................................23
8.4. Handling of XML Namespaces ................................24
9. Mapping YANG Data Models to the Hybrid Schema ..................25
9.1. Occurrence Rules for Data Nodes ...........................25
9.1.1. Optional and Mandatory Nodes .......................26
9.1.2. Implicit Nodes .....................................27
9.2. Mapping YANG Groupings and Typedefs .......................28
9.2.1. YANG Refinements and Augments ......................29
9.2.2. Type Derivation Chains .............................32
9.3. Translation of XPath Expressions ..........................35
9.4. YANG Language Extensions ..................................36
10. Mapping YANG Statements to the Hybrid Schema ..................37
10.1. The 'anyxml' Statement ...................................37
10.2. The 'argument' Statement .................................38
10.3. The 'augment' Statement ..................................39
10.4. The 'base' Statement .....................................39
10.5. The 'belongs-to' Statement ...............................39
10.6. The 'bit' Statement ......................................39
10.7. The 'case' Statement .....................................39
10.8. The 'choice' Statement ...................................39
10.9. The 'config' Statement ...................................40
10.10. The 'contact' Statement .................................40
10.11. The 'container' Statement ...............................40
10.12. The 'default' Statement .................................40
10.13. The 'description' Statement .............................42
10.14. The 'deviation' Statement ...............................42
10.15. The 'enum' Statement ....................................42
10.16. The 'error-app-tag' Statement ...........................42
10.17. The 'error-message' Statement ...........................42
10.18. The 'extension' Statement ...............................43
10.19. The 'feature' Statement .................................43
10.20. The 'grouping' Statement ................................43
10.21. The 'identity' Statement ................................43
10.22. The 'if-feature' Statement ..............................45
10.23. The 'import' Statement ..................................45
10.24. The 'include' Statement .................................45
10.25. The 'input' Statement ...................................46
10.26. The 'key' Statement .....................................46
10.27. The 'leaf' Statement ....................................46
10.28. The 'leaf-list' Statement ...............................46
10.29. The 'length' Statement ..................................47
10.30. The 'list' Statement ....................................47
10.31. The 'mandatory' Statement ...............................48
10.32. The 'max-elements' Statement ............................49
10.33. The 'min-elements' Statement ............................49
10.34. The 'module' Statement ..................................49
10.35. The 'must' Statement ....................................49
10.36. The 'namespace' Statement ...............................50
10.37. The 'notification' Statement ............................50
10.38. The 'ordered-by' Statement ..............................50
10.39. The 'organization' Statement ............................50
10.40. The 'output' Statement ..................................51
10.41. The 'path' Statement ....................................51
10.42. The 'pattern' Statement .................................51
10.43. The 'position' Statement ................................51
10.44. The 'prefix' Statement ..................................51
10.45. The 'presence' Statement ................................51
10.46. The 'range' Statement ...................................51
10.47. The 'reference' Statement ...............................51
10.48. The 'require-instance' Statement ........................51
10.49. The 'revision' Statement ................................52
10.50. The 'rpc' Statement .....................................52
10.51. The 'status' Statement ..................................52
10.52. The 'submodule' Statement ...............................52
10.53. The 'type' Statement ....................................53
10.53.1. The "empty" Type .................................54
10.53.2. The "boolean" Type ...............................54
10.53.3. The "binary" Type ................................54
10.53.4. The "bits" Type ..................................54
10.53.5. The "enumeration" and "union" Types ..............54
10.53.6. The "identityref" Type ...........................54
10.53.7. The "instance-identifier" Type ...................55
10.53.8. The "leafref" Type ...............................55
10.53.9. The Numeric Types ................................55
10.53.10. The "string" Type ...............................57
10.53.11. Derived Types ...................................58
10.54. The 'typedef' Statement .................................59
10.55. The 'unique' Statement ..................................59
10.56. The 'units' Statement ...................................60
10.57. The 'uses' Statement ....................................60
10.58. The 'value' Statement ...................................60
10.59. The 'when' Statement ....................................60
10.60. The 'yang-version' Statement ............................60
10.61. The 'yin-element' Statement .............................61
11. Mapping the Hybrid Schema to DSDL .............................61
11.1. Generating RELAX NG Schemas for Various Document Types ...61
11.2. Mapping Semantic Constraints to Schematron ...............62
11.2.1. Constraints on Mandatory Choice ...................65
11.3. Mapping Default Values to DSRL ...........................67
12. Mapping NETMOD-Specific Annotations to DSDL Schema Languages ..71
12.1. The @nma:config Annotation ...............................71
12.2. The @nma:default Annotation ..............................71
12.3. The <nma:error-app-tag> Annotation .......................71
12.4. The <nma:error-message> Annotation .......................71
12.5. The @if-feature Annotation ...............................71
12.6. The @nma:implicit Annotation .............................72
12.7. The <nma:instance-identifier> Annotation .................72
12.8. The @nma:key Annotation ..................................72
12.9. The @nma:leaf-list Annotation ............................72
12.10. The @nma:leafref Annotation .............................73
12.11. The @nma:min-elements Annotation ........................73
12.12. The @nma:max-elements Annotation ........................73
12.13. The <nma:must> Annotation ...............................73
12.14. The <nma:ordered-by> Annotation .........................74
12.15. The <nma:status> Annotation .............................74
12.16. The @nma:unique Annotation ..............................74
12.17. The @nma:when Annotation ................................74
13. IANA Considerations ...........................................75
14. Security Considerations .......................................75
15. Contributors ..................................................75
16. Acknowledgments ...............................................76
17. References ....................................................76
17.1. Normative References .....................................76
17.2. Informative References ...................................77
Appendix A. RELAX NG Schema for NETMOD-Specific Annotations .......79
Appendix B. Schema-Independent Library ............................84
Appendix C. Mapping DHCP Data Model - A Complete Example ..........85
C.1. Input YANG Module .........................................85
C.2. Hybrid Schema .............................................88
C.3. Final DSDL Schemas .......................................93
C.3.1. Main RELAX NG Schema for <nc:get> Reply ............93
C.3.2. RELAX NG Schema - Global Named Pattern
Definitions ........................................95
C.3.3. Schematron Schema for <nc:get> Reply ...............98
C.3.4. DSRL Schema for <nc:get> Reply .....................99
The NETCONF Working Group has completed a base protocol used for configuration management [RFC4741]. This base specification defines protocol bindings and an XML container syntax for configuration and management operations, but does not include a data modeling language or accompanying rules for how to model configuration and state information carried by NETCONF. The IETF Operations Area has a long tradition of defining data for Simple Network Management Protocol (SNMP) Management Information Bases (MIB) modules [RFC1157] using the Structure of Management Information (SMI) language [RFC2578] to model its data. While this specific modeling approach has a number of well-understood problems, most of the data modeling features provided by SMI are still considered extremely important. Simply modeling the valid syntax without the additional semantic relationships has caused significant interoperability problems in the past.
NetConfワーキンググループは、構成管理に使用される基本プロトコルを完了しました[RFC4741]。このベース仕様は、構成および管理操作のプロトコルバインディングとXMLコンテナ構文を定義しますが、NetConfが運ぶ構成と状態情報をモデル化する方法に関するデータモデリング言語または付随するルールは含まれていません。IETF操作領域には、管理情報の構造（SMI）言語[RFC2578]の構造を使用して、単純なネットワーク管理プロトコル（SNMP）管理情報ベース（MIB）モジュール[RFC1157]のデータを定義する長い伝統があります。この特定のモデリングアプローチには、よく理解されている多くの問題がありますが、SMIが提供するデータモデリング機能のほとんどは依然として非常に重要であると考えられています。追加のセマンティック関係なしで有効な構文をモデル化するだけで、過去に重大な相互運用性の問題を引き起こしました。
The NETCONF community concluded that a data modeling framework is needed to support ongoing development of IETF and vendor-defined management information modules. The NETMOD Working Group was chartered to design a modeling language defining the semantics of operational data, configuration data, event notifications, and operations, with focus on "human-friendliness", i.e., readability and ease of use. The result is the YANG data modeling language [RFC6020], which now serves for the normative description of NETCONF data models.
NetConfコミュニティは、IETFおよびベンダー定義の管理情報モジュールの継続的な開発をサポートするために、データモデリングフレームワークが必要であると結論付けました。NetModワーキンググループは、「人間に優しい」、つまり読みやすさと使いやすさに焦点を当てて、運用データ、構成データ、イベント通知、および操作のセマンティクスを定義するモデリング言語を設計するためにチャーターされました。その結果、Yang Data Modeling Language [RFC6020]ができました。これは、NetConfデータモデルの規範的な説明に役立ちます。
Since NETCONF uses XML for encoding its messages, it is natural to express the constraints on NETCONF content using standard XML schema languages. For this purpose, the NETMOD WG selected the Document Schema Definition Languages (DSDL) that is being standardized as ISO/IEC 19757 [DSDL]. The DSDL framework comprises a set of XML schema languages that address grammar rules, semantic constraints, and other data modeling aspects, but also, and more importantly, do it in a coordinated and consistent way. While it is true that some DSDL parts have not been standardized yet and are still work in progress, the three parts that the YANG-to-DSDL mapping relies upon -- Regular Language for XML Next Generation (RELAX NG), Schematron and Document Schema Renaming Language (DSRL) -- already have the status of an ISO/ IEC International Standard and are supported in a number of software tools.
NetConfはメッセージをエンコードするためにXMLを使用するため、標準のXMLスキーマ言語を使用してNetConfコンテンツの制約を表現することは自然です。この目的のために、NetMod WGは、ISO/IEC 19757 [DSDL]として標準化されているドキュメントスキーマ定義言語（DSDL）を選択しました。DSDLフレームワークは、文法ルール、セマンティック制約、およびその他のデータモデリングの側面に対処する一連のXMLスキーマ言語で構成されていますが、さらに重要なことには、調整された一貫した方法で行うことです。一部のDSDL部品はまだ標準化されておらず、まだ進行中の作業中であることは事実ですが、Yang-to-DSDLマッピングが依存している3つのパート - XML Next Generation（Relax Ng）、Schematron、Document Schemaの正規言語言語の改名（DSRL） - すでにISO/ IEC国際標準のステータスを持っており、多くのソフトウェアツールでサポートされています。
This document contains a specification of a mapping that translates YANG data models to XML schemas utilizing a subset of the DSDL schema languages. The mapping procedure is divided into two steps: In the first step, the structure of the data tree, signatures of remote procedure call (RPC) operations, and notifications are expressed as the so-called "hybrid schema" -- a single RELAX NG schema with annotations representing additional data model information (metadata, documentation, semantic constraints, default values, etc.). The second step then generates a coordinated set of DSDL schemas that can be used for validating specific XML documents such as client requests, server responses or notifications, perhaps also taking into account additional context such as active capabilities or features.
このドキュメントには、YangデータモデルをDSDLスキーマ言語のサブセットを使用してXMLスキーマに変換するマッピングの仕様が含まれています。マッピング手順は2つのステップに分けられます。最初のステップでは、データツリーの構造、リモートプロシージャコール（RPC）操作の署名、および通知がいわゆる「ハイブリッドスキーマ」として表されます。追加のデータモデル情報（メタデータ、ドキュメント、セマンティック制約、デフォルト値など）を表す注釈付きスキーマ。2番目のステップでは、クライアント要求、サーバー応答、通知などの特定のXMLドキュメントを検証するために使用できるDSDLスキーマの調整されたセットを生成します。おそらく、アクティブな機能や機能などの追加のコンテキストを考慮しています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
The following terms are defined in [RFC4741]:
次の用語は[RFC4741]で定義されています。
o client
o クライアント
o datastore
o データストア
o message
o メッセージ
o operation
o 手術
o server
o サーバ
The following terms are defined in [RFC6020]:
次の用語は[RFC6020]で定義されています。
o augment
o 増強
o base type
o ベースタイプ
o built-in type o configuration data
o 組み込みタイプo構成データ
o container
o 容器
o data model
o データ・モデル
o data node
o データノード
o data tree
o データツリー
o derived type
o 派生タイプ
o device deviation
o デバイスの偏差
o extension
o 拡大
o feature
o 特徴
o grouping
o グループ化
o instance identifier
o インスタンス識別子
o leaf-list
o リーフリスト
o list
o リスト
o mandatory node
o 必須ノード
o module
o モジュール
o RPC
o RPC
o RPC operation
o RPC操作
o schema node
o スキーマノード
o schema tree
o スキーマツリー
o state data
o 状態データ
o submodule
o サブモジュール
o top-level data node
o トップレベルのデータノード
o uses The following terms are defined in [XML-INFOSET]:
o 次の用語は[xml-infoset]で定義されています。
o attribute
o 属性
o document
o 資料
o document element
o ドキュメント要素
o document type declaration (DTD)
o ドキュメントタイプ宣言（DTD）
o element
o エレメント
o information set
o 情報セット
o namespace
o 名前空間
In the text, the following typographic conventions are used:
テキストでは、次のタイポグラフィの規則が使用されています。
o YANG statement keywords are delimited by single quotes.
o Yangステートメントキーワードは、単一の引用によって区切られています。
o XML element names are delimited by "<" and ">" characters.
o XML要素名は、「<」および「>」文字によって区切られています。
o Names of XML attributes are prefixed by the "@" character.
o XML属性の名前には、「@」文字が付いています。
o Other literal values are delimited by double quotes.
o 他の文字通りの値は、二重引用符によって区切られています。
XML element names are always written with explicit namespace prefixes corresponding to the following XML vocabularies:
XML要素名は、常に次のXML語彙に対応する明示的な名前空間プレフィックスで書かれています。
"a" DTD compatibility annotations [RNG-DTD];
"a" dtd互換性の注釈[rng-dtd];
"dc" Dublin Core metadata elements [RFC5013];
「DC」ダブリンコアメタデータ要素[RFC5013];
"dsrl" Document Semantics Renaming Language [DSRL];
「DSRL」ドキュメントセマンティクスの名前を変更する[DSRL];
"en" NETCONF event notifications [RFC5277];
"en" netconfイベント通知[RFC5277];
"nc" NETCONF protocol [RFC4741];
「NC」NetConfプロトコル[RFC4741];
"nma" NETMOD-specific schema annotations (see Section 5.3);
「NMA」NetMod固有のスキーマアノテーション（セクション5.3を参照）。
"nmf" NETMOD-specific XML Path Language (XPath) extension functions (see Section 12.7);
「NMF」NetMod固有のXMLパス言語（XPath）拡張機能（セクション12.7を参照）;
"rng" RELAX NG [RNG];
「RNG」リラックスng [rng];
"sch" ISO Schematron [Schematron];
"sch" iso schematron [schematron];
"xsd" W3C XML Schema [XSD].
「XSD」W3C XMLスキーマ[XSD]。
The following table shows the mapping of these prefixes to namespace URIs.
次の表は、urisという名前のこれらのプレフィックスのマッピングを示しています。
+--------+-----------------------------------------------------+
| Prefix | Namespace URI |
+--------+-----------------------------------------------------+
| a | http://relaxng.org/ns/compatibility/annotations/1.0 |
| | |
| dc | http://purl.org/dc/terms |
| | |
| dsrl | http://purl.oclc.org/dsdl/dsrl |
| | |
| en | urn:ietf:params:xml:ns:netconf:notification:1.0 |
| | |
| nc | urn:ietf:params:xml:ns:netconf:base:1.0 |
| | |
| nma | urn:ietf:params:xml:ns:netmod:dsdl-annotations:1 |
| | |
| nmf | urn:ietf:params:xml:ns:netmod:xpath-extensions:1 |
| | |
| rng | http://relaxng.org/ns/structure/1.0 |
| | |
| sch | http://purl.oclc.org/dsdl/schematron |
| | |
| xsd | http://www.w3.org/2001/XMLSchema |
+--------+-----------------------------------------------------+
Table 1: Used namespace prefixes and corresponding URIs
表1：使用済みの名前空間プレフィックスと対応するURI
o ancestor data type: Any data type from which a given data type is (transitively) derived.
o 祖先のデータ型：特定のデータ型が（トランザティブに）導出される任意のデータ型。
o ancestor built-in data type: The built-in data type that is at the start of the type derivation chain for a given data type.
o 先祖組み込みデータ型：特定のデータ型のタイプ派生チェーンの開始時に組み込まれたデータ型。
o hybrid schema: A RELAX NG schema with annotations, which embodies the same information as the source YANG module(s). See Section 8.1 for details.
o ハイブリッドスキーマ：注釈付きのリラックスNGスキーマ。ソースYangモジュールと同じ情報を具体化します。詳細については、セクション8.1を参照してください。
o implicit node: A data node that, if it is not instantiated in a data tree, may be added to the information set of that data tree (configuration, RPC input or output, notification) without changing the semantics of the data tree.
o 暗黙的なノード：データツリーにインスタンス化されていない場合、データツリーのセマンティクスを変更せずにそのデータツリー（構成、RPC入力または出力、通知）の情報セットに追加できるデータノード。
The main objective of this work is to complement YANG as a data modeling language with validation capabilities of DSDL schema languages, namely RELAX NG, Schematron, and DSRL. This document describes the correspondence between grammatical, semantic, and data type constraints expressed in YANG and equivalent DSDL patterns and rules. The ultimate goal is to be able to capture all substantial information contained in YANG modules and express it in DSDL schemas. While the mapping from YANG to DSDL described in this document may in principle be invertible, the inverse mapping from DSDL to YANG is beyond the scope of this document.
この作業の主な目的は、DSDLスキーマ言語の検証機能を備えたデータモデリング言語としてのYangを補完することです。このドキュメントでは、Yangで表される文法、セマンティック、およびデータ型の制約と同等のDSDLパターンとルールの対応について説明します。究極の目標は、Yangモジュールに含まれるすべての実質的な情報をキャプチャし、DSDLスキーマで表現できることです。このドキュメントで説明されているYangからDSDLへのマッピングは原則として反転可能である可能性がありますが、DSDLからYangへの逆マッピングは、このドキュメントの範囲を超えています。
XML-based information models and XML-encoded data appear in several different forms in various phases of YANG data modeling and NETCONF workflow -- configuration datastore contents, RPC requests and replies, and notifications. Moreover, RPC operations are characterized by an inherent diversity resulting from selective availability of capabilities and features. YANG modules can also define new RPC operations. The mapping should be able to accommodate this variability and generate schemas that are specifically tailored to a particular situation and thus considerably more effective for validation than generic all-encompassing schemas.
XMLベースの情報モデルとXMLエンコードデータは、YangデータモデリングとNetConfワークフローのさまざまなフェーズ（構成データストアコンテンツ、RPC要求と返信、および通知）のいくつかの異なる形式で表示されます。さらに、RPC操作は、機能と機能の選択的可用性に起因する固有の多様性によって特徴付けられます。Yangモジュールは、新しいRPC操作を定義することもできます。マッピングは、この変動性に対応し、特定の状況に合わせて特別に調整されているため、一般的なすべての包括的なスキーマよりも検証にかなり効果的なスキーマを生成できる必要があります。
In order to cope with this variability, we assume that the DSDL schemas will be generated on demand for a particular purpose from the available collection of YANG modules and their lifetime will be relatively short. In other words, we don't envision that any collection of DSDL schemas will be created and maintained over an extended period of time in parallel to YANG modules.
この変動性に対処するために、DSDLスキーマは、利用可能なYangモジュールのコレクションから特定の目的に対してオンデマンドで生成され、それらの寿命は比較的短くなると仮定します。言い換えれば、DSDLスキーマのコレクションがYangモジュールと並行して長期間にわたって作成および維持されることを想定していません。
The generated schemas are primarily intended as input to existing XML schema validators and other off-the-shelf tools. However, the schemas may also be perused by developers and users as a formal representation of constraints on a particular XML-encoded data object. Consequently, our secondary goal is to keep the schemas as readable as possible. To this end, the complexity of the mapping is distributed into two steps:
生成されたスキーマは、主に既存のXMLスキーマバリデーターおよびその他の既製のツールへの入力として意図されています。ただし、スキーマは、特定のXMLエンコードデータオブジェクトの制約の正式な表現として、開発者とユーザーが熟読することもできます。したがって、私たちの二次的な目標は、スキーマをできるだけ読みやすくすることです。この目的のために、マッピングの複雑さは2つのステップに分配されます。
1. The first step maps one or more YANG modules to the so-called hybrid schema, which is a single RELAX NG schema that describes grammatical constraints for the main data tree as well as for RPC operations and notifications. Semantic constraints and other information appearing in the input YANG modules is recorded in the hybrid schema in the form of foreign namespace annotations. The output of the first step can thus be considered a virtually complete equivalent of the input YANG modules. It cannot, however, be directly used for any validation.
1. 最初のステップは、1つ以上のヤンモジュールをいわゆるハイブリッドスキーマにマッピングします。これは、メインデータツリーの文法的制約とRPC操作と通知を説明する単一のリラックスNGスキーマです。入力Yangモジュールに表示されるセマンティックの制約およびその他の情報は、外国の名前空間注釈の形でハイブリッドスキーマに記録されます。したがって、最初のステップの出力は、入力Yangモジュールに実質的に完全に相当すると見なすことができます。ただし、検証には直接使用することはできません。
2. In the second step, the hybrid schema from step 1 is transformed further to a coordinated set of fully conformant DSDL schemas containing constraints for a particular data object and a specific situation. The DSDL schemas are intended mainly for machine validation using off-the-shelf tools.
2. 2番目のステップでは、ステップ1のハイブリッドスキーマは、特定のデータオブジェクトと特定の状況の制約を含む完全に適合したDSDLスキーマの調整されたセットにさらに変換されます。DSDLスキーマは、主に既製のツールを使用したマシン検証を目的としています。
Document Schema Definition Languages (DSDL) is a framework of schema languages that is being developed as the International Standard ISO/ IEC 19757 [DSDL]. Unlike other approaches to XML document validation, most notably W3C XML Schema Definition (XSD) [XSD], the DSDL framework adheres to the principle of "small languages": each of the DSDL constituents is a stand-alone schema language with a relatively narrow purpose and focus. Together, these schema languages may be used in a coordinated way to accomplish various validation tasks.
ドキュメントスキーマ定義言語（DSDL）は、国際標準ISO/ IEC 19757 [DSDL]として開発されているスキーマ言語のフレームワークです。XMLドキュメントの検証に対する他のアプローチ、特にW3C XMLスキーマ定義（XSD）[XSD]とは異なり、DSDLフレームワークは「小言語」の原則に準拠しています。DSDL成分のそれぞれは、比較的狭いスタンドアロンのスキーマ言語です。目的と焦点。一緒に、これらのスキーマ言語は、さまざまな検証タスクを達成するために調整された方法で使用できます。
The mapping described in this document uses three of the DSDL schema languages, namely RELAX NG [RNG], Schematron [Schematron], and DSRL [DSRL].
このドキュメントで説明されているマッピングでは、3つのDSDLスキーマ言語、つまりリラックスNG [RNG]、Schematron [Schematron]、およびDSRL [DSRL]を使用しています。
RELAX NG (pronounced "relaxing") is an XML schema language for grammar-based validation and Part 2 of the ISO/IEC DSDL family of standards [RNG]. Like XSD, it is able to describe constraints on the structure and contents of XML documents. However, unlike the DTD [XML] and XSD schema languages, RELAX NG intentionally avoids any infoset augmentation such as defining default values. In the DSDL architecture, the particular task of defining and applying default values is delegated to another schema language, DSRL (see Section 4.3).
リラックスNG（「リラックス」と発音）は、文法ベースの検証のためのXMLスキーマ言語であり、ISO/IEC DSDLファミリーファミリー[RNG]のパート2です。XSDと同様に、XMLドキュメントの構造と内容の制約を記述することができます。ただし、DTD [XML]やXSDスキーマ言語とは異なり、リラックスNGは、デフォルト値の定義などのインフォセット増強を意図的に回避します。DSDLアーキテクチャでは、デフォルト値を定義および適用する特定のタスクは、別のスキーマ言語DSRLに委任されます（セクション4.3を参照）。
As its base data type library, RELAX NG uses the W3C XML Schema Datatypes [XSD-D]; but unlike XSD, other data type libraries may be used along with it or even replace it if necessary.
ベースデータ型ライブラリとして、lrabe ngはW3C XMLスキーマデータ型[XSD-D]を使用します。ただし、XSDとは異なり、他のデータ型ライブラリを使用するか、必要に応じて交換することもできます。
RELAX NG is very liberal in accepting annotations from other namespaces. With a few exceptions, such annotations may be placed anywhere in the schema and need no encapsulating elements such as <xsd:annotation> in XSD.
リラックスNgは、他の名前空間からの注釈を受け入れるのに非常にリベラルです。いくつかの例外を除いて、そのような注釈はスキーマのどこにでも配置され、XSDの<XSD：Annotation>などのカプセル化要素は必要ありません。
RELAX NG schemas can be represented in two equivalent syntaxes: XML and compact. The compact syntax is described in Annex C of the RELAX NG specification [RNG-CS], which was added to the standard in 2006 (Amendment 1). Automatic bidirectional conversions between the two syntaxes can be accomplished using several tools, for example, Trang [Trang].
ngスキーマをリラックスさせると、XMLとコンパクトの2つの同等の構文で表現できます。コンパクトな構文は、2006年に標準に追加されたRelax Ng仕様[RNG-CS]の付録Cで説明されています（修正1）。2つの構文間の自動双方向変換は、Trang [Trang]など、いくつかのツールを使用して達成できます。
For its terseness and readability, the compact syntax is often the preferred form for publishing RELAX NG schemas, whereas validators and other software tools usually work with the XML syntax. However, the compact syntax has two drawbacks:
その想像力と読みやすさのために、コンパクトな構文は多くの場合、リラックスNGスキーマを公開するのに好ましいフォームですが、バリデーターや他のソフトウェアツールは通常XML構文で動作します。ただし、コンパクトな構文には2つの欠点があります。
o External annotations make the compact syntax schema considerably less readable. While in the XML syntax the annotating elements and attributes are represented in a simple and uniform way (XML elements and attributes from foreign namespaces), the compact syntax uses as many as four different syntactic constructs: documentation, grammar, initial, and following annotations. Therefore, the impact of annotations on readability is often much stronger for the compact syntax than it is for the XML syntax.
o 外部アノテーションにより、コンパクトな構文スキーマの読み取りがかなり低くなります。XML構文では、注釈を付ける要素と属性はシンプルで均一な方法（XML要素と外部名空間からの属性）で表されますが、コンパクトな構文は、ドキュメント、文法、初期、および次の注釈の4つの異なる構文コンストラクトを使用します。したがって、読みやすさに対する注釈の影響は、XML構文よりもコンパクトな構文の方がはるかに強いことがよくあります。
o In a computer program, it is more difficult to generate the compact syntax than the XML syntax. While a number of software libraries exist that make it easy to create an XML tree in the memory and then serialize it, no such aid is available for the compact syntax.
o コンピュータープログラムでは、XML構文よりもコンパクトな構文を生成することがより困難です。メモリ内でXMLツリーを簡単に作成してからシリアル化できる多くのソフトウェアライブラリが存在しますが、コンパクトな構文にはそのような援助は利用できません。
For these reasons, the mapping specification in this document uses exclusively the XML syntax. Where appropriate, though, the schemas resulting from the translation MAY be presented in the equivalent compact syntax.
これらの理由により、このドキュメントのマッピング仕様は、XML構文のみを使用しています。ただし、必要に応じて、翻訳から生じるスキーマは、同等のコンパクト構文で提示される場合があります。
RELAX NG elements are qualified with the namespace URI "http://relaxng.org/ns/structure/1.0". The namespace of the XSD data type library is "http://www.w3.org/2001/XMLSchema-datatypes".
リラックスNG要素には、名前空間URI "http://relaxng.org/ns/structure/1.0"が付いています。XSDデータ型ライブラリの名前空間は「http://www.w3.org/2001/xmlschema-datatypes」です。
Schematron is Part 3 of DSDL that reached the status of a full ISO/ IEC standard in 2006 [Schematron]. In contrast to the traditional schema languages such as DTD, XSD, or RELAX NG, which are based on the concept of a formal grammar, Schematron utilizes a rule-based approach. Its rules may specify arbitrary conditions involving data from different parts of an XML document. Each rule consists of three essential components:
Schematronは、2006年に完全なISO/ IEC標準のステータスに達したDSDLのパート3です[Schematron]。正式な文法の概念に基づいたDTD、XSD、またはRelax NGなどの従来のスキーマ言語とは対照的に、Schematronはルールベースのアプローチを利用しています。そのルールは、XMLドキュメントのさまざまな部分からのデータを含む任意の条件を指定する場合があります。各ルールは、3つの重要なコンポーネントで構成されています。
o context - an XPath expression that defines the set of locations where the rule is to be applied;
o コンテキスト - ルールが適用される場所のセットを定義するXPath式。
o assert or report condition - another XPath expression that is evaluated relative to the location matched by the context expression;
o 条件をアサートまたは報告する - コンテキスト式と一致する位置に対して評価される別のXPath式。
o human-readable message that is displayed when the assert condition is false or report condition is true.
o アサート条件が誤っている場合、または報告条件が真である場合に表示される人間の読み取り可能なメッセージ。
The difference between the assert and report condition is that the former is positive in that it states a condition that a valid document has to satisfy, whereas the latter specifies an error condition.
アサート条件とレポート条件の違いは、前者が有効なドキュメントが満たさなければならないという条件を述べ、後者はエラー条件を指定するという点でプラスであるということです。
Schematron draws most of its expressive power from XPath [XPath] and Extensible Stylesheet Language Transformations (XSLT) [XSLT]. ISO Schematron allows for dynamic query language binding so that the following XML query languages can be used: STX, XSLT 1.0, XSLT 1.1, EXSLT, XSLT 2.0, XPath 1.0, XPath 2.0, and XQuery 1.0 (this list may be extended in the future).
Schematronは、Xpath [XPath]および拡張可能なStyleSheet言語変換（XSLT）[XSLT]から表現力のあるパワーのほとんどを引き出します。ISO Schematronでは、次のXMLクエリ言語を使用できるように動的クエリ言語バインディングを可能にします：STX、XSLT 1.0、XSLT 1.1、EXSLT、XSLT 2.0、XPath 1.0、XPath 2.0、およびXquery 1.0（このリストは将来拡張される可能性があります）。
Human-readable error messages are another feature that sets Schematron apart from other common schema languages. The messages may even contain XPath expressions that are evaluated in the actual context and thus refer to information items in the XML document being validated.
人間の読み取り可能なエラーメッセージは、スキーマトロンを他の一般的なスキーマ言語と区別する別の機能です。メッセージには、実際のコンテキストで評価されているXPath式が含まれている場合があるため、検証されているXMLドキュメント内の情報項目が参照されます。
Another feature of Schematron that is used by the mapping are abstract patterns. These work essentially as macros and may also contain parameters which are supplied when the abstract pattern is used.
マッピングで使用されるスキーマトロンのもう1つの機能は、抽象的なパターンです。これらは本質的にマクロとして機能し、抽象パターンが使用されるときに提供されるパラメーターも含まれている場合があります。
Schematron elements are qualified with namespace URI "http://purl.oclc.org/dsdl/schematron".
スキーマトロン要素には、名前空間URI "http://purl.oclc.org/dsdl/schematron"が付いています。
DSRL (pronounced "disrule") is Part 8 of DSDL that reached the status of a full ISO/IEC standard in 2008 [DSRL]. Unlike RELAX NG and Schematron, DSRL is allowed to modify XML information set of the validated document. While DSRL is primarily intended for renaming XML elements and attributes, it can also define default values for XML attributes and default contents for XML elements or subtrees so that the default contents are inserted if they are missing in the validated documents. The latter feature is used by the YANG-to-DSDL mapping for representing YANG default contents consisting of leaf nodes with default values and their ancestor non-presence containers.
DSRL（「Disrule」と発音）は、2008年に完全なISO/IEC標準のステータスに達したDSDLのパート8です[DSRL]。raxy ngやSchematronとは異なり、DSRLは検証済みのドキュメントのXML情報セットを変更することが許可されています。DSRLは主にXML要素と属性の名前を変更することを目的としていますが、XML属性のデフォルト値とXML要素またはサブツリーのデフォルトコンテンツを定義して、検証済みのドキュメントに欠落している場合にデフォルトの内容が挿入されるようにすることもできます。後者の特徴は、デフォルト値を持つ葉のノードとその祖先の非表現容器で構成されるYangデフォルトコンテンツを表すために、Yang-to-DSDLマッピングで使用されます。
DSRL elements are qualified with namespace URI "http://purl.oclc.org/dsdl/dsrl".
DSRL要素には、名前空間uri "http://purl.oclc.org/dsdl/dsrl"が付いています。
Besides the DSDL schema languages, the mapping also uses three sets of annotations that are added as foreign-namespace attributes and elements to RELAX NG schemas.
DSDLスキーマ言語に加えて、マッピングは、NGスキーマをリラックスするために外部名型属性と要素として追加される3セットの注釈も使用します。
Two of the annotation sets -- Dublin Core elements and DTD compatibility annotations -- are standard vocabularies for representing metadata and documentation, respectively. Although these data model items are not used for formal validation, they quite often carry important information for data model implementers. Therefore, they SHOULD be included in the hybrid schema and MAY also appear in the final validation schemas.
2つの注釈セット - ダブリンのコア要素とDTD互換性の注釈 - は、それぞれメタデータとドキュメントを表すための標準的な語彙です。これらのデータモデル項目は正式な検証には使用されていませんが、データモデルの実装者にとって重要な情報を非常に頻繁に伝えています。したがって、それらはハイブリッドスキーマに含める必要があり、最終的な検証スキーマにも表示される場合があります。
The third set are NETMOD-specific annotations. They are specifically designed for the hybrid schema and convey semantic constraints and other information that cannot be expressed directly in RELAX NG. In the second mapping step, these annotations are converted to Schematron and DSRL rules.
3番目のセットは、NetMod固有の注釈です。これらは、ハイブリッドスキーマ用に特別に設計されており、セマンティックの制約やリラックスNGで直接表現できないその他の情報を伝えます。2番目のマッピングステップでは、これらの注釈はSchematronおよびDSRLルールに変換されます。
Dublin Core is a system of metadata elements that was originally created for describing metadata of World Wide Web resources in order to facilitate their automated lookup. Later it was accepted as a standard for describing metadata of arbitrary resources. This specification uses the definition from [RFC5013].
ダブリンコアは、自動検索を容易にするために、ワールドワイドウェブリソースのメタデータを記述するために元々作成されたメタデータ要素のシステムです。その後、任意のリソースのメタデータを記述するための基準として受け入れられました。この仕様では、[RFC5013]の定義を使用します。
Dublin Core elements are qualified with namespace URI "http://purl.org/dc/terms".
ダブリンのコア要素には、名前空間URI "http://purl.org/dc/terms"が付いています。
DTD compatibility annotations are a part of the RELAX NG DTD Compatibility specification [RNG-DTD]. YANG-to-DSDL mapping uses only the <a:documentation> annotation for representing YANG 'description' and 'reference' texts.
DTD互換性注釈は、リラックスNG DTD互換性の仕様[RNG-DTD]の一部です。Yang-to-DSDLマッピングでは、Yang '説明'および「参照」テキストを表すための<a：documentation> annotationのみを使用します。
Note that there is no intention to make the resulting schemas DTD-compatible, the main reason for using these annotations is technical: they are well supported and adequately formatted by several RELAX NG tools.
結果として生じるスキーマDTD互換性を互いに互換性のあるものにするつもりはないことに注意してください。これらの注釈を使用する主な理由は技術的です。それらはいくつかのリラックスNGツールによって十分にサポートされ、適切にフォーマットされています。
DTD compatibility annotations are qualified with namespace URI "http://relaxng.org/ns/compatibility/annotations/1.0".
DTD互換性の注釈は、名前空間URI "http://relaxng.org/ns/compatibility/annotations/1.0"で適格です。
NETMOD-specific annotations are XML elements and attributes that are qualified with the namespace URI "urn:ietf:params:xml:ns:netmod:dsdl-annotations:1" and that appear in various locations of the hybrid schema. YANG statements are mapped to these annotations in a straightforward way. In most cases, the annotation attributes and elements have the same name as the corresponding YANG statement.
NetMod固有のアノテーションは、名前空間URI "urn：ietf：params：xml：ns：netmod：dsdl-annotations：1"で適格なXML要素と属性です。それはハイブリッドスキーマのさまざまな場所に表示されます。Yangステートメントは、これらの注釈に簡単な方法でマッピングされます。ほとんどの場合、注釈属性と要素は、対応するYangステートメントと同じ名前を持っています。
Table 2 lists, alphabetically, the names of NETMOD-specific annotation attributes (prefixed with "@") and elements (in angle brackets) along with a reference to the section where their use is described. Appendix A contains a RELAX NG schema for this annotation vocabulary.
表2のリスト、アルファベット順に、NetMod固有のアノテーション属性（「@」が付いている）と要素（角度ブラケット内）の名前と、それらの使用が記載されているセクションへの参照とともにリストされています。付録Aには、この注釈語彙のリラックスNGスキーマが含まれています。
+---------------------------+--------------------+------+
| annotation | section | note |
+---------------------------+--------------------+------+
| @nma:config | 10.9 | |
| | | |
| <nma:data> | 8.1 | 4 |
| | | |
| @nma:default | 10.12 | |
| | | |
| <nma:error-app-tag> | 10.16 | 1 |
| | | |
| <nma:error-message> | 10.17 | 1 |
| | | |
| @nma:if-feature | 10.22 | |
| | | |
| @nma:implicit | 10.11, 10.7, 10.12 | |
| | | |
| <nma:input> | 8.1 | 4 |
| | | |
| <nma:instance-identifier> | 10.53.7 | 2 |
| | | |
| @nma:key | 10.26 | |
| | | |
| @nma:leaf-list | 10.28 | |
| | | |
| @nma:leafref | 10.53.8 | |
| | | |
| @nma:mandatory | 10.8 | |
| | | |
| @nma:max-elements | 10.28 | |
| | | |
| @nma:min-elements | 10.28 | |
| | | |
| @nma:module | 10.34 | |
| | | |
| <nma:must> | 10.35 | 3 |
| | | |
| <nma:notification> | 8.1 | 4 |
| | | |
| <nma:notifications> | 8.1 | 4 |
| | | |
| @nma:ordered-by | 10.38 | |
| <nma:output> | 8.1 | 4 |
| | | |
| <nma:rpc> | 8.1 | 4 |
| | | |
| <nma:rpcs> | 8.1 | 4 |
| | | |
| @nma:status | 10.51 | |
| | | |
| @nma:unique | 10.55 | |
| | | |
| @nma:units | 10.56 | |
| | | |
| @nma:when | 10.59 | |
+---------------------------+--------------------+------+
Table 2: NETMOD-specific annotations
表2：NetMod固有の注釈
Notes:
ノート：
1. Appears only as a subelement of <nma:must>.
1. <nma：must>のサブレメントとしてのみ表示されます。
2. Has an optional attribute @require-instance.
2. オプションの属性 @require-instanceがあります。
3. Has a mandatory attribute @assert and two optional subelements <nma:error-app-tag> and <nma:error-message>.
3. 必須の属性@Assertと2つのオプションのサブエレメント<nma：error-app-tag>および<nma：error-message>。
4. Marker element in the hybrid schema.
4. ハイブリッドスキーマのマーカー要素。
This section gives an overview of the YANG-to-DSDL mapping, its inputs and outputs. Figure 1 presents an overall structure of the mapping:
このセクションでは、Yang-to-DSDLマッピング、入力、および出力の概要を説明します。図1は、マッピングの全体的な構造を示しています。
+----------------+
| YANG module(s) |
+----------------+
|
|T
|
+------------------------------------+
| hybrid schema |
+------------------------------------+
/ | | \
/ | | \
Tg/ Tr| |Tn \
/ | | \
+---------+ +-----+ +-------+ +------+
|get reply| | rpc | | notif | | .... |
+---------+ +-----+ +-------+ +------+
Figure 1: Structure of the mapping
図1：マッピングの構造
The mapping procedure is divided into two steps:
マッピング手順は、2つのステップに分割されます。
1. Transformation T in the first step maps one or more YANG modules to the hybrid schema (see Section 8.1). Constraints that cannot be expressed directly in RELAX NG (list key definitions, 'must' statements, etc.) and various documentation texts are recorded in the schema as foreign-namespace annotations.
1. 最初のステップの変換tは、1つ以上のヤンモジュールをハイブリッドスキーマにマッピングします（セクション8.1を参照）。リラックスNG（リストキー定義、「マスト」ステートメントなどのリストなど）で直接表現できない制約およびさまざまなドキュメンテーションテキストは、SchemaにForeign-Namespace Annotationsとして記録されています。
2. In the second step, the hybrid schema may be transformed in multiple ways to a coordinated set of DSDL schemas that can be used for validating a particular data object in a specific context. Figure 1 shows three simple possibilities as examples. In the process, appropriate parts of the hybrid schema are extracted and specific annotations transformed to equivalent, but usually more complex, Schematron patterns, DSRL element maps, etc.
2. 2番目のステップでは、ハイブリッドスキーマは、特定のコンテキストで特定のデータオブジェクトを検証するために使用できるDSDLスキーマの調整されたセットに複数の方法で変換される場合があります。図1は、例として3つの単純な可能性を示しています。その過程で、ハイブリッドスキーマの適切な部分が抽出され、特定の注釈が同等のものに変換されますが、通常はより複雑なスキーマトロンパターン、DSRL要素マップなどに変換されます。
An implementation of the mapping algorithm MUST accept one or more valid YANG modules as its input. It is important to be able to process multiple YANG modules together since multiple modules may be negotiated for a NETCONF session and the contents of the configuration datastore is then obtained as the union of data trees specified by the individual modules, which may also lead to multiple root nodes of the datastore hierarchy. In addition, the input modules may be further coupled by the 'augment' statement in which one module augments the data tree of another module.
マッピングアルゴリズムの実装は、入力として1つ以上の有効なYangモジュールを受け入れる必要があります。複数のモジュールがNetConfセッションのためにネゴシエートされ、構成データストアの内容が個々のモジュールによって指定されたデータツリーの結合として取得されるため、複数のモジュールがネットコンフセッションのためにネゴシエートされる可能性があるため、複数のYangモジュールを処理できることが重要です。データストア階層のルートノード。さらに、入力モジュールは、1つのモジュールが別のモジュールのデータツリーを強化する「Augment」ステートメントによってさらに結合される場合があります。
It is also assumed that the algorithm has access, perhaps on demand, to all YANG modules that the input modules import (directly or transitively).
また、アルゴリズムには、入力モジュールが（直接またはトランザティブに）インポートするすべてのYangモジュールに、おそらくオンデマンドでアクセスできると想定されています。
Other information contained in input YANG modules, such as semantic constraints and default values, is recorded in the hybrid schema as annotations -- XML attributes or elements qualified with the namespace URI "urn:ietf:params:xml:ns:netmod:dsdl-annotations:1". Metadata describing the YANG modules are mapped to Dublin Core annotations elements (Section 5.1). Finally, documentation strings are mapped to <a:documentation> elements belonging to the DTD compatibility vocabulary (Section 5.2).
セマンティック制約やデフォルト値などの入力Yangモジュールに含まれるその他の情報は、ハイブリッドスキーマに注釈として記録されます。XML属性または名前空間URIの資格のある要素 "urn：ietf：xml：ns：netmod：dsdl-注釈：1 "。Yangモジュールを説明するメタデータは、ダブリンのコアアノテーション要素にマッピングされます（セクション5.1）。最後に、ドキュメント文字列は、DTD互換性の語彙に属する<a：documentation>要素にマッピングされます（セクション5.2）。
The output of the second step is a coordinated set of three DSDL schemas corresponding to a specific data object and context:
2番目のステップの出力は、特定のデータオブジェクトとコンテキストに対応する3つのDSDLスキーマの調整されたセットです。
o RELAX NG schema describing the grammatical and data type constraints;
o 文法およびデータ型の制約を説明するNGスキーマをリラックスします。
o Schematron schema expressing other constraints such as uniqueness of list keys or user-specified semantic rules;
o リストキーの一意性やユーザー指定のセマンティックルールなどの他の制約を表現するスキーマトロンスキーマ。
o DSRL schema containing the specification of default contents.
o デフォルトコンテンツの仕様を含むDSRLスキーマ。
This section describes how the schemas generated by the YANG-to-DSDL mapping are supposed to be applied for validating XML instance documents such as the contents of a datastore or various NETCONF messages.
このセクションでは、Yang-to-DSDLマッピングによって生成されたスキーマが、データストアの内容やさまざまなNetConfメッセージなどのXMLインスタンスドキュメントを検証するために適用されることになっている方法について説明します。
The validation proceeds in the following steps, which are also illustrated in Figure 2:
検証は次の手順で進行します。これは図2にも示されています。
1. The XML instance document is checked for grammatical and data type validity using the RELAX NG schema.
1. XMLインスタンスドキュメントは、Relax NGスキーマを使用して文法およびデータ型の妥当性についてチェックされます。
2. Default values for leaf nodes have to be applied and their ancestor containers added where necessary. It is important to add the implicit nodes before the next validation step because YANG specification [RFC6020] requires that the data tree against which XPath expressions are evaluated already has all defaults filled-in. Note that this step modifies the information set of the validated XML document.
2. 葉のノードのデフォルト値を適用する必要があり、必要に応じて祖先容器を追加する必要があります。Yang仕様[RFC6020]では、Xpath式が評価されているデータツリーにすでにすべてのデフォルトが記入されているため、次の検証ステップの前に暗黙のノードを追加することが重要です。このステップは、検証済みのXMLドキュメントの情報セットを変更することに注意してください。
3. The semantic constraints are checked using the Schematron schema.
3. セマンティックの制約は、スキーマトロンスキーマを使用してチェックされます。
+----------+ +----------+
| | | XML |
| XML | | document |
| document |-----------o----------->| with |
| | ^ | defaults |
| | | | |
+----------+ | +----------+
^ | filling in ^
| grammar, | defaults | semantic
| data types | | constraints
| | |
+----------+ +--------+ +------------+
| RELAX NG | | DSRL | | Schematron |
| schema | | schema | | schema |
+----------+ +--------+ +------------+
Figure 2: Outline of the validation procedure
図2：検証手順の概要
YANG data models could, in principle, be mapped to the DSDL schemas in a number of ways. The mapping procedure described in this document uses several specific design decisions that are discussed in the following subsections.
Yangデータモデルは、原則として、さまざまな方法でDSDLスキーマにマッピングできます。このドキュメントで説明されているマッピング手順では、以下のサブセクションで説明されているいくつかの特定の設計上の決定を使用しています。
As was explained in Section 6, the first step of the mapping produces an intermediate document -- the hybrid schema, which specifies all constraints for the entire data model using the RELAX NG syntax and additional annotations. In cannot be directly used for validation -- as a matter of fact, it is not even a valid RELAX NG schema because it contains multiple schemas demarcated by special annotation elements.
セクション6で説明したように、マッピングの最初のステップは中間ドキュメントであるハイブリッドスキーマを生成します。これは、Relax NG構文と追加注釈を使用してデータモデル全体のすべての制約を指定します。検証に直接使用することはできません - 実際のところ、特別な注釈要素によって区切られた複数のスキーマが含まれているため、有効なリラックスNGスキーマでさえありません。
Every input YANG module corresponds to exactly one embedded grammar in the hybrid schema. This separation of input YANG modules allows each embedded grammar to include named pattern definitions into its own namespace, which is important for mapping YANG groupings (see Section 9.2 for additional details).
すべての入力Yangモジュールは、ハイブリッドスキーマに1つの埋め込み文法に正確に対応しています。入力Yangモジュールのこの分離により、各組み込み文法は、Yangグループのマッピングに重要な名前のパターン定義を独自の名前空間に含めることができます（詳細についてはセクション9.2を参照）。
In addition to grammatical and data type constraints, YANG modules provide other important information that cannot be expressed in a RELAX NG schema: semantic constraints, default values, metadata, documentation, and so on. Such information items are represented in the hybrid schema as XML attributes and elements belonging to the namespace with the following URI: "urn:ietf:params:xml:ns:netmod:dsdl-annotations:1". A complete list of these annotations is given in Section 5.3, detailed rules about their use are then contained in the following sections.
文法およびデータ型の制約に加えて、Yangモジュールは、セマンティック制約、デフォルト値、メタデータ、ドキュメントなど、リラックスNGスキーマで表現できない他の重要な情報を提供します。このような情報項目は、次のURIを使用して名前空間に属するXML属性および要素としてハイブリッドスキーマで表されます。これらの注釈の完全なリストは、セクション5.3に記載されています。その使用に関する詳細なルールは、次のセクションに含まれています。
YANG modules define data models not only for configuration and state data but also for (multiple) RPC operations [RFC4741] and/or event notifications [RFC5277]. In order to be able to capture all three types of data models in one schema document, the hybrid schema uses special markers that enclose sub-schemas for configuration and state data, individual RPC operations (both input and output part) and individual notifications.
Yangモジュールは、構成と状態データだけでなく、（複数）RPC操作[RFC4741]および/またはイベント通知[RFC5277]のデータモデルを定義します。1つのスキーマドキュメントで3種類すべてのデータモデルをキャプチャできるようにするために、ハイブリッドスキーマは、構成および状態データ、個々のRPC操作（入力および出力パーツの両方）および個々の通知のサブスキーマを囲む特別なマーカーを使用します。
The markers are the following XML elements in the namespace of NETMOD-specific annotations (URI urn:ietf:params:xml:ns:netmod:dsdl-annotations:1):
マーカーは、NetMod固有の注釈の名前空間にある次のXML要素です（URI URN：IETF：PARAMS：XML：NS：NETMOD：DSDL-ANNOTATIONS：1）：
+-------------------+---------------------------------------+
| Element name | Role |
+-------------------+---------------------------------------+
| nma:data | encloses configuration and state data |
| | |
| nma:rpcs | encloses all RPC operations |
| | |
| nma:rpc | encloses an individual RPC operation |
| | |
| nma:input | encloses an RPC request |
| | |
| nma:output | encloses an RPC reply |
| | |
| nma:notifications | encloses all notifications |
| | |
| nma:notification | encloses an individual notification |
+-------------------+---------------------------------------+
Table 3: Marker elements in the hybrid schema
表3：ハイブリッドスキーマのマーカー要素
For example, consider a data model formed by two YANG modules "example-a" and "example-b" that define nodes in the namespaces "http://example.com/ns/example-a" and "http://example.com/ns/example-b". Module "example-a" defines configuration/state data, RPC methods and notifications, whereas "example-b" defines only configuration/state data. The hybrid schema can then be schematically represented as follows:
たとえば、名前空間でノードを定義する2つのYangモジュール「Example A」と「Example-B」によって形成されたデータモデルを考えてみましょう。Example.com/ns/example-b "。モジュール「Example-A」は、構成/状態データ、RPCメソッド、および通知を定義しますが、「例-B」は構成/状態データのみを定義します。ハイブリッドスキーマは、次のように概略的に表現できます。
<grammar xmlns="http://relaxng.org/ns/structure/1.0"
xmlns:nma="urn:ietf:params:xml:ns:netmod:dsdl-annotations:1"
xmlns:exa="http://example.com/ns/example-a"
xmlns:exb="http://example.com/ns/example-b"
datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes">
<start>
<grammar nma:module="example-a"
ns="http://example.com/ns/example-a">
<start>
<nma:data>
...configuration and state data defined in "example-a"...
</nma:data>
<nma:rpcs>
<nma:rpc>
<nma:input>
<element name="exa:myrpc">
...
</element>
</nma:input>
<nma:output>
...
</nma:output>
</nma:rpc>
...
</nma:rpcs>
<nma:notifications>
<nma:notification>
<element name="exa:mynotif">
...
</element>
</nma:notification>
...
</nma:notifications>
</start>
...local named pattern definitions of example-a...
</grammar>
<grammar nma:module="example-b"
ns="http://example.com/ns/example-a">
<start>
<nma:data>
...configuration and state data defined in "example-b"...
</nma:data>
<nma:rpcs/>
<nma:notifications/>
</start>
...local named pattern definitions of example-b...
</grammar>
</start>
...global named pattern definitions... </grammar>
...グローバル名のパターン定義... </grammar>
A complete hybrid schema for the data model of a DHCP server is given in Appendix C.2.
DHCPサーバーのデータモデルの完全なハイブリッドスキーマは、付録C.2に記載されています。
Both YANG and RELAX NG offer means for modularity, i.e., for splitting the contents of a full schema into separate modules and combining or reusing them in various ways. However, the approaches taken by YANG and RELAX NG differ. Modularity in RELAX NG is suitable for ad hoc combinations of a small number of schemas whereas YANG assumes a large set of modules similar to SNMP MIB modules. The following differences are important:
YangとRelax Ngの両方が、モジュール性の手段、つまり、完全なスキーマの内容を別々のモジュールに分割し、さまざまな方法でそれらを組み合わせまたは再利用するための手段を提供します。ただし、ヤンとリラックスngが取ったアプローチは異なります。リラックスNGのモジュール性は、少数のスキーマのアドホックな組み合わせに適していますが、YangはSNMP MIBモジュールに似た大きなモジュールのセットを想定しています。次の違いが重要です。
o In YANG, whenever module A imports module B, it gets access to the definitions (groupings and typedefs) appearing at the top level of module B. However, no part of data tree from module B is imported along with it. In contrast, the <rng:include> pattern in RELAX NG imports both definitions of named patterns and the entire schema tree from the included schema.
o Yangでは、モジュールAインポートモジュールBをインポートするたびに、モジュールBの上位レベルに表示される定義（グループ化とtypedef）にアクセスできます。ただし、モジュールBのデータツリーの一部はそれとともにインポートされません。対照的に、<rng：included> pattern in lrage ngは、名前付きパターンの定義と、含まれたスキーマからのスキーマツリー全体の両方の定義をインポートします。
o The names of imported YANG groupings and typedefs are qualified with the namespace of the imported module. On the other hand, the names of data nodes contained inside the imported groupings, when used within the importing module, become part of the importing module's namespace. In RELAX NG, the names of patterns are unqualified and so named patterns defined in both the importing and imported module share the same flat namespace. The contents of RELAX NG named patterns may either keep the namespace of the schema where they are defined or inherit the namespace of the importing module, analogically to YANG. However, in order to achieve the latter behavior, the definitions of named patterns must be included from an external schema, which has to be prepared in a special way (see [Vli04], Chapter 11).
o インポートされたYangグループとTypedefsの名前は、インポートされたモジュールの名前空間で資格があります。一方、インポートモジュール内で使用すると、インポートされたグループ内に含まれるデータノードの名前は、インポートモジュールの名前空間の一部になります。リラックスNGでは、パターンの名前は資格がなく、インポートモジュールとインポートされたモジュールの両方で定義されたパターンが同じフラットネームスペースを共有しています。リラックスNGの名前付きパターンの内容は、スキーマの名前空間を定義されているか、Yangと同様にインポートモジュールの名前空間を継承するかのいずれかを保持する場合があります。ただし、後者の動作を達成するには、名前付きパターンの定義は、特別な方法で準備する必要がある外部スキーマから含める必要があります（[VLI04]、第11章を参照）。
In order to map, as much as possible, the modularity of YANG to RELAX NG, a validating RELAX NG schema (the result of the second mapping step) has to be split into two files, one of them containing all global definitions that are mapped from top-level YANG groupings appearing in all input YANG module. This RELAX NG schema MUST NOT define any namespace via the @ns attribute.
可能な限りマッピングするために、Yangのモジュール性NGをリラックスするために、検証済みのリラックスNGスキーマ（2番目のマッピングステップの結果）を2つのファイルに分割する必要があります。すべての入力ヤンモジュールに表示されるトップレベルのヤングループから。このリラックスNGスキーマは、@NS属性を介して名前空間を定義してはなりません。
The other RELAX NG schema file then defines actual data trees mapped from input YANG modules, each of them enclosed in an own embedded grammar. Those embedded grammars, in which at least one of the global definitions is used, MUST include the first schema with definitions and also MUST define the local namespace using the @ns attribute. This way, the global definitions can be used inside different embedded grammar, each time accepting a different local namespace.
その後、もう1つのRelax ngスキーマファイルは、入力Yangモジュールからマッピングされた実際のデータツリーを定義します。それぞれが独自の埋め込み文法に囲まれています。グローバルな定義の少なくとも1つが使用されるこれらの組み込み文法には、定義を備えた最初のスキーマを含める必要があり、@NS属性を使用してローカルネームスペースを定義する必要があります。これにより、グローバルな定義は、異なるローカルネームスペースを受け入れるたびに、異なる組み込み文法内で使用できます。
Named pattern definitions that are mapped from non-top-level YANG groupings MUST be placed inside the embedded grammar corresponding to the YANG module where the grouping is defined.
非トップレベルのYangグループからマッピングされた名前のパターン定義は、グループが定義されているYangモジュールに対応する埋め込み文法の内側に配置する必要があります。
In the hybrid schema, we need to distinguish the global and non-global named pattern definitions while still keeping the hybrid schema in one file. This is accomplished in the following way:
ハイブリッドスキーマでは、ハイブリッドスキーマを1つのファイルに保持しながら、グローバルおよび非グロバルという名前のパターン定義を区別する必要があります。これは次の方法で達成されます。
o Every global definition MUST be placed as a child of the outer <rng:grammar> element (the document root of the hybrid schema).
o すべてのグローバル定義は、外側<rng：grammar>要素の子として配置する必要があります（ハイブリッドスキーマのドキュメントルート）。
o Every non-global definitions MUST be placed as a child of the corresponding embedded <rng:grammar> element.
o すべての非グローバル定義は、対応する埋め込み<rng：grammar>要素の子として配置する必要があります。
YANG also allows for splitting a module into a number of submodules. However, as submodules have no impact on the scope of identifiers and namespaces, the modularity based on submodules is not mapped in any way. The contents of submodules is therefore handled as if the submodule text appeared directly in the main module.
Yangでは、モジュールを多くのサブモジュールに分割することもできます。ただし、サブモジュールは識別子と名前空間の範囲に影響を与えないため、サブモジュールに基づくモジュール性は決してマッピングされません。したがって、サブモジュールの内容は、サブモジュールテキストがメインモジュールに直接表示されるかのように処理されます。
RELAX NG supports different styles of schema structuring: one extreme, often called "Russian Doll", specifies the structure of an XML instance document in a single hierarchy. The other extreme, the flat style, uses a similar approach as the Data Type Definition (DTD) schema language -- every XML element corresponds to a named pattern definition. In practice, some compromise between the two extremes is usually chosen.
Relax Ngは、さまざまなスタイルのスキーマ構造をサポートしています。1つの極端な「ロシア人形」と呼ばれることは、単一の階層でXMLインスタンスドキュメントの構造を指定します。もう1つの極端であるフラットスタイルは、データ型定義（DTD）スキーマ言語と同様のアプローチを使用します。すべてのXML要素は、指定されたパターン定義に対応しています。実際には、通常、両極端の間のいくつかの妥協が選択されます。
YANG supports both styles in principle, too, but in most cases the modules are organized in a way closer to the "Russian Doll" style, which provides a better insight into the structure of the configuration data. Groupings are usually defined only for contents that are prepared for reuse in multiple places via the 'uses' statement. In contrast, RELAX NG schemas tend to be much flatter, because finer granularity is also needed in RELAX NG for extensibility of the schemas -- it is only possible to replace or modify schema fragments that are factored out as named patterns. For YANG, this is not an issue since its 'augment' and 'refine' statements can delve, by using path expressions, into arbitrary depths of existing structures.
Yangは原則として両方のスタイルもサポートしていますが、ほとんどの場合、モジュールは「ロシア人形」スタイルに近い方法で編成されており、構成データの構造に関するより良い洞察を提供します。グループ化は通常、「使用」ステートメントを介して複数の場所で再利用するために準備されたコンテンツに対してのみ定義されます。対照的に、リラックスNGスキーマは、スキーマの拡張性のためにリラックスngにもより細かい粒度が必要であるため、非常に平らになる傾向があります。名前が付けられたパターンとして因数分解されるスキーマフラグメントを置き換えるか変更することは可能です。Yangの場合、これは「Augment」および「Refine」ステートメントがパス式を使用して既存の構造の任意の深さを掘り下げることができるため、問題ではありません。
In general, it is not feasible to map YANG's powerful extension mechanisms to those available in RELAX NG. For this reason, the mapping essentially keeps the granularity of the original YANG data model: YANG groupings and definitions of derived types usually have direct counterparts in definitions of named patterns in the resulting RELAX NG schema.
一般に、ヤンの強力な拡張メカニズムをリラックスNGで利用できるものにマッピングすることは実現可能ではありません。このため、マッピングは本質的に元のYangデータモデルの粒度を維持します。ヤンのグループ化と派生タイプの定義には、通常、結果のリラックスNGスキーマの名前付きパターンの定義に直接対応するものがあります。
Most modern XML schema languages, including RELAX NG, Schematron, and DSRL, support schemas for so-called compound XML documents that contain elements from multiple namespaces. This is useful for our purpose since the YANG-to-DSDL mapping allows for multiple input YANG modules, which naturally leads to compound document schemas.
Relax NG、Schematron、DSRLを含むほとんどの最新のXMLスキーマ言語は、複数の名前空間からの要素を含むいわゆる化合物XMLドキュメントのスキーマをサポートしています。これは、Yang-to-DSDLマッピングが複数の入力Yangモジュールを許可し、自然に複合ドキュメントスキーマにつながるため、私たちの目的に役立ちます。
RELAX NG offers two alternatives for defining the target namespaces in the schema:
Relax Ngは、スキーマ内のターゲットネームスペースを定義するための2つの選択肢を提供します。
1. First possibility is the traditional XML way via the @xmlns:xxx attribute.
1. 最初の可能性は、@xmlns：xxx属性を介した従来のXML方法です。
2. One of the target namespace URIs may be declared using the @ns attribute.
2. ターゲットネームスペースURIの1つは、@NS属性を使用して宣言できます。
In both the hybrid schema and validation RELAX NG schemas generated in the second step, the namespaces MUST be declared as follows:
ハイブリッドスキーマと検証の両方で、2番目のステップで生成されたNGスキーマをリラックスさせると、名前空間は次のように宣言する必要があります。
1. The root <rng:grammar> MUST have @xmlns:xxx attributes declaring prefixes of all namespaces that are used in the data model. The prefixes SHOULD be identical to those defined in the 'prefix' statements. An implementation of the mapping MUST resolve all collisions in the prefixes defined by different input modules, if there are any.
1. root <rng：grammar>は、@xmlns：xxx属性を持っている必要があります。データモデルで使用されるすべての名前空間のプレフィックスを宣言します。プレフィックスは、「プレフィックス」ステートメントで定義されているものと同一である必要があります。マッピングの実装は、ある場合、異なる入力モジュールで定義されたプレフィックス内のすべての衝突を解決する必要があります。
2. Each embedded <rng:grammar> element MUST declare the namespace of the corresponding module using the @ns attribute. This way, the names of nodes defined by global named patterns are able to adopt the local namespace of each embedded grammar, as explained in Section 8.2.
2. 各埋め込み<rng：grammar>要素は、@NS属性を使用して対応するモジュールの名前空間を宣言する必要があります。このようにして、グローバルな名前のパターンで定義されたノードの名前は、セクション8.2で説明されているように、各組み込み文法のローカルネームスペースを採用することができます。
This setup is illustrated by the example at the end of Section 8.1.
このセットアップは、セクション8.1の最後の例で説明されています。
DSRL schemas may declare any number of target namespaces via the standard XML attributes xmlns:xxx.
DSRLスキーマは、標準のXML属性XMLNS：XXXを介して任意の数のターゲット名空間を宣言する場合があります。
In contrast, Schematron requires all used namespaces to be defined in the <sch:ns> subelements of the document element <sch:schema>.
対照的に、Schematronでは、すべての使用された名前空間をドキュメント要素の<sch：ns>サブエレメント<sch：schema>で定義する必要があります。
This section explains the main principles governing the first step of the mapping. Its result is the hybrid schema that is described in Section 8.1.
このセクションでは、マッピングの最初のステップを管理する主要な原則について説明します。その結果、セクション8.1で説明されているハイブリッドスキーマが得られました。
A detailed specification of the mapping of individual YANG statements is contained in Section 10.
個々のヤンステートメントのマッピングの詳細な仕様は、セクション10に含まれています。
In DSDL schema languages, occurrence constraints for a node are always localized together with that node. In a RELAX NG schema, for example, the <rng:optional> pattern appears as the parent element of the pattern defining a leaf or non-leaf element. Similarly, DSRL specifies default contents separately for every single node, be it a leaf or non-leaf element.
DSDLスキーマ言語では、ノードの発生制約は常にそのノードとともにローカライズされます。たとえば、リラックスngスキーマでは、<rng：optional>パターンは、葉または非葉要素を定義するパターンの親要素として表示されます。同様に、DSRLは、葉または非葉要素であっても、すべてのノードのデフォルトコンテンツを個別に指定します。
For leaf nodes in YANG modules, the occurrence constraints are also easily inferred from the substatements of 'leaf'. On the other hand, for a YANG container, it is often necessary to examine its entire subtree in order to determine the container's occurrence constraints.
Yangモジュールの葉のノードの場合、「葉」の置換から発生の制約も簡単に推測されます。一方、ヤン容器の場合、コンテナの発生制約を決定するために、サブツリー全体を調べる必要があることがよくあります。
Therefore, one of the goals of the first mapping step is to infer the occurrence constraints for all data nodes and mark, accordingly, the corresponding <rng:element> patterns in the hybrid schema so that any transformation procedure in the second mapping step can simply use this information and need not examine the subtree again.
したがって、最初のマッピングステップの目標の1つは、すべてのデータノードとマークの発生制約を推測することです。この情報を使用すると、サブツリーを再度調べる必要はありません。
First, it has to be decided whether a given data node must always be present in a valid configuration. If so, such a node is called mandatory, otherwise it is called optional. This constraint is closely related to the notion of mandatory nodes in Section 3.1 in [RFC6020]. The only difference is that this document also considers list keys to be mandatory.
まず、特定のデータノードが常に有効な構成に存在する必要があるかどうかを決定する必要があります。その場合、そのようなノードは必須と呼ばれ、それ以外の場合はオプションと呼ばれます。この制約は、[RFC6020]のセクション3.1の必須ノードの概念と密接に関連しています。唯一の違いは、このドキュメントがリストキーが必須であるとも考慮していることです。
The other occurrence constraint has to do with the semantics of the 'default' statement and the possibility of removing empty non-presence containers. As a result, the information set of a valid configuration may be modified by adding or removing certain leaf or container elements without changing the meaning of the configuration. In this document, such elements are called implicit. In the hybrid schema, they can be identified as RELAX NG patterns having either the @nma:default or the @nma:implicit attribute.
もう1つの発生制約は、「デフォルト」ステートメントのセマンティクスと、空の非表定コンテナを削除する可能性に関係しています。その結果、有効な構成の情報セットは、構成の意味を変更せずに特定の葉または容器要素を追加または削除することにより変更できます。このドキュメントでは、そのような要素は暗黙的と呼ばれます。ハイブリッドスキーマでは、@NMA：デフォルトまたは@NMA：暗黙的な属性のいずれかを持つリラックスNGパターンとして識別できます。
Note that both occurrence constraints apply to containers at the top level of the data tree, and then also to other containers under the additional condition that their parent node exists in the instance document. For example, consider the following YANG fragment:
両方の発生制約は、データツリーの最上位レベルのコンテナに、そしてインスタンスドキュメントに親ノードが存在する追加の条件下で他のコンテナにも適用されることに注意してください。たとえば、次のヤンフラグメントを検討してください。
container outer {
presence 'Presence of "outer" means something.';
container c1 {
leaf foo {
type uint8;
default 1;
}
}
container c2 {
leaf-list bar {
type uint8;
min-elements 0;
}
}
container c3 {
leaf baz {
type uint8;
mandatory true;
}
}
}
Here, container "outer" has the 'presence' substatement, which means that it is optional and not implicit. If "outer" is not present in a configuration, its child containers are not present as well. However, if "outer" does exist, it makes sense to ask which of its child containers are optional and which are implicit. In this case, "c1" is optional and implicit, "c2" is optional but not implicit, and "c3" is mandatory (and therefore not implicit).
ここで、コンテナ「外側」には「存在」の代替物があります。これは、オプションであり、暗黙的ではないことを意味します。「外側」が構成に存在しない場合、その子容器も同様に存在しません。ただし、「外側」が存在する場合、子供の容器のどれがオプションで、どの子供が暗黙的であるかを尋ねるのは理にかなっています。この場合、「C1」はオプションで暗黙的であり、「C2」はオプションですが、暗黙的ではなく、「C3」は必須です（したがって暗黙的ではありません）。
The following subsections give precise rules for determining whether a container is optional or mandatory and whether it is implicit. In order to simplify the recursive definition of these occurrence characteristics, it is useful to define them also for other types of YANG schema nodes, i.e., leaf, list, leaf-list, anyxml, and choice.
次のサブセクションは、コンテナがオプションであるか必須か、それが暗黙的かを決定するための正確なルールを提供します。これらの発生特性の再帰的定義を簡素化するために、他のタイプのYangスキーマノード、つまり葉、リスト、葉リスト、AnyXML、および選択についても定義することが有用です。
The decision whether a given node is mandatory or optional is governed by the following rules: o Leaf, anyxml, and choice nodes are mandatory if they contain the substatement "mandatory true;". For a choice node, this means that at least one node from exactly one case branch must exist.
特定のノードが必須であるかオプションであるかどうかの決定は、次のルールに準拠しています。O葉、anyXML、および選択ノードには、「必須の真」;選択ノードの場合、これは、1つのケースブランチから少なくとも1つのノードが存在する必要があることを意味します。
o In addition, a leaf node is mandatory if it is declared as a list key.
o さらに、リストキーとして宣言されている場合、リーフノードは必須です。
o A list or leaf-list node is mandatory if it contains the 'min-elements' substatement with an argument value greater than zero.
o リストまたはリーフリストノードは、ゼロより大きい引数値を持つ「ミニエレメント」のサクセクトメントが含まれている場合、必須です。
o A container node is mandatory if its definition does not contain the 'presence' substatement and at least one of its child nodes is mandatory.
o 定義に「存在」の置換が含まれていない場合、コンテナノードは必須であり、少なくとも1つの子ノードが必須です。
A node that is not mandatory is said to be optional.
必須ではないノードはオプションであると言われています。
In RELAX NG, definitions of nodes that are optional must be explicitly wrapped in the <rng:optional> element. The mapping MUST use the above rules to determine whether a YANG node is optional, and if so, insert the <rng:optional> element in the hybrid schema.
リラックスngでは、オプションのノードの定義は、<rng：optional>要素に明示的にラップする必要があります。マッピングは、上記のルールを使用して、Yangノードがオプションであるかどうかを判断する必要があります。その場合、ハイブリッドスキーマに<rng：optional>要素を挿入する必要があります。
However, alternatives in <rng:choice> MUST NOT be defined as optional in the hybrid schema. If a choice in YANG is not mandatory, <rng: optional> MUST be used to wrap the entire <rng:choice> pattern.
ただし、<rng：choice>の代替案は、ハイブリッドスキーマでオプションとして定義してはなりません。Yangの選択が必須でない場合、<rng：オプション>を使用して、<rng：choice>パターン全体をラップする必要があります。
The following rules are used to determine whether a given data node is implicit:
次のルールを使用して、特定のデータノードが暗黙的であるかどうかを判断します。
o List, leaf-list, and anyxml nodes are never implicit.
o リスト、リーフリスト、およびanyXMLノードは決して暗黙的ではありません。
o A leaf node is implicit if and only if it has a default value, defined either directly or via its data type.
o リーフノードは、直接またはデータ型を介して定義されたデフォルト値がある場合にのみ暗黙的です。
o A container node is implicit if and only if it does not have the 'presence' substatement, none of its children are mandatory, and at least one child is implicit.
o コンテナノードは、「存在」の置換がない場合にのみ暗黙的です。子供はいずれも必須であり、少なくとも1人の子供が暗黙的です。
In the hybrid schema, all implicit containers, as well as leafs that obtain their default value from a typedef and don't have the @nma: default attribute, MUST be marked with @nma:implicit attribute having the value of "true".
ハイブリッドスキーマでは、すべての暗黙のコンテナ、およびtypedefからデフォルト値を取得し、@NMA：デフォルト属性を持たないリーフは、@NMA：「true」の値を持つ暗黙的属性でマークする必要があります。
Note that Section 7.9.3 in [RFC6020] specifies other rules that must be taken into account when deciding whether or not a given container or leaf appearing inside a case of a choice is ultimately implicit. Specifically, a leaf or container under a case can be implicit only if the case appears in the argument of the choice's 'default' statement. However, this is not sufficient by itself but also depends on the particular instance XML document, namely on the presence or absence of nodes from other (non-default) cases. The details are explained in Section 11.3.
[RFC6020]のセクション7.9.3は、選択の場合に表示される特定の容器または葉が最終的に暗黙的であるかどうかを決定する際に考慮する必要がある他のルールを指定していることに注意してください。具体的には、ケースの下の葉または容器は、選択の「デフォルト」ステートメントの引数にケースが表示される場合にのみ暗黙的になります。ただし、これだけでは十分ではありませんが、特定のインスタンスXMLドキュメント、つまり他の（非デフォルト）ケースからのノードの有無にも依存します。詳細については、セクション11.3で説明しています。
YANG groupings and typedefs are generally mapped to RELAX NG named patterns. There are, however, several caveats that the mapping has to take into account.
YangグループとTypedefsは、通常、名前が付けられたパターンをリラックスするためにマッピングされます。ただし、マッピングが考慮する必要があるいくつかの注意事項があります。
First of all, YANG typedefs and groupings may appear at all levels of the module hierarchy and are subject to lexical scoping, see Section 5.5 in [RFC6020]. Second, top-level symbols from external modules may be imported as qualified names represented using the external module namespace prefix and the name of the symbol. In contrast, named patterns in RELAX NG (both local and imported via the <rng: include> pattern) share the same namespace and within a grammar they are always global -- their definitions may only appear at the top level as children of the <rng:grammar> element. Consequently, whenever YANG groupings and typedefs are mapped to RELAX NG named pattern definitions, their names MUST be disambiguated in order to avoid naming conflicts. The mapping uses the following procedure for mangling the names of groupings and type definitions:
まず第一に、Yang Typedefとグループ化は、モジュール階層のすべてのレベルで表示され、語彙スコーピングの対象となる場合があります。[RFC6020]のセクション5.5を参照してください。第二に、外部モジュールからのトップレベルのシンボルは、外部モジュール名空間プレフィックスとシンボルの名前を使用して表現される適格名としてインポートできます。対照的に、リラックスngの名前のパターン（ローカルと<rng：include> patternを介してインポートされます）同じ名前空間を共有し、文法の中で常にグローバルです。RNG：文法>要素。その結果、YangグループとTypedefsがマッピングされている場合はいつでも、パターン定義という名前のngをリラックスさせるには、競合の命名を避けるために名前を曖昧にする必要があります。マッピングは、グループ化の名前とタイプ定義の名前をマングするために、次の手順を使用します。
o Names of groupings and typedefs appearing at the top level of the YANG module hierarchy are prefixed with the module name and two underscore characters ("__").
o Yangモジュール階層の上位レベルに表示されるグループ化とtypedefsの名前には、モジュール名と2つのアンダースコア文字（「__」）が付いています。
o Names of other groupings and typedefs, i.e., those that do not appear at the top level of a YANG module, are prefixed with the module name, double underscore, and then the names of all ancestor data nodes separated by double underscore.
o 他のグループの名前、つまり、Yangモジュールの上位レベルに表示されない名前は、モジュール名、ダブルアンダースコア、次にダブルアンダースコアで区切られたすべての祖先データノードの名前が付いています。
o Finally, since the names of groupings and typedefs in YANG have different namespaces, an additional underscore character is added to the beginning of the mangled names of all groupings.
o 最後に、Yangのグループ化とtypedefsの名前は異なる名前空間を持っているため、すべてのグループのマングルされた名前の先頭に追加のアンダースコア文字が追加されます。
An additional complication is caused by the YANG rules for subelement ordering (see, e.g., Section 7.5.7 in [RFC6020]): in RPC input and output parameters, subelements must follow the order specified in the data model; otherwise, the order is arbitrary. Consequently, if a grouping is used both in RPC input/output parameters and elsewhere, it MUST be mapped to two different named pattern definitions -- one with fixed order and the other with arbitrary order. To distinguish them, the "__rpc" suffix MUST be appended to the version with fixed order.
追加の合併症は、サブエレメントの順序付けのYangルールによって引き起こされます（例えば、[RFC6020]のセクション7.5.7を参照）：RPC入力および出力パラメーターでは、サブエレメントはデータモデルで指定された順序に従う必要があります。それ以外の場合、順序はarbitrary意的です。したがって、グループがRPC入力/出力パラメーターと他の場所の両方で使用されている場合、2つの異なる名前のパターン定義にマッピングする必要があります。それらを区別するには、「__RPC」接尾辞を固定注文でバージョンに追加する必要があります。
EXAMPLE. Consider the following YANG module that imports the standard module "ietf-inet-types" [RFC6021]:
例。標準モジュール「IETF-INET-TYPES」[RFC6021]をインポートする次のYangモジュールを考えてみましょう。
module example1 {
namespace "http://example.com/ns/example1";
prefix ex1;
typedef vowels {
type string {
pattern "[aeiouy]*";
}
}
grouping "grp1" {
leaf "void" {
type "empty";
}
}
container "cont" {
leaf foo {
type vowels;
}
uses "grp1";
}
}
The hybrid schema generated by the first mapping step will then contain the following two (global) named pattern definitions:
最初のマッピングステップで生成されたハイブリッドスキーマには、次の2つの（グローバル）名前のパターン定義が含まれます。
<rng:define name="example1__vowels">
<rng:data type="string">
<rng:param name="pattern">[aeiouy]*</rng:param>
</rng:data>
</rng:define>
<rng:define name="_example1__grp1">
<rng:optional>
<rng:element name="void">
<rng:empty/>
</rng:element>
</rng:optional>
</rng:define>
YANG groupings represent a similar concept as named pattern definitions in RELAX NG, and both languages also offer mechanisms for their subsequent modification. However, in RELAX NG, the definitions themselves are modified, whereas YANG provides two substatements of 'uses', which modify expansions of groupings: o The 'refine' statement allows for changing parameters of a schema node inside the grouping referenced by the parent 'uses' statement;
Yangグループは、リラックスNGの名前付きパターン定義と同様の概念を表しており、両方の言語もその後の変更のメカニズムを提供します。ただし、リラックスngでは、定義自体が変更されますが、Yangはグループ化の拡張を変更する「使用」の2つの置換を提供します。o「Refine」ステートメントでは、親が参照されるグループ内のスキーマノードのパラメーターのパラメーターを変更できます。使用する声明。
o The 'augment' statement can be used for adding new schema nodes to the grouping contents.
o 「Augment」ステートメントは、グループ化内容に新しいスキーマノードを追加するために使用できます。
Both 'refine' and 'augment' statements are quite powerful in that they can address, using XPath-like expressions as their arguments, schema nodes that are arbitrarily deep inside the grouping contents. In contrast, modifications of named pattern definitions in RELAX NG are applied exclusively at the topmost level of the named pattern contents. In order to achieve a modifiability of named patterns comparable to YANG, a RELAX NG schema would have to be extremely flat (cf. Section 8.3) and very difficult to read.
XPathのような表現を引数として使用して、グループ内コンテンツの奥深くにあるスキーマノードを使用して、「洗練」と「拡張」ステートメントの両方が非常に強力です。対照的に、リラックスNGの名前付きパターン定義の変更は、指定されたパターンコンテンツの最上位レベルでのみ適用されます。Yangに匹敵する名前付きパターンの変更性を実現するには、リラックスNGスキーマは非常にフラットでなければならず（セクション8.3を参照）、読みにくいです。
Since the goal of the mapping described in this document is to generate ad hoc DSDL schemas, we decided to avoid these complications and instead expand the grouping and refine and/or augment it "in place". In other words, every 'uses' statement that has 'refine' and/or 'augment' substatements is replaced by the contents of the corresponding grouping, the changes specified in the 'refine' and 'augment' statements are applied, and the resulting YANG schema fragment is mapped as if the 'uses'/'grouping' indirection wasn't there.
このドキュメントで説明されているマッピングの目標はアドホックDSDLスキーマを生成することであるため、これらの合併症を回避し、代わりにグループ化を拡張し、「所定の位置に」洗練および/または増強することにしました。言い換えれば、「洗練」および/または「拡張」の置換を持つすべての「使用」ステートメントは、対応するグループ化の内容、「改良」と「拡張」ステートメントで指定された変更が適用され、結果の声明が置き換えられます。Yangスキーマフラグメントは、「使用」/「グループ化」間接がないかのようにマッピングされています。
If there are further 'uses' statements inside the grouping contents, they may require expansion, too: it is necessary if the contained 'uses'/'grouping' pair lies on the "modification path" specified in the argument of a 'refine' or 'augment' statement.
グループコンテンツ内にさらに「使用」ステートメントがある場合、拡張が必要になる場合があります。「使用」/「グループ化」ペアが「refine」の引数で指定された「変更パス」にある場合に必要な場合があります。または「拡張」声明。
EXAMPLE. Consider the following YANG module:
例。次のYangモジュールを検討してください。
module example2 {
namespace "http://example.com/ns/example2";
prefix ex2;
grouping leaves {
uses fr;
uses es;
}
grouping fr {
leaf feuille {
type string;
}
}
grouping es {
leaf hoja {
type string;
}
}
uses leaves;
}
The resulting hybrid schema contains three global named pattern definitions corresponding to the three groupings, namely:
結果のハイブリッドスキーマには、3つのグループに対応する3つのグローバル指名パターン定義が含まれています。
<rng:define name="_example2__leaves">
<rng:interleave>
<rng:ref name="_example2__fr"/>
<rng:ref name="_example2__es"/>
</rng:interleave>
</rng:define>
<rng:define name="_example2__fr">
<rng:optional>
<rng:element name="feuille">
<rng:data type="string"/>
</rng:element>
</rng:optional>
</rng:define>
<rng:define name="_example2__es"> <rng:optional> <rng:element name="hoja"> <rng:data type="string"/> </rng:element> </rng:optional> </rng:define> and the configuration data part of the hybrid schema is a single named pattern reference:
<rng：define name = "_ embles2__ES"> <rng：optional> <rng：element name = "hoja"> <rng：data型= "string"/>> </rng：element> </rng：optional> </RNG：定義>およびハイブリッドスキーマの構成データ部分は、パターン参照の単一です。
<nma:data>
<rng:ref name="_example2__leaves"/>
</nma:data>
Now assume that the "uses leaves" statement contains a 'refine' substatement, for example:
「使用する葉」のステートメントには、「洗練」の代替物が含まれていると仮定します。たとえば、次のようです。
uses leaves {
refine "hoja" {
default "alamo";
}
}
The resulting hybrid schema now contains just one named pattern definition - "_example2__fr". The other two groupings "leaves" and "es" have to be expanded because they both lie on the "modification path", i.e., contain the leaf "hoja" that is being refined. The configuration data part of the hybrid schema now looks like this:
結果として得られるハイブリッドスキーマには、1つの名前のパターン定義のみが含まれています - 「_example2__fr」。他の2つのグループは「葉」と「es」を拡張する必要があります。どちらも「修正パス」、つまり洗練されている葉の「hoja」が含まれているためです。ハイブリッドスキーマの構成データ部分は、次のようになりました。
<nma:data>
<rng:interleave>
<rng:ref name="_example2__fr"/>
<rng:optional>
<rng:element name="ex2:hoja" nma:default="alamo">
<rng:data type="string"/>
</rng:element>
</rng:optional>
</rng:interleave>
</nma:data>
RELAX NG has no equivalent of the type derivation mechanism in YANG that allows one to restrict a built-in type (perhaps in multiple steps) by adding new constraints. Whenever a derived YANG type is used without restrictions -- as a substatement of either 'leaf' or another 'typedef' -- then the 'type' statement is mapped simply to a named pattern reference <rng:ref>, and the type definition is mapped to a RELAX NG named pattern definition <rng:define>. However, if any restrictions are specified as substatements of the 'type' statement, the type definition MUST be expanded at that point so that only the ancestor built-in type appears in the hybrid schema, restricted with facets that correspond to the combination of all restrictions found along the type derivation chain and also in the 'type' statement.
Relax Ngには、新しい制約を追加することにより、組み込みのタイプ（おそらく複数のステップで）を制限できるYangのタイプ派生メカニズムに相当するものはありません。「葉」または別の「typedef」のいずれかの置換として制限なしに派生したYangタイプが使用される場合は、「タイプ」ステートメントは、名前付きパターン参照<RNG：REF>、およびタイプ定義に単純にマッピングされます。パターン定義という名前のリラックスngにマッピングされます<rng：define>。ただし、「タイプ」ステートメントの置換として制限が指定されている場合、その時点でタイプ定義を拡張して、先祖組み込みのタイプのみがハイブリッドスキーマに表示され、すべての組み合わせに対応するファセットに制限されるようにする必要があります。タイプ派生チェーンおよび「タイプ」ステートメントに沿って見つかった制限。
EXAMPLE. Consider this YANG module:
例。このヤンモジュールを考えてみましょう。
module example3 {
namespace "http://example.com/ns/example3";
prefix ex3;
typedef dozen {
type uint8 {
range 1..12;
}
}
leaf month {
type dozen;
}
}
The 'type' statement in "leaf month" has no restrictions and is therefore mapped simply to the reference <rng:ref name="example3__dozen"/> and the corresponding named pattern is defined as follows:
「Leaf Month」の「タイプ」ステートメントには制限がないため、参照<rng：ref name = "emple3__dozen"/>に単純にマッピングされ、対応する名前のパターンは次のように定義されます。
<rng:define name="example3__dozen">
<rng:data type="unsignedByte">
<rng:param name="minInclusive">1</rng:param>
<rng:param name="maxInclusive">12</rng:param>
</rng:data>
</rng:define>
Assume now that the definition of leaf "month" is changed to:
葉の「月」の定義が次のように変更されると仮定します。
leaf month {
type dozen {
range 7..max;
}
}
The output RELAX NG schema then will not contain any named pattern definition and the leaf "month" will be mapped directly to:
出力リラックスngスキーマには名前付きパターン定義は含まれず、葉の「月」は次のように直接マッピングされます。
<rng:element name="ex3:month">
<rng:data type="unsignedByte">
<rng:param name="minInclusive">7</rng:param>
<rng:param name="maxInclusive">12</rng:param>
</rng:data>
</rng:element>
The mapping of type derivation chains may be further complicated by the presence of the 'default' statement in type definitions. In the simple case, when a type definition containing the 'default' statement is used without restrictions, the 'default' statement is mapped to the @nma:default attribute attached to the <rng:define> element.
タイプ導出チェーンのマッピングは、タイプ定義に「デフォルト」ステートメントが存在することにより、さらに複雑になる可能性があります。単純な場合、「デフォルト」ステートメントを含むタイプ定義が制限なしに使用される場合、「デフォルト」ステートメントは@NMA：<rng：define>要素に添付されている@NMA：デフォルト属性にマッピングされます。
However, if that type definition has to be expanded due to restrictions, the @nma:default attribute arising from the expanded type or ancestor types in the type derivation chain MUST be attached to the pattern where the expansion occurs. If there are multiple 'default' statements in consecutive steps of the type derivation, only the 'default' statement that is closest to the expanded type is used.
ただし、制限のためにそのタイプ定義を拡張する必要がある場合、 @nma：展開されたタイプまたは祖先タイプから生じるデフォルト属性は、拡張が発生するパターンに添付する必要があります。タイプ派生の連続した手順に複数の「デフォルト」ステートメントがある場合、拡張されたタイプに最も近い「デフォルト」ステートメントのみが使用されます。
EXAMPLE. Consider this variation of the last example:
例。最後の例のこのバリエーションを考えてみましょう。
module example3bis {
namespace "http://example.com/ns/example3bis";
prefix ex3bis;
typedef dozen {
type uint8 {
range 1..12;
}
default 7;
}
leaf month {
type dozen;
}
}
The 'typedef' statement in this module is mapped to the following named pattern definition:
このモジュールの「typedef」ステートメントは、次の名前のパターン定義にマッピングされます。
<rng:define name="example3bis__dozen" @nma:default="7">
<rng:data type="unsignedByte">
<rng:param name="minInclusive">1</rng:param>
<rng:param name="maxInclusive">12</rng:param>
</rng:data>
</rng:define>
If the "dozen" type is restricted when used in the leaf "month" definition, as in the previous example, the "dozen" type has to be expanded and @nma:default becomes an attribute of the <ex3bis:month> element definition:
前の例のように、葉の「月」の定義で使用されると「ダース」タイプが制限されている場合、「ダース」タイプを拡張し、@NMA：デフォルトは<ex3bis：月>要素定義の属性になります：
<rng:element name="ex3bis:month" @nma:default="7">
<rng:data type="unsignedByte">
<rng:param name="minInclusive">7</rng:param>
<rng:param name="maxInclusive">12</rng:param>
</rng:data>
</rng:element>
However, if the definition of the leaf "month" itself contained the 'default' substatement, the default specified for the "dozen" type would be ignored.
ただし、葉の「月」自体の定義に「デフォルト」の置換が含まれている場合、「ダース」タイプに指定されたデフォルトは無視されます。
YANG uses full XPath 1.0 syntax [XPath] for the arguments of 'must', 'when', and 'path' statements. As the names of data nodes defined in a YANG module always belong to the namespace of that YANG module, YANG adopted a simplification similar to the concept of default namespace in XPath 2.0: node names in XPath expressions needn't carry a namespace prefix inside the module where they are defined and the local module's namespace is assumed.
Yangは、「必須」、「 'When」、および「Path」ステートメントの引数に、完全なXpath 1.0 Syntax [XPath]を使用します。Yangモジュールで定義されているデータノードの名前は常にそのYangモジュールの名前空間に属しているため、YangはXpath 2.0のデフォルトネームスペースの概念と同様の簡素化を採用しました。XPathExpressionsのノード名は、その名前空間の接頭辞を持つ必要はありません。それらが定義されているモジュールとローカルモジュールの名前空間が想定されています。
Consequently, all XPath expressions MUST be translated into a fully conformant XPath 1.0 expression: every unprefixed node name MUST be prepended with the local module's namespace prefix as declared by the 'prefix' statement.
したがって、すべてのXPath式は、完全に適合したXPath 1.0式に変換する必要があります。すべての再固定されていないノード名は、「プレフィックス」ステートメントで宣言されたローカルモジュールの名前空間プレフィックスで準備する必要があります。
XPath expressions appearing inside top-level groupings require special attention because all unprefixed node names contained in them must adopt the namespace of each module where the grouping is used (cf. Section 8.2). In order to achieve this, the local prefix MUST be represented using the variable "$pref" in the hybrid schema. A Schematron schema which encounters such an XPath expression then supplies an appropriate value for this variable via a parameter to an abstract pattern to which the YANG grouping is mapped (see Section 11.2).
トップレベルのグループ内に表示されるXpath式は、グループに含まれるすべての再固定されていないノード名が使用される各モジュールの名前空間を採用する必要があるため、特別な注意が必要です（セクション8.2を参照）。これを達成するには、ローカルプレフィックスをハイブリッドスキーマの変数「$ pref」を使用して表現する必要があります。このようなXPATH式に遭遇するスキーマトロンスキーマは、パラメーターを介してこの変数に適切な値を提供し、Yangグループがマッピングされている抽象パターンに提供されます（セクション11.2を参照）。
For example, XPath expression "/dhcp/max-lease-time" appearing in a YANG module with the "dhcp" prefix will be translated to:
たとえば、「DHCP」プレフィックスを備えたYangモジュールに表示されるXpath式 "/dhcp/max-lease-time"は以下に翻訳されます。
o "$pref:dhcp/$pref:max-lease-time", if the expression is inside a top-level grouping;
o 「$ pref：dhcp/$ pref：max-lease-time」、表現がトップレベルのグループ内にある場合。
o "dhcp:dhcp/dhcp:max-lease-time", otherwise.
o 「DHCP：DHCP/DHCP：Max-Lease-Time」、それ以外の場合。
YANG also uses other XPath-like expressions, namely key identifiers and "descendant schema node identifiers" (see the ABNF production for and "descendant-schema-nodeid" in Section 12 of [RFC6020]). These expressions MUST be translated by adding local module prefixes as well.
Yangは、他のXpathのような式、すなわち重要な識別子と「子孫スキーマノード識別子」も使用しています（[RFC6020]のセクション12のABNF生産および「子孫 - 系統型」を参照）。これらの式は、ローカルモジュールのプレフィックスも追加して翻訳する必要があります。
YANG allows for extending its own language in-line by adding new statements with keywords from special namespaces. Such extensions first have to be declared using the 'extension' statement, and then they can be used as the standard YANG statements, from which they are distinguished by a namespace prefix qualifying the extension keyword. RELAX NG has a similar extension mechanism -- XML elements and attributes with names from foreign namespaces may be inserted at almost any place of a RELAX NG schema.
Yangは、特別な名前空間からキーワードを含む新しいステートメントを追加することにより、独自の言語をインラインで拡張することができます。このような拡張機能は、最初に「拡張機能」ステートメントを使用して宣言する必要があり、次に標準のYangステートメントとして使用でき、そこから拡張キーワードを適格な名前空間プレフィックスによって区別されます。Relax Ngには同様の拡張メカニズムがあります。XML要素と、外国の名前空間からの名前の属性は、リラックスNGスキーマのほぼすべての場所に挿入される場合があります。
YANG language extensions may or may not have a meaning in the context of DSDL schemas. Therefore, an implementation MAY ignore any or all of the extensions. However, an extension that is not ignored MUST be mapped to XML element(s) and/or attribute(s) that exactly match the YIN form of the extension, see Section 11.1 in [RFC6020].
Yang Language Extensionsは、DSDLスキーマのコンテキストで意味を持つ場合とそうでない場合があります。したがって、実装では、拡張機能の一部またはすべてが無視される場合があります。ただし、無視されていない拡張機能は、拡張機能のYIN形式と正確に一致するXML要素および/または属性にマッピングする必要があります。[RFC6020]のセクション11.1を参照してください。
EXAMPLE. Consider the following extension defined by the "acme" module:
例。「ACME」モジュールで定義された次の拡張を検討してください。
extension documentation-flag {
argument number;
}
This extension can then be used in the same or another module, for instance like this:
この拡張機能は、このようなものなど、同じモジュールまたは別のモジュールで使用できます。
leaf folio {
acme:documentation-flag 42;
type string;
}
If this extension is honored by the mapping, it will be mapped to:
この拡張機能がマッピングによって表彰されている場合、次のようにマッピングされます。
<rng:element name="acme:folio">
<acme:documentation-flag number="42"/>
<rng:data type="string"/>
</rng:element>
Note that the 'extension' statement itself is not mapped in any way.
「拡張機能」ステートメント自体は決してマッピングされていないことに注意してください。
Each subsection in this section is devoted to one YANG statement and provides the specification of how the statement is mapped to the hybrid schema. The subsections are sorted alphabetically by the statement keyword.
このセクションの各サブセクションは、1つのYangステートメントに専念し、ステートメントがハイブリッドスキーマにマッピングされる方法の仕様を提供します。サブセクションは、ステートメントキーワードによってアルファベット順にソートされます。
Each YANG statement is mapped to an XML fragment, typically a single element or attribute, but it may also be a larger structure. The mapping procedure is inherently recursive, which means that after finishing a statement the mapping continues with its substatements, if there are any, and a certain element of the resulting fragment becomes the parent of other fragments resulting from the mapping of substatements. Any changes to this default recursive procedure are explicitly specified.
各Yangステートメントは、XMLフラグメント、通常は単一の要素または属性にマッピングされますが、より大きな構造である可能性もあります。マッピング手順は本質的に再帰的です。つまり、ステートメントを終了した後、マッピングがその置換で継続されます。このデフォルトの再帰手順の変更は明示的に指定されています。
YANG XML encoding rules translate to the following rules for ordering multiple subelements:
Yang XMLエンコードルールは、複数のサブエレメントを注文するための次のルールに変換されます。
1. Within the <nma:rpcs> subtree (i.e., for input and output parameters of an RPC operation) the order of subelements is fixed and their definitions in the hybrid schema MUST follow the order specified in the source YANG module.
1. <nma：rpcs> subtree（つまり、RPC操作の入力および出力パラメーターの場合）内で、サブエレメントの順序が固定されており、ハイブリッドスキーマの定義はソースYangモジュールで指定された順序に従う必要があります。
2. When mapping the 'list' statement, all keys MUST come before any other subelements and in the same order as they are declared in the 'key' statement. The order of the remaining (non-key) subelements is not specified, so their definitions in the hybrid schema MUST be enclosed in the <rng:interleave> element.
2. 「リスト」ステートメントをマッピングする場合、すべてのキーは、他のサブエレメントの前に、および「キー」ステートメントで宣言されているのと同じ順序で来なければなりません。残りの（非キー）サブエレメントの順序は指定されていないため、ハイブリッドスキーマの定義は<rng：interleave>要素に囲まれている必要があります。
3. Otherwise, the order of subelements is arbitrary and, consequently, all definitions of subelements in the hybrid schema MUST be enclosed in the <rng:interleave> element.
3. それ以外の場合、サブエレメントの順序は任意であり、その結果、ハイブリッドスキーマ内のサブエレメントのすべての定義は、<rng：interleave>要素に囲む必要があります。
The following conventions are used in this section:
このセクションでは、次の規則を使用しています。
o The argument of the statement being mapped is denoted by ARGUMENT.
o マッピングされている声明の引数は、引数によって示されます。
o The element in the RELAX NG schema that becomes the parent of the resulting XML fragment is denoted by PARENT.
o 結果のXMLフラグメントの親になるリラックスNGスキーマの要素は、親によって示されます。
This statement is mapped to the <rng:element> element and ARGUMENT with prepended local namespace prefix becomes the value of its @name attribute. The contents of <rng:element> are:
このステートメントは、<rng：element> element and引数にマッピングされます。<rng：element>の内容は次のとおりです。
<rng:ref name="__anyxml__"/> Substatements of the 'anyxml' statement, if any, MAY be mapped to additional children of the <rng:element> element.
<rng：ref name = "__ anyxml __"/>「anyxml」ステートメントの置換は、<rng：element> elementの追加の子供にマッピングされる場合があります。
If at least one 'anyxml' statement occurs in any of the input YANG modules, the following pattern definition MUST be added exactly once to the RELAX NG schema as a child of the root <rng:grammar> element (cf. [Vli04], p. 172):
入力Yangモジュールのいずれかで少なくとも1つの「anyxml」ステートメントが発生した場合、次のパターン定義は、ルートの子としてのリラックスngスキーマに正確に1回追加する必要があります<rng：grammar> element（cf. [vli04]、p。172）：
<rng:define name="__anyxml__">
<rng:zeroOrMore>
<rng:choice>
<rng:attribute>
<rng:anyName/>
</rng:attribute>
<rng:element>
<rng:anyName/>
<rng:ref name="__anyxml__"/>
</rng:element>
<rng:text/>
</rng:choice>
</rng:zeroOrMore>
</rng:define>
EXAMPLE: YANG statement in a module with namespace prefix "yam"
例：名前空間プレフィックス「Yam」を備えたモジュールのYangステートメント
anyxml data {
description "Any XML content allowed here.";
}
is mapped to the following fragment:
次のフラグメントにマッピングされます。
<rng:element name="yam:data">
<a:documentation>Any XML content allowed here</a:documentation>
<rng:ref name="__anyxml__"/>
</rng:element>
An anyxml node is optional if there is no "mandatory true;" substatement. The <rng:element> element then MUST be wrapped in <rng:optional>, except when the 'anyxml' statement is a child of the 'choice' statement and thus forms a shorthand case for that choice (see Section 9.1.1 for details).
anyXMLノードは、「必須のtrue」がない場合、オプションです。置換。<rng：element> elementは、「anyxml」ステートメントが「選択」ステートメントの子であるため、その選択の速記のケースを形成する場合を除き、<rng：optional>にラップする必要があります（セクション9.1.1を参照してください。詳細）。
This statement is not mapped to the output schema, but see the rules for handling extensions in Section 9.4.
このステートメントは出力スキーマにマッピングされていませんが、セクション9.4の拡張機能を処理するためのルールを参照してください。
As a substatement of 'uses', this statement is handled as a part of 'uses' mapping, see Section 10.57.
「使用」の代替として、このステートメントは「使用」マッピングの一部として処理されます。セクション10.57を参照してください。
At the top level of a module or submodule, the 'augment' statement is used for augmenting the schema tree of another YANG module. If the augmented module is not processed within the same mapping session, the top-level 'augment' statement MUST be ignored. Otherwise, the contents of the statement are added to the foreign module with the namespace of the module where the 'augment' statement appears.
モジュールまたはサブモジュールの最上位レベルでは、別のヤンモジュールのスキーマツリーを拡張するために「Augment」ステートメントが使用されます。拡張モジュールが同じマッピングセッション内で処理されない場合、トップレベルの「Augment」ステートメントは無視する必要があります。それ以外の場合、ステートメントの内容は、「Augment」ステートメントが表示されるモジュールの名前空間を使用して、外部モジュールに追加されます。
This statement is ignored as a substatement of 'identity' and handled within the 'identityref' type if it appears as a substatement of that type definition, see Section 10.53.6.
このステートメントは、「アイデンティティ」の代替として無視され、そのタイプ定義の置換として表示される場合は、「IDEF」タイプ内で処理されます。セクション10.53.6を参照してください。
This statement is not used since the processing of submodules is always initiated from the main module, see Section 10.24.
サブモジュールの処理は常にメインモジュールから開始されるため、このステートメントは使用されません。セクション10.24を参照してください。
This statement is handled within the "bits" type, see Section 10.53.4.
このステートメントは、「ビット」タイプ内で処理されます。セクション10.53.4を参照してください。
This statement is mapped to the <rng:group> or <rng:interleave> element, depending on whether or not the statement belongs to an definition of an RPC operation. If the argument of a sibling 'default' statement equals to ARGUMENT, the @nma:implicit attribute with the value of "true" MUST be added to that <rng:group> or <rng: interleave> element. The @nma:implicit attribute MUST NOT be used for nodes at the top-level of a non-default case (see Section 7.9.3 in [RFC6020]).
このステートメントは、ステートメントがRPC操作の定義に属するかどうかに応じて、<rng：group>または<rng：interleave>要素にマッピングされます。兄弟の「デフォルト」ステートメントの引数が引数に等しい場合、@NMA：「true」の値を持つ暗黙の属性は、その<rng：group>または<rng：interleave>要素に追加する必要があります。@NMA：暗黙の属性は、非デフォルトケースのトップレベルでノードに使用してはなりません（[RFC6020]のセクション7.9.3を参照）。
This statement is mapped to the <rng:choice> element.
このステートメントは、<rng：choice>要素にマッピングされます。
If 'choice' has the 'mandatory' substatement with the value of "true", the attribute @nma:mandatory MUST be added to the <rng: choice> element with the value of ARGUMENT. This case may require additional handling, see Section 11.2.1. Otherwise, if "mandatory true;" is not present, the <rng:choice> element MUST be wrapped in <rng:optional>.
「選択」に「true」の値に「必須」の置換がある場合、属性@NMA：必須は、引数の値を持つ<rng：choice>要素に追加する必要があります。このケースは追加の取り扱いが必要になる場合があります。セクション11.2.1を参照してください。それ以外の場合、「必須の真実」の場合。存在しない、<rng：choice>要素は<rng：optional>にラップする必要があります。
The alternatives in <rng:choice> -- mapped from either the 'case' statement or a shorthand case -- MUST NOT be defined as optional.
<rng：choice>の代替案 - 「ケース」ステートメントまたは速記のケースのいずれかからマッピングされたものは、オプションとして定義してはなりません。
This statement is mapped to the @nma:config attribute, and ARGUMENT becomes its value.
このステートメントは@NMA：config属性にマッピングされ、引数がその値になります。
This statement SHOULD NOT be used by the mapping since the hybrid schema may be mapped from multiple YANG modules created by different authors. The hybrid schema contains references to all input modules in the Dublin Core elements <dc:source>, see Section 10.34. The original YANG modules are the authoritative sources of the authorship information.
ハイブリッドスキーマは、異なる著者によって作成された複数のYangモジュールからマッピングされる可能性があるため、このステートメントはマッピングで使用されるべきではありません。ハイブリッドスキーマには、ダブリンコア要素のすべての入力モジュールへの参照が含まれています<DC：ソース>、セクション10.34を参照してください。元のYangモジュールは、著者情報の権威あるソースです。
Using the rules specified in Section 9.1.1, the mapping algorithm MUST determine whether the statement defines an optional container, and if so, insert the <rng:optional> element and make it the new PARENT.
セクション9.1.1で指定されたルールを使用して、マッピングアルゴリズムは、ステートメントがオプションのコンテナを定義するかどうかを判断する必要があります。その場合、<rng：optional>要素を挿入し、新しい親にします。
The container defined by this statement is then mapped to the <rng: element> element, which becomes a child of PARENT and uses ARGUMENT with prepended local namespace prefix as the value of its @name attribute.
このステートメントで定義されたコンテナは、<rng：element> elementにマッピングされます。これは、親の子になり、@name属性の値としてpregenedローカルネームスペースプレフィックスを使用して引数を使用します。
Finally, using the rules specified in Section 9.1.2, the mapping algorithm MUST determine whether the container is implicit, and if so, add the attribute @nma:implicit with the value of "true" to the <rng:element> element.
最後に、セクション9.1.2で指定されたルールを使用して、マッピングアルゴリズムはコンテナが暗黙的であるかどうかを判断する必要があります。もしそうなら、属性@NMA：<rng：element> elementに「true」の値を暗黙的に追加する必要があります。
If this statement is a substatement of 'leaf', it is mapped to the @nma:default attribute of PARENT and ARGUMENT becomes its value.
このステートメントが「葉」の代替物である場合、@NMA：親のデフォルト属性と引数のデフォルト属性にマッピングされます。
As a substatement of 'typedef', the 'default' statement is also mapped to the @nma:default attribute with the value of ARGUMENT. The placement of this attribute depends on whether or not the type definition has to be expanded when it is used: o If the type definition is not expanded, @nma:default becomes an attribute of the <rng:define> pattern resulting from the parent 'typedef' mapping.
「typedef」の代替として、「デフォルト」ステートメントは、引数の値を持つ@NMA：デフォルト属性にもマッピングされます。この属性の配置は、使用時にタイプ定義を展開する必要があるかどうかによって異なります。Oタイプ定義が展開されていない場合、@NMA：デフォルトは親から生じる<rng：定義>パターンの属性になります「Typedef」マッピング。
o Otherwise, @nma:default becomes an attribute of the ancestor RELAX NG pattern inside which the expansion takes place.
o それ以外の場合、@NMA：デフォルトは、拡張が行われる祖先リラックスパターンの属性になります。
Details and an example are given in Section 9.2.2.
詳細と例は、セクション9.2.2に記載されています。
Finally, as a substatement of 'choice', the 'default' statement identifies the default case and is handled within the 'case' statement, see Section 10.7. If the default case uses the shorthand notation where the 'case' statement is omitted, the @nma:implicit attribute with the value of "true" is either attached to the node representing the default case in the shorthand notation or, alternatively, an extra <rng:group> element MAY be inserted and the @nma:implicit attribute attached to it. In the latter case, the net result is the same as if the 'case' statement wasn't omitted for the default case.
最後に、「選択」の代替として、「デフォルト」ステートメントはデフォルトのケースを識別し、「ケース」ステートメント内で処理されます。セクション10.7を参照してください。デフォルトのケースが「ケース」ステートメントが省略されている速記表記を使用する場合、@NMA：「true」の値を持つ暗黙の属性は、速記表記のデフォルトのケースを表すノードに添付されるか、あるいは余分な、余分なもの<RNG：Group>要素が挿入され、@NMA：暗黙の属性が添付されます。後者の場合、正味の結果は、デフォルトのケースで「ケース」ステートメントが省略されなかった場合と同じです。
EXAMPLE. The following 'choice' statement in a module with namespace prefix "yam"
例。名前空間プレフィックス「ヤム」を備えたモジュールの次の「選択」ステートメント
choice leaves {
default feuille;
leaf feuille { type empty; }
leaf hoja { type empty; }
}
is either mapped directly to:
次のいずれかに直接マッピングされます。
<rng:choice> <rng:element name="yam:feuille" nma:implicit="true"> <rng:empty/> </rng:element> <rng:element name="yam:hoja"> <rng:empty/> </rng:element/> </rng:choice> or the default case may be wrapped in an extra <rng:group>:
<rng：choice> <rng：element name = "yam：feuille" nma：blicit = "true"> <rng：empty/> </rng：element> <rng：element name = "yam：hoja"> <rng：empty/> </rng：element/> </rng：choice>またはデフォルトのケースは、余分な<rng：group>にラップされる場合があります。
<rng:choice>
<rng:group nma:implicit="true">
<rng:element name="yam:feuille">
<rng:empty/>
</rng:element>
</rng:group>
<rng:element name="yam:hoja">
<rng:empty/>
</rng:element/>
</rng:choice>
This statement is mapped to the DTD compatibility element <a:documentation> and ARGUMENT becomes its text.
このステートメントは、DTD互換性要素<A：ドキュメント>にマッピングされ、引数がテキストになります。
In order to get properly formatted in the RELAX NG compact syntax, this element SHOULD be inserted as the first child of PARENT.
リラックスNGコンパクトな構文で適切にフォーマットされるには、この要素を親の最初の子として挿入する必要があります。
This statement is ignored. However, it is assumed that all deviations are known beforehand and the corresponding changes have already been applied to the input YANG modules.
この声明は無視されます。ただし、すべての偏差は事前に知られており、対応する変更は既に入力Yangモジュールに適用されていると想定されています。
This statement is mapped to the <rng:value> element, and ARGUMENT becomes its text. All substatements except 'status' are ignored because the <rng:value> element cannot contain annotation elements, see [RNG], Section 6.
このステートメントは<rng：value>要素にマッピングされ、引数がテキストになります。<rng：value>要素には注釈要素が含まれないため、「ステータス」を除くすべての置換は無視されます。[RNG]、セクション6を参照してください。
This statement is ignored unless it is a substatement of 'must'. In the latter case, it is mapped to the <nma:error-app-tag> element. See also Section 10.35.
この声明は、「必須」の代替でない限り無視されます。後者の場合、<nma：error-app-tag>要素にマッピングされます。セクション10.35も参照してください。
This statement is ignored unless it is a substatement of 'must'. In the latter case, it is mapped to the <nma:error-message> element. See also Section 10.35.
この声明は、「必須」の代替でない限り無視されます。後者の場合、それは<nma：error-message>要素にマッピングされます。セクション10.35も参照してください。
This statement is ignored. However, extensions to the YANG language MAY be mapped as described in Section 9.4.
この声明は無視されます。ただし、Yang言語への拡張は、セクション9.4で説明されているようにマッピングできます。
This statement is ignored.
この声明は無視されます。
This statement is mapped to a RELAX NG named pattern definition <rng: define>, but only if the grouping defined by this statement is used without refinements and augments in at least one of the input modules. In this case, the named pattern definition becomes a child of the <rng:grammar> element and its name is ARGUMENT mangled according to the rules specified in Section 9.2.
このステートメントは、パターン定義という名前のリラックスng <rng：define>にマッピングされますが、このステートメントで定義されたグループが改良せずに使用され、入力モジュールの少なくとも1つで使用されます。この場合、指定されたパターン定義は<rng：grammar>要素の子になり、その名前はセクション9.2で指定されたルールに従ってマングルされています。
As explained in Section 8.2, a named pattern definition MUST be placed:
セクション8.2で説明されているように、名前付きパターン定義を配置する必要があります。
o as a child of the root <rng:grammar> element if the corresponding grouping is defined at the top level of an input YANG module;
o ルートの子として<rng：grammar>要素に対応するグループ化が入力ヤンモジュールの最上位レベルで定義されている場合。
o otherwise as a child of the embedded <rng:grammar> element corresponding to the module in which the grouping is defined.
o それ以外の場合は、グループ化が定義されているモジュールに対応する埋め込み<rng：grammar>要素の子として。
Whenever a grouping is used with refinements and/or augments, it is expanded so that the refinements and augments may be applied in place to the prescribed schema nodes. See Section 9.2.1 for further details and an example.
グループ化が改良および/または拡張で使用される場合はいつでも、拡張されているため、規定されたスキーマノードに洗練と拡張が適切に適用されるようにします。詳細と例については、セクション9.2.1を参照してください。
An implementation MAY offer the option of mapping all 'grouping' statements as named pattern definitions in the output RELAX NG schema even if they are not referenced. This is useful for mapping YANG "library" modules that typically contain only 'typedef' and/or 'grouping' statements.
実装は、たとえ参照されていなくても、出力リラックスNGスキーマの名前付きパターン定義としてすべての「グループ化」ステートメントをマッピングするオプションを提供する場合があります。これは、通常「typedef」および/または「グループ化」ステートメントのみを含むYangの「ライブラリ」モジュールをマッピングするのに役立ちます。
This statement is mapped to the following named pattern definition which is placed as a child of the root <rng:grammar> element:
このステートメントは、ルートの子として配置された次の名前のパターン定義にマッピングされます<rng：grammar>要素：
<rng:define name="__PREFIX_ARGUMENT">
<rng:choice>
<rng:value type="QName">PREFIX:ARGUMENT</rng:value>
<rng:ref name="IDENTITY1"/>
...
</rng:choice>
</rng:define>
where:
ただし：
PREFIX is the prefix used in the hybrid schema for the namespace of the module where the current identity is defined.
プレフィックスは、現在のIDが定義されているモジュールの名前空間のハイブリッドスキーマで使用されるプレフィックスです。
IDENTITY1 is the name of the named pattern corresponding to an identity that is derived from the current identity. Exactly one <rng:ref> element MUST be present for every such identity.
ID1は、現在のアイデンティティから派生したアイデンティティに対応する名前付きパターンの名前です。正確に1つの<rng：ref>そのようなアイデンティティごとに存在する必要があります。
EXAMPLE ([RFC6020], Section 7.16.3). Consider the following identities defined in two input YANG modules:
例（[RFC6020]、セクション7.16.3）。2つの入力Yangモジュールで定義されている次のIDを考えてみましょう。
module crypto-base {
namespace "http://example.com/crypto-base";
prefix "crypto";
identity crypto-alg {
description
"Base identity from which all crypto algorithms
are derived.";
}
}
module des {
namespace "http://example.com/des";
prefix "des";
import "crypto-base" {
prefix "crypto";
}
identity des {
base "crypto:crypto-alg";
description "DES crypto algorithm";
}
identity des3 {
base "crypto:crypto-alg";
description "Triple DES crypto algorithm";
}
}
The identities will be mapped to the following named pattern
definitions:
<define name="__crypto_crypto-alg">
<choice>
<value type="QName">crypto:crypto-alg</value>
<ref name="__des_des"/>
<ref name="__des_des3"/>
</choice>
</define>
<define name="__des_des">
<value type="QName">des:des</value>
</define>
<define name="__des_des3">
<value type="QName">des:des3</value>
</define>
ARGUMENT together with arguments of all sibling 'if-feature' statements (with added prefixes, if missing) MUST be collected in a space-separated list that becomes the value of the @nma:if-feature attribute. This attribute is attached to PARENT.
すべての兄弟の「if-feature」ステートメントの議論と一緒に議論（waking @nma：if-feature属性の値になるスペース分離リストに収集する必要があります。この属性は親に添付されています。
This statement is not specifically mapped. The module whose name is in ARGUMENT has to be parsed so that the importing module is able to use its top-level groupings, typedefs and identities, and also augment the data tree of the imported module.
このステートメントは具体的にマッピングされていません。名前が引数のモジュールを解析する必要があるため、インポートモジュールがトップレベルのグループ、Typedef、IDを使用し、インポートされたモジュールのデータツリーを拡張できるようにします。
If the 'import' statement has the 'revision' substatement, the corresponding revision of the imported module MUST be used. The mechanism for finding a given module revision is outside the scope of this document.
「インポート」ステートメントに「改訂」の表現がある場合、インポートされたモジュールの対応する改訂を使用する必要があります。特定のモジュールリビジョンを見つけるメカニズムは、このドキュメントの範囲外です。
This statement is not specifically mapped. The submodule whose name is in ARGUMENT has to be parsed and its contents mapped exactly as if the submodule text appeared directly in the main module text.
このステートメントは具体的にマッピングされていません。引数の名前があるサブモジュールは解析する必要があり、その内容はまるでサブモジュールテキストがメインモジュールテキストに直接表示されているかのようにマッピングされます。
If the 'include' statement has the 'revision' substatement, the corresponding revision of the submodule MUST be used. The mechanism for finding a given submodule revision is outside the scope of this document.
「含める」ステートメントに「改訂」の表現がある場合、サブモジュールの対応する改訂を使用する必要があります。特定のサブモジュールリビジョンを見つけるメカニズムは、このドキュメントの範囲外です。
This statement is handled within 'rpc' statement, see Section 10.50.
このステートメントは、「RPC」ステートメント内で処理されます。セクション10.50を参照してください。
This statement is mapped to @nma:key attribute. ARGUMENT MUST be translated so that every key is prefixed with the namespace prefix of the local module. The result of this translation then becomes the value of the @nma:key attribute.
このステートメントは、@NMA：キー属性にマッピングされます。すべてのキーにローカルモジュールの名前空間プレフィックスが付いているように、引数を翻訳する必要があります。この翻訳の結果は、@NMA：キー属性の値になります。
This statement is mapped to the <rng:element> element and ARGUMENT with prepended local namespace prefix becomes the value of its @name attribute.
このステートメントは、<rng：element> element and引数にマッピングされます。
If the leaf is optional, i.e., if there is no "mandatory true;" substatement and the leaf is not declared among the keys of an enclosing list, then the <rng:element> element MUST be enclosed in <rng:optional>, except when the 'leaf' statement is a child of the 'choice' statement and thus represents a shorthand case for that choice (see Section 9.1.1 for details).
葉がオプションの場合、つまり「必須の真の」がない場合。置換と葉は、囲みのリストのキー間で宣言されていません。<rng：要素>要素は、「葉」ステートメントが「選択」ステートメントの子である場合を除き、<rng：optional>に囲む必要があります。したがって、その選択の速記のケースを表します（詳細については、セクション9.1.1を参照）。
This statement is mapped to a block enclosed by either the <rng: zeroOrMore> or the <rng:oneOrMore> element depending on whether the argument of 'min-elements' substatement is "0" or positive, respectively (it is zero by default). This <rng:zeroOrMore> or <rng: oneOrMore> element becomes the PARENT.
このステートメントは、<rng：zeroormore>または<rng：oneormore>要素のいずれかによって囲まれたブロックにマッピングされます。）。この<rng：zeroormore>または<rng：oneormore>要素が親になります。
<rng:element> is then added as a child element of PARENT and ARGUMENT with prepended local namespace prefix becomes the value of its @name attribute. Another attribute, @nma:leaf-list, MUST also be added to this <rng:element> element with the value of "true". If the 'leaf-list' statement has the 'min-elements' substatement and its argument is greater than one, additional attribute @nma:min-elements is attached to <rng:element> and the argument of 'min-elements' becomes the value of this attribute. Similarly, if there is the 'max-elements' substatement and its argument value is not "unbounded", attribute @nma:max-elements is attached to this element and the argument of 'max-elements' becomes the value of this attribute.
<rng：element>は、親の子要素として追加され、プリデンドローカルネームスペースのプレフィックスを使用して引数が@name属性の値になります。別の属性@NMA：Leaf-Listも、「true」の値を持つこの<rng：要素>要素に追加する必要があります。「葉のリスト」ステートメントに「最小要素」の代替があり、その引数が1より大きい場合、追加の属性@NMA：MIN-ELEMENTSが<RNG：要素>に添付され、「MIN-ELEMENTS」の引数はなります。この属性の値。同様に、「最大要素」の置換があり、その引数値が「バウンド」されていない場合、属性@NMA：MAX-ELEMENTSがこの要素に添付され、「MAX-ELEMENTS」の引数がこの属性の値になります。
EXAMPLE. Consider the following 'leaf-list' appearing in a module with the namespace prefix "yam":
例。名前空間プレフィックス「YAM」を備えたモジュールに表示される次の「リーフリスト」を考えてみましょう。
leaf-list foliage {
min-elements 3;
max-elements 6378;
ordered-by user;
type string;
}
It is mapped to the following RELAX NG fragment:
次のリラックスngフラグメントにマッピングされます。
<rng:oneOrMore>
<rng:element name="yam:foliage" nma:leaf-list="true"
nma:ordered-by="user"
nma:min-elements="3" nma:max-elements="6378">
<rng:data type="string"/>
</rng:element>
</rng:oneOrMore>
This statement is handled within the "string" type, see Section 10.53.10.
このステートメントは、「文字列」タイプ内で処理されます。セクション10.53.10を参照してください。
This statement is mapped exactly as the 'leaf-list' statement, see Section 10.28. The only difference is that the @nma:leaf-list annotation either MUST NOT be present or MUST have the value of "false".
このステートメントは、「リーフリスト」ステートメントとまったく同じようにマップされています。セクション10.28を参照してください。唯一の違いは、@NMA：Leaf-List Annotationが存在してはならないか、「false」の値を持たなければならないことです。
When mapping the substatements of 'list', the order of children of the list element MUST be specified so that list keys, if there are any, always appear in the same order as they are defined in the 'key' substatement and before other children, see [RFC6020], Section 7.8.5. In particular, if a list key is defined in a grouping but the list node itself is not a part of the same grouping, and the position of the 'uses' statement would violate the above ordering requirement, the grouping MUST be expanded, i.e., the 'uses' statement replaced by the grouping contents.
「リスト」の置換をマッピングする場合、リストキーがある場合は、「キー」の置換および他の子供の前に定義されているのと同じ順序で常に表示されるように、リスト要素の子供の順序を指定する必要があります、[RFC6020]、セクション7.8.5を参照してください。特に、リストキーがグループで定義されているが、リストノード自体が同じグループ化の一部ではなく、「使用」ステートメントの位置が上記の順序付け要件に違反する場合、グループ化は拡張する必要があります。「使用」ステートメントは、グループ化の内容に置き換えられました。
For example, consider the following YANG fragment of a module with
the prefix "yam":
grouping keygrp {
leaf clef {
type uint8;
}
}
list foo {
key clef;
leaf bar {
type string;
}
leaf baz {
type string;
}
uses keygrp;
}
It is mapped to the following RELAX NG fragment:
次のリラックスngフラグメントにマッピングされます。
<rng:zeroOrMore>
<rng:element name="yam:foo" nma:key="yam:clef">
<rng:element name="yam:clef">
<rng:data type="unsignedByte"/>
</rng:element>
<rng:interleave>
<rng:element name="yam:bar">
<rng:data type="string"/>
</rng:element>
<rng:element name="yam:baz">
<rng:data type="string"/>
</rng:element>
</rng:interleave>
</rng:element>
</rng:zeroOrMore>
Note that the "keygrp" grouping is expanded and the definition of "yam:clef" is moved before the <rng:interleave> pattern.
「keygrp」のグループ化が拡張され、「yam：clef」の定義が<rng：interleave>パターンの前に移動されることに注意してください。
This statement may appear as a substatement of 'leaf', 'choice', or 'anyxml' statement. If ARGUMENT is "true", the parent data node is mapped as mandatory, see Section 9.1.1.
このステートメントは、「葉」、「選択」、または「anyxml」ステートメントの代替として表示される場合があります。引数が「true」の場合、親データノードは必須としてマッピングされます。セクション9.1.1を参照してください。
As a substatement of 'choice', this statement is also mapped to the @nma:mandatory attribute, which is added to PARENT. The value of this attribute is the argument of the parent 'choice' statement.
「選択」の代替として、このステートメントは@NMA：必須属性にもマッピングされ、親に追加されます。この属性の値は、親の「選択」ステートメントの引数です。
This statement is handled within 'leaf-list' or 'list' statements, see Section 10.28.
このステートメントは、「リーフリスト」または「リスト」ステートメント内で処理されます。セクション10.28を参照してください。
This statement is handled within 'leaf-list' or 'list' statements, see Section 10.28.
このステートメントは、「リーフリスト」または「リスト」ステートメント内で処理されます。セクション10.28を参照してください。
This statement is mapped to an embedded <rng:grammar> pattern having the @nma:module attribute with the value of ARGUMENT. In addition, a <dc:source> element SHOULD be created as a child of this <rng: grammar> element and contain ARGUMENT as a metadata reference to the input YANG module. See also Section 10.49.
このステートメントは、引数の値を持つ@NMA：モジュール属性を持つ埋め込み<rng：grammar>パターンにマッピングされます。さらに、A <dc：source>要素は、この<rng：grammar>要素の子として作成し、入力Yangモジュールへのメタデータ参照として引数を含める必要があります。セクション10.49も参照してください。
Substatements of the 'module' statement MUST be mapped so that:
「モジュール」ステートメントの置換は、次のようにマッピングする必要があります。
o statements representing configuration/state data are mapped to descendants of the <nma:data> element;
o 構成/状態データを表すステートメントは、<nma：data> elementの子孫にマッピングされます。
o statements representing the contents of RPC requests or replies are mapped to descendants of the <nma:rpcs> element;
o RPC要求または返信の内容を表すステートメントは、<nma：rpcs>要素の子孫にマッピングされます。
o statements representing the contents of event notifications are mapped to descendants of the <nma:notifications> element.
o イベント通知の内容を表すステートメントは、<nma：通知>要素の子孫にマッピングされます。
This statement is mapped to the <nma:must> element. It has one mandatory attribute @assert (with no namespace) that contains ARGUMENT transformed into a valid XPath expression (see Section 9.3). The <nma:must> element may have other subelements resulting from mapping the 'error-app-tag' and 'error-message' substatements. Other substatements of 'must', i.e., 'description' and 'reference', are ignored.
このステートメントは、<nma：must>要素にマッピングされます。有効なXPath式に変換された引数を含む1つの必須属性@Assert（名前空間なし）があります（セクション9.3を参照）。<nma：must> elementには、「エラーアプリタグ」と「エラーメサージ」の置換をマッピングしたことから生じる他のサブエレメントがある場合があります。「必須」、つまり「説明」と「参照」の他の置換は無視されます。
EXAMPLE. YANG statement in the "dhcp" module
例。「DHCP」モジュールのYangステートメント
must 'current() <= ../max-lease-time' { error-message "The default-lease-time must be less than max-lease-time"; } is mapped to:
'current（）<= ../max-lease-time' {error-message "デフォルトリース時間は最大リース時間よりも短くする必要があります";}にマッピングされます：
<nma:must assert="current()<=../dhcp:max-lease-time">
<nma:error-message>
The default-lease-time must be less than max-lease-time
</nma:error-message>
</nma:must>
This statement is mapped simultaneously in two ways:
このステートメントは、2つの方法で同時にマップされています。
1. to the @xmlns:PREFIX attribute of the root <rng:grammar> element where PREFIX is the namespace prefix specified by the sibling 'prefix' statement. ARGUMENT becomes the value of this attribute;
1. @xmlnsへ：ルートのプレフィックス属性<rng：grammar>要素は、兄弟の「プレフィックス」ステートメントで指定された名前空間プレフィックスです。引数はこの属性の値になります。
2. to the @ns attribute of PARENT, which is an embedded <rng: grammar> pattern. ARGUMENT becomes the value of this attribute.
2. 埋め込み<rng：grammar>パターンである親の@NS属性に。引数はこの属性の値になります。
This statement is mapped to the following subtree of the <nma: notifications> element in the hybrid schema (where PREFIX is the prefix of the local YANG module):
このステートメントは、ハイブリッドスキーマの<nma：通知>要素の次のサブツリー（プレフィックスはローカルヤンモジュールのプレフィックス）にマッピングされます。
<nma:notification>
<rng:element name="PREFIX:ARGUMENT">
...
</rng:element>
</nma:notification>
Substatements of 'notification' are mapped under <rng:element name="PREFIX:ARGUMENT">.
「通知」の置換は、<rng：element name = "prefix：argument">の下にマッピングされます。
This statement is mapped to @nma:ordered-by attribute and ARGUMENT becomes the value of this attribute. See Section 10.28 for an example.
このステートメントは、@NMAにマッピングされます：並べ替えられた属性と引数がこの属性の値になります。例については、セクション10.28を参照してください。
This statement is ignored by the mapping because the hybrid schema may be mapped from multiple YANG modules authored by different parties. The hybrid schema SHOULD contain references to all input modules in the Dublin Core <dc:source> elements, see Section 10.34.
ハイブリッドスキーマは、さまざまな関係者によって作成された複数のYangモジュールからマッピングされる可能性があるため、このステートメントはマッピングによって無視されます。ハイブリッドスキーマには、ダブリンコア<DC：ソース>要素のすべての入力モジュールへの参照を含める必要があります。セクション10.34を参照してください。
The original YANG modules are the authoritative sources of the authorship information.
元のYangモジュールは、著者情報の権威あるソースです。
This statement is handled within the 'rpc' statement, see Section 10.50.
このステートメントは、「RPC」ステートメント内で処理されます。セクション10.50を参照してください。
This statement is handled within the "leafref" type, see Section 10.53.8.
このステートメントは、「leafref」タイプ内で処理されます。セクション10.53.8を参照してください。
This statement is handled within the "string" type, see Section 10.53.10.
このステートメントは、「文字列」タイプ内で処理されます。セクション10.53.10を参照してください。
This statement is ignored.
この声明は無視されます。
This statement is handled within the sibling 'namespace' statement, see Section 10.36, or within the parent 'import' statement, see Section 10.23. As a substatement of 'belongs-to' (in submodules), the 'prefix' statement is ignored.
このステートメントは、兄弟の「名前空間」ステートメント、セクション10.36を参照するか、親の「インポート」ステートメントを参照して、セクション10.23を参照して処理されます。「属する」（サブモジュール）の代替として、「プレフィックス」ステートメントは無視されます。
This statement influences the mapping of the parent container (Section 10.11): the parent container definition MUST be wrapped in <rng:optional>, regardless of its contents. See also Section 9.1.1.
このステートメントは、親コンテナのマッピングに影響します（セクション10.11）：親コンテナの定義は、その内容に関係なく、<rng：optional>にラップする必要があります。セクション9.1.1も参照してください。
This statement is handled within numeric types, see Section 10.53.9.
このステートメントは数値タイプ内で処理されます。セクション10.53.9を参照してください。
This statement is mapped to <a:documentation> element and its text is set to ARGUMENT prefixed with "See: ".
このステートメントは、<a：documentation>要素にマッピングされ、そのテキストは「see：」が付いた引数に設定されています。
This statement is handled within "instance-identifier" type (Section 10.53.7).
このステートメントは、「Instance-Identifier」タイプ（セクション10.53.7）内で処理されます。
The mapping uses only the most recent instance of the 'revision' statement, i.e., one with the latest date in ARGUMENT, which specifies the current revision of the input YANG module [RFC6020]. This date SHOULD be recorded, together with the name of the YANG module, in the corresponding Dublin Core <dc:source> element (see Section 10.34), for example in this form:
マッピングは、「改訂」ステートメントの最新のインスタンスのみ、つまり、入力Yangモジュール[RFC6020]の現在の改訂を指定する最新の引数の日付を使用します。この日付は、対応するダブリンコア<DC：ソース>要素（セクション10.34を参照）に、Yangモジュールの名前とともに記録する必要があります。
<dc:source>YANG module 'foo', revision 2010-03-02</dc:source>
The 'description' substatement of 'revision' is ignored.
「修正」の「説明」の代替は無視されます。
This statement is mapped to the following subtree in the RELAX NG schema (where PREFIX is the prefix of the local YANG module):
このステートメントは、Relax Ngスキーマの次のサブツリーにマッピングされています（プレフィックスはローカルヤンモジュールのプレフィックスです）：
<nma:rpc>
<nma:input>
<rng:element name="PREFIX:ARGUMENT">
... mapped contents of 'input' ...
</rng:element>
</nma:input>
<nma:output">
... mapped contents of 'output' ...
</nma:output>
</nma:rpc>
As indicated in the schema fragment, contents of the 'input' substatement (if any) are mapped under <rng:element name="PREFIX: ARGUMENT">. Similarly, contents of the 'output' substatement are mapped under <nma:output>. If there is no 'output' substatement, the <nma:output> element MUST NOT be present.
スキーマフラグメントに示されているように、「入力」置換の内容（存在する場合）は、<rng：element name = "prefix：argument">の下にマッピングされます。同様に、「出力」代替物の内容は、<nma：output>の下にマッピングされます。「出力」の置換がない場合、<nma：output>要素が存在しないでください。
The <nma:rpc> element is a child of <nma:rpcs>.
<nma：rpc>要素は、<nma：rpcs>の子です。
This statement MAY be ignored. Otherwise, it is mapped to @nma: status attribute and ARGUMENT becomes its value.
この声明は無視される場合があります。それ以外の場合、@NMA：ステータス属性と引数にマッピングされます。
This statement is not specifically mapped. Its substatements are mapped as if they appeared directly in the module to which the submodule belongs.
このステートメントは具体的にマッピングされていません。その置換は、サブモジュールが属するモジュールに直接表示されるかのようにマッピングされます。
Most YANG built-in data types have an equivalent in the XSD data type library [XSD-D] as shown in Table 4.
表4に示すように、ほとんどのYang組み込みのデータ型は、XSDデータ型ライブラリ[XSD-D]に相当します。
+-----------+---------------+--------------------------------+
| YANG type | XSD type | Meaning |
+-----------+---------------+--------------------------------+
| int8 | byte | 8-bit integer value |
| | | |
| int16 | short | 16-bit integer value |
| | | |
| int32 | int | 32-bit integer value |
| | | |
| int64 | long | 64-bit integer value |
| | | |
| uint8 | unsignedByte | 8-bit unsigned integer value |
| | | |
| uint16 | unsignedShort | 16-bit unsigned integer value |
| | | |
| uint32 | unsignedInt | 32-bit unsigned integer value |
| | | |
| uint64 | unsignedLong | 64-bit unsigned integer value |
| | | |
| string | string | character string |
| | | |
| binary | base64Binary | binary data in base64 encoding |
+-----------+---------------+--------------------------------+
Table 4: YANG built-in data types with equivalents in the W3C XML Schema Type Library
表4：W3C XMLスキーマタイプライブラリに同等のYang組み込みデータ型
Two important data types of the XSD data type library -- "dateTime" and "anyURI" -- are not built-in types in YANG but instead are defined as derived types in the standard modules [RFC6021]: "date-and-time" in the "ietf-yang-types" module and "uri" in the "ietf-inet-types" module. However, the formal restrictions in the YANG type definitions are rather weak. Therefore, implementations of the YANG-to-DSDL mapping SHOULD detect these derived types in source YANG modules and map them to "dateType" and "anyURI", respectively.
XSDデータ型ライブラリの2つの重要なデータタイプ（「DateTime」と「Anyuri」）は、Yangに組み込まれたタイプではなく、標準モジュール[RFC6021]の派生タイプとして定義されています。「IETF-YANG-TYPES」モジュールと「IETF-INETタイプ」モジュールの「URI」で。ただし、ヤンタイプの定義の正式な制限はかなり弱いです。したがって、Yang-to-DSDLマッピングの実装は、ソースYangモジュールでこれらの派生タイプを検出し、それぞれ「DateType」と「Anyuri」にマッピングする必要があります。
Details about the mapping of individual YANG built-in types are given in the following subsections.
個々のYang組み込みタイプのマッピングに関する詳細は、以下のサブセクションに記載されています。
This type is mapped to <rng:empty/>.
このタイプは、<rng：empty/>にマッピングされます。
This built-in type does not allow any restrictions and is mapped to the following XML fragment:
この組み込みタイプは制限を許可せず、次のXMLフラグメントにマッピングされます。
<rng:choice>
<rng:value>true</rng:value>
<rng:value>false</rng:value>
</rng:choice>
Note that the XSD "boolean" type cannot be used here because it allows, unlike YANG, an alternative numeric representation of boolean values: 0 for "false" and 1 for "true".
XSD「ブール」タイプは、Yangとは異なり、ブール値の代替数値表現を可能にするため、ここでは使用できないことに注意してください。
This built-in type does not allow any restrictions and is mapped simply by inserting an <rng:data> element whose @type attribute value is set to "base64Binary" (see also Table 4).
この組み込みタイプは制限を許可せず、@Type属性値が「base64binary」に設定されている<rng：data>要素を挿入するだけでマッピングされます（表4も参照）。
This type is mapped to the <rng:list> and for each 'bit' substatement the following XML fragment is inserted as a child of <rng:list>:
このタイプは<rng：list>にマッピングされ、各「ビット」の置換に対して、次のxmlフラグメントが<rng：list>の子として挿入されます。
<rng:optional>
<rng:value>bit_name</rng:value>
</rng:optional>
where bit_name is the name of the bit as found in the argument of a 'bit' substatement.
ここで、bit_nameは「ビット」の置換の引数にあるビットの名前です。
These types are mapped to the <rng:choice> element.
これらのタイプは、<rng：choice>要素にマッピングされます。
This type is mapped to the following named pattern reference:
このタイプは、次の名前のパターン参照にマッピングされます。
<rng:ref name="__PREFIX_BASE"/>
where PREFIX:BASE is the qualified name of the identity appearing in the argument of the 'base' substatement.
ここで、プレフィックス：ベースは、「ベース」の置換の引数に表示されるアイデンティティの適格な名前です。
For example, assume that module "des" in Section 10.21 contains the following leaf definition:
たとえば、セクション10.21のモジュール「DES」には、次の葉の定義が含まれていると仮定します。
leaf foo {
type identityref {
base crypto:crypto-alg;
}
}
This leaf would then be mapped to the following element pattern:
この葉は、次の要素パターンにマッピングされます。
<element name="des:foo">
<ref name="__crypto_crypto-alg"/>
</element>
This type is mapped to <rng:data> element with @type attribute set to "string". In addition, an empty <nma:instance-identifier> element MUST be inserted as a child of PARENT.
このタイプは、@Type属性を「string」に設定した<rng：data>要素にマッピングされます。さらに、空の<nma：instance-identifier>要素を親の子として挿入する必要があります。
The argument of the 'require-instance' substatement, if it exists, becomes the value of the @require-instance attribute of the <nma: instance-identifier> element.
「要求」の代替の引数は、それが存在する場合、<nma：instance-identifier>要素の @reasure-instance属性の値になります。
This type is mapped exactly as the type of the leaf given in the argument of 'path' substatement. However, if the type of the referred leaf defines a default value, this default value MUST be ignored by the mapping.
このタイプは、「パス」の置換の引数で与えられた葉のタイプとまったく同じようにマッピングされます。ただし、参照された葉のタイプがデフォルト値を定義する場合、このデフォルト値はマッピングによって無視する必要があります。
In addition, @nma:leafref attribute MUST be added to PARENT. The argument of the 'path' substatement, translated according to Section 9.3, is set as the value of this attribute.
さらに、@NMA：Leafref属性を親に追加する必要があります。セクション9.3に従って翻訳された「パス」の置換の引数は、この属性の値として設定されています。
YANG built-in numeric types are "int8", "int16", "int32", "int64", "uint8", "uint16", "uint32", "uint64", and "decimal64". They are mapped to the <rng:data> element with the @type attribute set to ARGUMENT translated according to Table 4 above.
Yang内蔵数値タイプは、「Int8」、「Int16」、「Int32」、「Int64」、「UINT8」、「UINT16」、「UINT32」、「UINT64」、および「Decimal64」です。上記の表4に従って翻訳された引数に設定された@Type属性を使用して、<rng：data>要素にマッピングされます。
An exception is the "decimal64" type, which is mapped to the "decimal" type of the XSD data type library. Its precision and number of fractional digits are controlled with the following facets, which MUST always be present: o "totalDigits" facet set to the value of 19.
例外は、XSDデータ型ライブラリの「小数」タイプにマッピングされる「Decimal64」タイプです。その精度と分数桁の数は、次のファセットで制御されます。これは常に存在する必要があります。o "TotalDigits"ファセットは、19の値に設定されています。
o "fractionDigits" facet set to the argument of the 'fraction-digits' substatement.
o 「FractionDigits」ファセットは、「分数桁」の代替の議論に設定されています。
The fixed value of "totalDigits" corresponds to the maximum of 19 decimal digits for 64-bit integers.
「TotalDigits」の固定値は、64ビット整数の最大19桁の数字に対応します。
For example, the statement:
たとえば、声明：
type decimal64 {
fraction-digits 2;
}
is mapped to the following RELAX NG data type:
次のリラックスデータ型にマッピングされます。
<rng:data type="decimal">
<rng:param name="totalDigits">19</rng:param>
<rng:param name="fractionDigits">2</rng:param>
</rng:data>
All numeric types support the 'range' restriction, which is mapped as follows:
すべての数値タイプは、「範囲」制限をサポートしています。これは次のようにマッピングされます。
If the range expression consists of just a single range LO..HI, then it is mapped to a pair of data type facets:
範囲式が単一の範囲LO..hiで構成されている場合、それはデータ型ファセットのペアにマッピングされます。
<rng:param name="minInclusive">LO</rng:param>
and
と
<rng:param name="maxInclusive">HI</rng:param>
If the range consists of a single number, the values of both facets are set to this value. If LO is equal to the string "min", the "minInclusive" facet is omitted. If HI is equal to the string "max", the "maxInclusive" facet is omitted.
範囲が単一の数値で構成されている場合、両方のファセットの値がこの値に設定されます。LOが文字列「MIN」に等しい場合、「ミニンクスル」ファセットは省略されています。HIが文字列「Max」に等しい場合、「MaxInclusive」ファセットは省略されています。
If the range expression has multiple parts separated by "|", then the parent <rng:data> element must be repeated once for every range part and all such <rng:data> elements are wrapped in <rng:choice> element. Each <rng:data> element contains the "minInclusive" and "maxInclusive" facets for one part of the range expression as described in the previous paragraph.
範囲式に「|」で区切られている複数の部分がある場合、親<rng：data>要素はすべての範囲部分に対して1回繰り返す必要があります。各<rng：data>要素には、前の段落に記載されている範囲式の一部の「ミニンクスル」および「最大融合」ファセットが含まれています。
For the "decimal64" type, the "totalDigits" and "fractionDigits" must be repeated inside each of the <rng:data> elements.
「decimal64」タイプの場合、<rng：data>要素のそれぞれ内で「totaldigits」と「fractiondigits」を繰り返す必要があります。
For example,
例えば、
type int32 {
range "-6378..0|42|100..max";
}
is mapped to the following RELAX NG fragment:
次のリラックスngフラグメントにマッピングされます。
<rng:choice>
<rng:data type="int">
<rng:param name="minInclusive">-6378</rng:param>
<rng:param name="maxInclusive">0</rng:param>
</rng:data>
<rng:data type="int">
<rng:param name="minInclusive">42</rng:param>
<rng:param name="maxInclusive">42</rng:param>
</rng:data>
<rng:data type="int">
<rng:param name="minInclusive">100</rng:param>
</rng:data>
</rng:choice>
See Section 9.2.2 for further details on mapping the restrictions.
制限のマッピングの詳細については、セクション9.2.2を参照してください。
This type is mapped to the <rng:data> element with the @type attribute set to "string".
このタイプは、@Type属性が「文字列」に設定された<rng：data>要素にマッピングされます。
The 'length' restriction is handled analogically to the 'range' restriction for the numeric types (Section 10.53.9):
「長さ」の制限は、数値タイプの「範囲」制限に類似して処理されます（セクション10.53.9）：
If the length expression has just a single range:
長さの式に単一の範囲がある場合：
o and if the length range consists of a single number LENGTH, the following data type facet is inserted:
o 長さの範囲が単一の数の長さで構成されている場合、次のデータ型ファセットが挿入されます。
<rng:param name="length">LENGTH</rng:param>.
<rng：param name = "length"> length </rng：param>。
o if the length range is of the form LO..HI, i.e., it consists of both the lower and upper bound. The following two data type facets are then inserted:
o 長さの範囲がlo..hiの形式である場合、つまり、下部と上限の両方で構成されています。次の2つのデータ型ファセットが挿入されます。
<rng:param name="minLength">LO</rng:param>
and
と
<rng:param name="maxLength">HI</rng:param>
If LO is equal to the string "min", the "minLength" facet is omitted. If HI is equal to the string "max", the "maxLength" facet is omitted.
LOが文字列「min」に等しい場合、「minlength」ファセットは省略されています。HIが文字列「Max」に等しい場合、「MaxLength」ファセットは省略されています。
If the length expression has of multiple parts separated by "|", then the parent <rng:data> element must be repeated once for every range part and all such <rng:data> elements are wrapped in <rng:choice> element. Each <rng:data> element contains the "length" or "minLength" and "maxLength" facets for one part of the length expression as described in the previous paragraph.
長さの式に「|」で区切られた複数の部分がある場合、親<rng：data>要素はすべての範囲パーツで1回繰り返す必要があり、そのようなすべての<rng：data>要素は<rng：choice>要素に巻き付けられます。各<rng：data>要素には、前の段落で説明されている長さ式の一部の「長さ」または「minlength」および「maxlength」ファセットが含まれます。
Every 'pattern' restriction of the "string" data type is mapped to the "pattern" facet:
「文字列」データ型のすべての「パターン」制限は、「パターン」ファセットにマッピングされます。
<rng:param name="pattern">...</rng:param>
with text equal to the argument of the 'pattern' statement. All such "pattern" facets must be repeated inside each copy of the <rng:data> element, i.e., once for each length range.
「パターン」ステートメントの引数に等しいテキスト。そのようなすべての「パターン」ファセットは、<rng：data>要素の各コピー、つまり各長さの範囲で1回繰り返す必要があります。
For example,
例えば、
type string {
length "1|3..8";
pattern "[A-Z][a-z]*";
}
is mapped to the following RELAX NG fragment:
次のリラックスngフラグメントにマッピングされます。
<rng:choice>
<rng:data type="string">
<rng:param name="length">1</rng:param>
<rng:param name="pattern">[A-Z][a-z]*</rng:param>
</rng:data>
<rng:data type="string">
<rng:param name="minLength">3</rng:param>
<rng:param name="maxLength">8</rng:param>
<rng:param name="pattern">[A-Z][a-z]*</rng:param>
</rng:data>
</rng:choice>
If the 'type' statement refers to a derived type, it is mapped in one of the following ways depending on whether it contains any restrictions as its substatements: 1. Without restrictions, the 'type' statement is mapped simply to the <rng:ref> element, i.e., a reference to a named pattern. If the RELAX NG definition of this named pattern has not been added to the hybrid schema yet, the corresponding type definition MUST be found and its mapping installed as a subelement of either the root or an embedded <rng:grammar> element, see Section 10.54. Even if a given derived type is used more than once in the input YANG modules, the mapping of the corresponding 'typedef' MUST be installed only once.
「タイプ」ステートメントが派生タイプを指している場合、それは次の方法のいずれかに応じてマッピングされます。REF>要素、つまり、名前付きパターンへの参照。この名前付きパターンのリラックスNG定義がまだハイブリッドスキーマに追加されていない場合、対応するタイプ定義が見つかり、そのマッピングはルートまたは埋め込み<rng：grammar>要素のサブエレメントとしてインストールする必要があります。セクション10.54を参照してください。。入力Yangモジュールで特定の派生型が複数回使用されている場合でも、対応する「typedef」のマッピングは1回だけインストールする必要があります。
2. If any restrictions are present, the ancestor built-in type for the given derived type must be determined and the mapping of this base type MUST be used. Restrictions appearing at all stages of the type derivation chain MUST be taken into account and their conjunction added to the <rng:data> element that defines the basic type.
2. 制限がある場合は、指定された派生型の祖先組み込み型を決定する必要があり、このベースタイプのマッピングを使用する必要があります。タイプ派生チェーンのすべての段階で表示される制限を考慮し、それらの接続が基本タイプを定義する<rng：data>要素に追加する必要があります。
See Section 9.2.2 for more details and an example.
詳細と例については、セクション9.2.2を参照してください。
This statement is mapped to a RELAX NG named pattern definition <rng: define>, but only if the type defined by this statement is used without restrictions in at least one of the input modules. In this case, the named pattern definition becomes a child of either the root or an embedded <rng:grammar> element, depending on whether or not the 'typedef' statement appears at the top level of a YANG module. The name of this named pattern definition is set to ARGUMENT mangled according to the rules specified in Section 9.2.
このステートメントは、パターン定義<rng：define>という名前のリラックスngにマッピングされますが、このステートメントで定義されたタイプが入力モジュールの少なくとも1つで制限なしに使用されている場合のみです。この場合、指定されたパターン定義は、「typedef」ステートメントがヤンモジュールの上位レベルに表示されるかどうかに応じて、ルートまたは埋め込み<rng：grammar>要素の子になります。この名前付きパターン定義の名前は、セクション9.2で指定されたルールに従ってマングルされた引数に設定されています。
Whenever a derived type is used with additional restrictions, the ancestor built-in type for the derived type is used instead with restrictions (facets) that are a combination of all restrictions specified along the type derivation chain. See Section 10.53.11 for further details and an example.
派生タイプが追加の制限で使用される場合はいつでも、派生タイプの祖先ビルトインタイプは、型導入チェーンに沿って指定されたすべての制限の組み合わせである制限（ファセット）で代わりに使用されます。詳細と例については、セクション10.53.11を参照してください。
An implementation MAY offer the option of recording all 'typedef' statements as named patterns in the output RELAX NG schema even if they are not referenced. This is useful for mapping YANG "library" modules containing only 'typedef' and/or 'grouping' statements.
実装は、たとえ参照されていなくても、出力リラックスNGスキーマの名前が付けられたパターンとしてすべての「typedef」ステートメントを記録するオプションを提供する場合があります。これは、「typedef」および/または「グループ化」ステートメントのみを含むYangの「ライブラリ」モジュールをマッピングするのに役立ちます。
This statement is mapped to the @nma:unique attribute. ARGUMENT MUST be translated so that every node identifier in each of its components is prefixed with the namespace prefix of the local module, unless the prefix is already present. The result of this translation then becomes the value of the @nma:unique attribute.
このステートメントは、@NMA：一意の属性にマッピングされます。各コンポーネントのすべてのノード識別子に、プレフィックスが既に存在しない限り、ローカルモジュールの名前空間プレフィックスが付いているように引数を翻訳する必要があります。この翻訳の結果は、@NMA：一意の属性の値になります。
For example, assuming that the local module prefix is "ex",
たとえば、ローカルモジュールのプレフィックスが「EX」であると仮定すると、
unique "foo ex:bar/baz"
ユニークな「foo ex：bar/baz」
is mapped to the following attribute/value pair:
次の属性/値ペアにマッピングされます。
nma:unique="ex:foo ex:bar/ex:baz"
This statement is mapped to the @nma:units attribute and ARGUMENT becomes its value.
このステートメントは、@NMA：UNITS属性と引数にマッピングされます。
If this statement has neither 'refine' nor 'augment' substatements, it is mapped to the <rng:ref> element, i.e., a reference to a named pattern, and the value of its @name attribute is set to ARGUMENT mangled according to Section 9.2. If the RELAX NG definition of the referenced named pattern has not been added to the hybrid schema yet, the corresponding grouping MUST be found and its mapping installed as a subelement of <rng:grammar>, see Section 10.20.
このステートメントに「洗練」も「拡張」の置換がない場合、<rng：ref>要素、つまり指定されたパターンへの参照にマッピングされ、@name属性の値は、に従ってマングルされた引数に設定されます。セクション9.2。参照された名前のパターンのリラックスNG定義がまだハイブリッドスキーマに追加されていない場合、対応するグループ化が見つかり、そのマッピングは<rng：grammar>のサブエレメントとしてインストールされなければなりません。セクション10.20を参照してください。
Otherwise, if the 'uses' statement has any 'refine' or 'augment' substatements, the corresponding grouping must be looked up and its contents inserted under PARENT. See Section 9.2.1 for further details and an example.
それ以外の場合、「使用」ステートメントに「洗練」または「拡張」の置換がある場合、対応するグループ化を調べて、その内容を親の下に挿入する必要があります。詳細と例については、セクション9.2.1を参照してください。
This statement is ignored.
この声明は無視されます。
This statement is mapped to the @nma:when attribute and ARGUMENT, translated according to Section 9.3, becomes it value.
このステートメントは、@NMAにマッピングされます。属性と引数がセクション9.3に従って翻訳されると、値が値になります。
This statement is not mapped to the output schema. However, an implementation SHOULD check that it is compatible with the YANG version declared by the statement (currently version 1). In the case of a mismatch, the implementation SHOULD report an error and terminate.
このステートメントは、出力スキーマにマッピングされていません。ただし、実装では、ステートメント（現在はバージョン1）で宣言されたヤンバージョンと互換性があることを確認する必要があります。不一致の場合、実装はエラーを報告して終了する必要があります。
This statement is not mapped to the output schema, but see the rules for extension handling in Section 9.4.
このステートメントは出力スキーマにマッピングされていませんが、セクション9.4の拡張処理のルールを参照してください。
As explained in Section 6, the second step of the YANG-to-DSDL mapping takes the hybrid schema and transforms it to various DSDL schemas capable of validating instance XML documents. As an input parameter, this step takes, in the simplest case, just a specification of the NETCONF XML document type that is to be validated. These document types can be, for example, the contents of a datastore, a reply to <nc:get> or <nc:get-config>, contents of other RPC requests/replies and event notifications, and so on.
セクション6で説明したように、Yang-to-DSDLマッピングの2番目のステップでは、ハイブリッドスキーマを取り、インスタンスXMLドキュメントを検証できるさまざまなDSDLスキーマに変換します。入力パラメーターとして、このステップは、最も単純な場合、検証されるNetConf XMLドキュメントタイプの指定のみを実行します。これらのドキュメントタイプは、たとえば、データストアの内容、<nc：get>または<nc：get-config>への返信、他のRPCリクエスト/返信、イベント通知などへの返信などです。
The second mapping step has to accomplish the following three general tasks:
2番目のマッピングステップでは、次の3つの一般的なタスクを達成する必要があります。
1. Extract the parts of the hybrid schema that are appropriate for the requested document type. For example, if a <nc:get> reply is to be validated, the subtree under <nma:data> has to be selected.
1. 要求されたドキュメントタイプに適したハイブリッドスキーマの部分を抽出します。たとえば、a <nc：get>返信が検証される場合、<nma：data>の下のサブツリーを選択する必要があります。
2. The schema must be adapted to the specific encapsulating XML elements mandated by the RPC layer. These are, for example, <nc: rpc> and <nc:data> elements in the case of a <nc:get> reply or <en:notification> for a notification.
2. スキーマは、RPCレイヤーによって義務付けられている特定のカプセル化XML要素に適応する必要があります。これらは、たとえば、<nc：rpc>および<nc：data> a <nc：get> neplyまたは<en：通知>の場合の要素です。
3. Finally, NETMOD-specific annotations that are relevant for the schema language of the generated schema must be mapped to the corresponding patterns or rules.
3. 最後に、生成されたスキーマのスキーマ言語に関連するNetMod固有の注釈は、対応するパターンまたはルールにマッピングする必要があります。
These three tasks are together much simpler than the first mapping step and can be effectively implemented using XSL transformations [XSLT].
これらの3つのタスクは、最初のマッピングステップよりもはるかにシンプルで、XSL変換[XSLT]を使用して効果的に実装できます。
The following subsections describe the details of the second mapping step for the individual DSDL schema languages. Section 12 then contains a detailed specification for the mapping of all NETMOD-specific annotations.
次のサブセクションでは、個々のDSDLスキーマ言語の2番目のマッピングステップの詳細について説明します。セクション12には、すべてのNetMod固有の注釈のマッピングに関する詳細な仕様が含まれています。
With one minor exception, obtaining a validating RELAX NG schema from the hybrid schema only means taking appropriate parts of the hybrid schema and assembling them in a new RELAX NG grammar, perhaps after removing all unwanted annotations.
1つのマイナーな例外を除いて、ハイブリッドスキーマから検証済みのリラックスNGスキーマを取得することは、ハイブリッドスキーマの適切な部分を取得し、おそらくすべての不要な注釈を削除した後、新しいリラックスNG文法で組み立てることを意味します。
The structure of the resulting RELAX NG schema is similar to that of the hybrid schema: the root grammar contains embedded grammars, one for each input YANG module. However, as explained in Section 8.2, global named pattern definitions (children of the root <rng:grammar> element) MUST be moved to a separate schema file.
結果として得られるリラックスNGスキーマの構造は、ハイブリッドスキーマの構造に似ています。ルート文法には、入力ヤンモジュールごとに1つの埋め込み文法が含まれています。ただし、セクション8.2で説明したように、グローバル指定パターン定義（root <rng：grammar> element）を別のスキーマファイルに移動する必要があります。
Depending on the XML document type that is the target for validation, such as <nc:get> or <nc:get-config> reply, RPC operations or notifications, patterns defining corresponding top-level information items MUST be added, such as <nc:rpc-reply> with the @message-id attribute and so on.
<nc：get>または<nc：get-config>返信、RPC操作、または通知など、検証のターゲットであるXMLドキュメントタイプに応じて、対応するトップレベルの情報項目を定義するパターンを追加する必要があります。NC：rpc-reply> @message-id属性など。
In order to avoid copying common named pattern definitions for common NETCONF elements and attributes to every single output RELAX NG file, such schema-independent definitions SHOULD be collected in a library file that is then included by the validating RELAX NG schemas. Appendix B has the listing of such a library file.
一般的なNetConf要素の一般的な名前のパターン定義をコピーしないようにするには、すべての出力リラックスNGファイルの一般的なNetConf要素と属性の属性をコピーするために、このようなスキーマに依存しない定義をライブラリファイルに収集する必要があります。付録Bには、このようなライブラリファイルのリストがあります。
The minor exception mentioned above is the annotation @nma:config, which must be observed if the target document type is a reply to <nc: get-config>. In this case, each element definition that has this attribute with the value of "false" MUST be removed from the schema together with its descendants. See Section 12.1 for more details.
上記のマイナーな例外はAnnotation @NMA：configです。ターゲットドキュメントタイプが<nc：get-config>への返信である場合に観察する必要があります。この場合、「false」の値を持つこの属性を持つ各要素定義は、その子孫と一緒にスキーマから削除する必要があります。詳細については、セクション12.1を参照してください。
Schematron schemas tend to be much flatter and more uniform compared to RELAX NG. They have exactly four levels of XML hierarchy: <sch: schema>, <sch:pattern>, <sch:rule>, and <sch:assert> or <sch:report>.
スキーマトロンスキーマは、NGのリラックスと比較して、はるかに平らで均一になる傾向があります。XML階層には正確に4つのレベルがあります：<sch：schema>、<sch：pattern>、<sch：rule>、<sch：assert>または<sch：sch：sch：report>。
In a Schematron schema generated by the second mapping step, the basic unit of organization is a rule represented by the <sch:rule> element. The following NETMOD-specific annotations from the hybrid schema (henceforth called "semantic annotations") are mapped to corresponding Schematron rules: <nma:must>, @nma:key, @nma:unique, @nma:max-elements, @nma:min-elements, @nma:when, @nma:leafref, @nma: leaf-list, and also @nma:mandatory appearing as an attribute of <rng: choice> (see Section 11.2.1).
2番目のマッピングステップによって生成されたスキーマトロンスキーマでは、組織の基本単位は<sch：ルール>要素で表されるルールです。ハイブリッドスキーマからの次のNetMod固有の注釈（以下「セマンティックアノテーション」と呼ばれる）は、対応するスキーマトロンルールにマッピングされています：<nma：bust>、@nma：key、@nma：unique、@nma：max-elements、@nma：min-elements、@nma：@nma：leafref、@nma：leaflist、および@nma：<rng：choice>の属性として表示される必須>（セクション11.2.1を参照）。
Each input YANG module is mapped to a Schematron pattern whose @id attribute is set to the module name. Every <rng:element> pattern containing at least one of the above-mentioned semantic annotations is then mapped to a Schematron rule:
各入力Yangモジュールは、@ID属性がモジュール名に設定されているスキーマトロンパターンにマッピングされます。上記のセマンティックアノテーションの少なくとも1つを含むすべての<rng：要素>パターンは、スキーマトロンルールにマッピングされます。
<sch:rule context="XELEM"> ... </sch:rule> The value of the mandatory @context attribute of <sch:rule> (denoted as XELEM) MUST be set to the absolute path of the context element in the data tree. The <sch:rule> element contains the mappings of all contained semantic annotations in the form of Schematron asserts or reports.
<sch：rule context = "xelem"> ... </sh：ルール>必須の@context属性の値<sch：rulem>（xelemとして示される）は、コンテキスト要素の絶対パスに設定する必要があります。データツリー。<sch：rule>要素には、Schematronの主張またはレポートの形式で含まれるすべての意味注釈のマッピングが含まれています。
Semantic annotations appearing inside a named pattern definition (i.e., having <rng:define> among its ancestors) require special treatment because they may be potentially used in different contexts. This is accomplished by using Schematron abstract patterns that use the "$pref" variable in place of the local namespace prefix. The value of the @id attribute of such an abstract pattern MUST be set to the name of the named pattern definition that is being mapped (i.e., the mangled name of the original YANG grouping).
名前付きパターン定義内に表示されるセマンティックアノテーション（つまり、先祖の間で<rng：define>を持つこと）は、異なるコンテキストで潜在的に使用される可能性があるため、特別な治療が必要です。これは、ローカルネームスペースプレフィックスの代わりに「$ pref」変数を使用するSchematron抽象パターンを使用することによって達成されます。このような抽象パターンの@ID属性の値は、マッピングされている名前のパターン定義の名前に設定する必要があります（つまり、元のヤングループのマングルされた名前）。
When the abstract pattern is instantiated, the values of the following two parameters MUST be provided:
抽象パターンがインスタンス化される場合、次の2つのパラメーターの値を提供する必要があります。
o pref: the actual namespace prefix,
o PRET：実際の名前空間プレフィックス、
o start: XPath expression defining the context in which the grouping is used.
o 開始：XPath式グループが使用されるコンテキストを定義します。
EXAMPLE. Consider the following YANG module:
例。次のYangモジュールを検討してください。
module example4 {
namespace "http://example.com/ns/example4";
prefix ex4;
uses sorted-leaf-list;
grouping sorted-leaf-list {
leaf-list sorted-entry {
must "not(preceding-sibling::sorted-entry > .)" {
error-message "Entries must appear in ascending order.";
}
type uint8;
}
}
}
The resulting Schematron schema for a reply to <nc:get> is then as
follows:
<?xml version="1.0" encoding="utf-8"?>
<sch:schema xmlns:sch="http://purl.oclc.org/dsdl/schematron">
<sch:ns uri="http://example.com/ns/example4" prefix="ex4"/>
<sch:ns uri="urn:ietf:params:xml:ns:netconf:base:1.0"
prefix="nc"/>
<sch:pattern abstract="true"
id="_example4__sorted-leaf-list">
<sch:rule context="$start/$pref:sorted-entry">
<sch:report
test=". = preceding-sibling::$pref:sorted-entry">
Duplicate leaf-list entry "<sch:value-of select="."/>".
</sch:report>
<sch:assert
test="not(preceding-sibling::$pref:sorted-entry > .)">
Entries must appear in ascending order.
</sch:assert>
</sch:rule>
</sch:pattern>
<sch:pattern id="example4"/>
<sch:pattern id="id2573371" is-a="_example4__sorted-leaf-list">
<sch:param name="start" value="/nc:rpc-reply/nc:data"/>
<sch:param name="pref" value="ex4"/>
</sch:pattern>
</sch:schema>
The "sorted-leaf-list" grouping from the input module is mapped to an abstract pattern with an @id value of "_example4__sorted-leaf-list" in which the 'must' statement corresponds to the <sch:assert> element. The abstract pattern is the instantiated by the pattern with an @id value of "id2573371", which sets the "start" and "pref" parameters to appropriate values.
入力モジュールからの「並べ替えられたリーフリスト」のグループ化は、「_example4__sorted-leaf-list」の@id値を持つ抽象パターンにマッピングされます。抽象パターンは、「ID2573371」の@ID値を持つパターンによってインスタンス化されており、適切な値に「start」と「pref」パラメーターを設定します。
Note that another Schematron element, <sch:report>, was automatically added, checking for duplicate leaf-list entries.
別のスキーマトロン要素<sch：sch：report>が自動的に追加され、葉の上リストの重複エントリをチェックすることに注意してください。
The mapping from the hybrid schema to Schematron proceeds in the following steps:
ハイブリッドスキーマからスキーマトロンへのマッピングは、次の手順で進行します。
1. First, the active subtree(s) of the hybrid schema must be selected depending on the requested target document type. This procedure is identical to the RELAX NG case, including the handling of @nma:config if the target document type is <nc:get-config> reply.
1. まず、ハイブリッドスキーマのアクティブなサブツリーを選択する必要があります。この手順は、 @nma：configの処理を含むリラックスNGケースと同じです。
2. Namespaces of all input YANG modules, together with the namespaces of base NETCONF ("nc" prefix) or notifications ("en" prefix) MUST be declared using the <sch:ns> element, for example:
2. すべての入力Yangモジュールの名前空間と、ベースネットコン（ "NC"プレフィックス）または通知（ "en"プレフィックス）の名前空間とともに、<sch：ns>要素を使用して宣言する必要があります。
<sch:ns uri="http://example.com/ns/example4" prefix="ex4"/>
3. One pattern is created for every input module. In addition, an abstract pattern is created for every named pattern definition containing one or more semantic annotations.
3. 入力モジュールごとに1つのパターンが作成されます。さらに、1つ以上のセマンティック注釈を含むすべての名前のパターン定義に対して抽象パターンが作成されます。
4. A <sch:rule> element is created for each element pattern containing semantic annotations.
4. a <sch：ルール>要素は、セマンティックアノテーションを含む各要素パターンに対して作成されます。
5. Every such annotation is then mapped to an <sch:assert> or <sch: report> element, which is installed as a child of the <sch:rule> element.
5. そのような注釈はすべて、<sch：assert>または<sch：report>要素にマッピングされます。
In order to fully represent the semantics of YANG's 'choice' statement with the "mandatory true;" substatement, the RELAX NG grammar has to be combined with a special Schematron rule.
ヤンの「選択」声明のセマンティクスを「必須のtrue」と完全に表すため。置換、リラックスNG文法は、特別なスキーマトロンルールと組み合わせる必要があります。
EXAMPLE. Consider the following module:
例。次のモジュールを検討してください。
module example5 {
namespace "http://example.com/ns/example5";
prefix ex5;
choice foobar {
mandatory true;
case foo {
leaf foo1 {
type uint8;
}
leaf foo2 {
type uint8;
}
}
leaf bar {
type uint8;
}
}
}
In this module, all three leaf nodes in both case branches are
optional but because of the "mandatory true;" statement, at least one
of them must be present in a valid configuration. The 'choice'
statement from this module is mapped to the following fragment of the
RELAX NG schema:
<rng:choice>
<rng:interleave>
<rng:optional>
<rng:element name="ex5:foo1">
<rng:data type="unsignedByte"/>
</rng:element>
</rng:optional>
<rng:optional>
<rng:element name="ex5:foo2">
<rng:data type="unsignedByte"/>
</rng:element>
</rng:optional>
</rng:interleave>
<rng:element name="ex5:bar">
<rng:data type="unsignedByte"/>
</rng:element>
</rng:choice>
In the second case branch, the "ex5:bar" element is defined as mandatory so that this element must be present in a valid configuration if this branch is selected. However, the two elements in the first branch "foo" cannot be both declared as mandatory since each of them alone suffices for a valid configuration. As a result, the above RELAX NG fragment would successfully validate configurations where none of the three leaf elements are present.
2番目のケースブランチでは、「ex5：bar」要素は必須として定義されているため、この分岐が選択されている場合は、この要素が有効な構成に存在する必要があります。ただし、最初のブランチ「foo」の2つの要素は、それぞれが有効な構成に十分であるため、両方とも必須として宣言することはできません。その結果、上記のリラックスNGフラグメントは、3つの葉要素が存在しない構成を正常に検証します。
Therefore, mandatory choices, which can be recognized in the hybrid schema as <rng:choice> elements with the @nma:mandatory annotation, have to be handled in a special way: for each mandatory choice where at least one of the cases contains more than one node, a Schematron rule MUST be added enforcing the presence of at least one element from any of the cases. (RELAX NG schema guarantees that elements from different cases cannot be mixed together, that all mandatory nodes are present, etc.).
したがって、ハイブリッドスキーマで<rng：choice> @nmaの要素として認識できる必須の選択肢は、特別な方法で処理する必要があります。1つのノードよりも、いずれかのケースから少なくとも1つの要素の存在を実施するスキマトロンルールを追加する必要があります。（リラックスNGスキーマは、異なるケースの要素を混合できないこと、すべての必須ノードが存在するなどを保証します）。
For the example module above, the Schematron rule will be as follows:
上記のモジュールの例では、スキーマトロンルールは次のとおりです。
<sch:rule context="/nc:rpc-reply/nc:data">
<sch:assert test="ex5:foo1 or ex5:foo2 or ex5:bar">
Node(s) from at least one case of choice "foobar" must exist.
</sch:assert>
</sch:rule>
DSRL is the only component of DSDL that is allowed to change the information set of the validated XML document. While DSRL also has other functions, YANG-to-DSDL mapping uses it only for specifying and applying default contents. For XML instance documents based on YANG data models, insertion of default contents may potentially take place for all implicit nodes identified by the rules in Section 9.1.2.
DSRLは、検証済みのXMLドキュメントの情報セットを変更できるDSDLの唯一のコンポーネントです。DSRLには他の機能もありますが、Yang-to-DSDLマッピングでは、デフォルトのコンテンツを指定および適用するためにのみ使用します。Yangデータモデルに基づくXMLインスタンスドキュメントの場合、セクション9.1.2のルールで識別されるすべての暗黙的なノードに対して、デフォルトの内容の挿入が潜在的に行われる場合があります。
In DSRL, the default contents of an element are specified using the <dsrl:default-content> element, which is a child of <dsrl:element-map>. Two sibling elements of <dsrl:default-content> determine the context for the application of the default contents, see [DSRL]:
DSRLでは、要素のデフォルトの内容は、<DSRL：Default-Content>要素を使用して指定されます。<dsrl：default-content>の2つの兄弟要素>デフォルトコンテンツの適用のコンテキストを決定します。[dsrl]を参照してください。
o the <dsrl:parent> element contains an XSLT pattern specifying the parent element; the default contents are applied only if the parent element exists in the instance document;
o <dsrl：parent>要素には、親要素を指定するXSLTパターンが含まれています。デフォルトの内容は、Instanceドキュメントに親要素が存在する場合にのみ適用されます。
o the <dsrl:name> contains the XML name of the element that, if missing or empty, is inserted together with the contents of <dsrl: default-content>.
o <dsrl：name>は、欠落または空の場合、<dsrl：default-content>の内容とともに挿入される要素のxml名が含まれています。
The <dsrl:parent> element is optional in a general DSRL schema but, for the purpose of the YANG-to-DSDL mapping, this element MUST be always present, in order to guarantee a proper application of default contents.
<dsrl：parent>要素は一般的なDSRLスキーマではオプションですが、Yang-to-DSDLマッピングの目的のために、デフォルトのコンテンツの適切な適用を保証するために、この要素は常に存在する必要があります。
DSRL mapping only deals with <rng:element> patterns in the hybrid schema that define implicit nodes (see Section 9.1.2). Such element patterns are distinguished by having NETMOD-specific annotation attributes @nma:default or @nma:implicit, i.e., either:
DSRLマッピングは、暗黙的なノードを定義するハイブリッドスキーマの<rng：element>パターンのみを扱います（セクション9.1.2を参照）。このような要素パターンは、netMod固有のアノテーション属性@NMA：デフォルトまたは@NMA：暗黙的、つまり：
<rng:element name="ELEM" nma:default="DEFVALUE">
...
</rng:element>
or
また
<rng:element name="ELEM" nma:implicit="true">
...
</rng:element>
The former case applies to leaf nodes having the 'default' substatement, but also to leaf nodes that obtain their default value from a typedef, if this typedef is expanded according to the rules in Section 9.2.2 so that the @nma:default annotation is attached directly to the leaf's element pattern.
前者のケースは、「デフォルト」の置換を持つ葉のノードに適用されますが、このtypedefがセクション9.2.2のルールに従って拡張されて@NMA：デフォルトの注釈に従って拡張されている場合、typedefからデフォルト値を取得する葉のノードにも適用されますリーフの要素パターンに直接付着しています。
The latter case is used for all implicit containers (see Section 9.1) and for leafs that obtain the default value from a typedef and don't have the @nma:default annotation.
後者のケースは、すべての暗黙的なコンテナ（セクション9.1を参照）およびtypedefからデフォルト値を取得し、@NMA：デフォルトのアノテーションを持っていない葉に使用されます。
In the simplest case, both element patterns are mapped to the following DSRL element map:
最も単純な場合、両方の要素パターンが次のDSRL要素マップにマッピングされます。
<dsrl:element-map>
<dsrl:parent>XPARENT</dsrl:parent>
<dsrl:name>ELEM</dsrl:name>
<dsrl:default-content>DEFCONT</dsrl:default-content>
</dsrl:element-map>
where XPARENT is the absolute XPath of ELEM's parent element in the data tree and DEFCONT is constructed as follows:
Xparentは、データツリーとDefcontのElemの親要素の絶対的なXpathです。次のように構築されています。
o If the implicit node ELEM is a leaf and has the @nma:default attribute, DEFCONT is set to the value of this attribute (denoted above as DEFVALUE).
o 暗黙的なノードエレムがリーフであり、@NMA：デフォルト属性を持っている場合、defContはこの属性の値に設定されます（上記でdefvalueとして表されます）。
o If the implicit node ELEM is a leaf and has the @nma:implicit attribute with the value of "true", the default value has to be determined from the @nma:default attribute of the definition of ELEM's type (perhaps recursively) and used in place of DEFCONT in the above DSRL element map. See also Section 9.2.2.
o 暗黙のノードエレムがリーフであり、@NMA：「true」の値を持つ暗黙的属性を持っている場合、デフォルト値は@NMA：ELEMのタイプの定義のデフォルト属性（おそらく再帰的）から決定する必要があり、使用する必要があります。上記のDSRL要素マップのDefContの代わりに。セクション9.2.2も参照してください。
o Otherwise, the implicit node ELEM is a container and DEFCONT is constructed as an XML fragment containing all descendant elements of ELEM that have either the @nma:implicit or the @nma:default attribute.
o それ以外の場合、暗黙のノードエレムはコンテナであり、defcontは@NMA：Implictまたは@NMA：デフォルト属性のいずれかを持つエレムのすべての子孫要素を含むXMLフラグメントとして構築されます。
In addition, when mapping the default case of a choice, it has to be guaranteed that the default contents are not applied if any node from any non-default case is present. This is accomplished by setting <dsrl:parent> in a special way:
さらに、選択のデフォルトのケースをマッピングする場合、非デフォルトケースのノードが存在する場合、デフォルトのコンテンツが適用されないことを保証する必要があります。これは、<dsrl：parent>を特別な方法で設定することで達成されます。
<dsrl:parent>XPARENT[not (ELEM1|ELEM2|...|ELEMn)]</dsrl:parent>
where ELEM1, ELEM2, ... ELEMn are the names of all top-level nodes from all non-default cases. The rest of the element map is exactly as before.
ここで、ELEM1、ELEM2、... Elemnは、すべての非デフォルトケースのすべてのトップレベルノードの名前です。要素マップの残りの部分は、以前とまったく同じです。
EXAMPLE. Consider the following YANG module:
例。次のYangモジュールを検討してください。
module example6 {
namespace "http://example.com/ns/example6";
prefix ex6;
container outer {
leaf leaf1 {
type uint8;
default 1;
}
choice one-or-two {
default "one";
container one {
leaf leaf2 {
type uint8;
default 2;
}
}
leaf leaf3 {
type uint8;
default 3;
}
}
}
}
The DSRL schema generated for the "get-reply" target document type
will be:
<?xml version="1.0" encoding="utf-8"?>
<dsrl:maps xmlns:dsrl="http://purl.oclc.org/dsdl/dsrl"
xmlns:ex6="http://example.com/ns/example6"
xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
<dsrl:element-map>
<dsrl:parent>/nc:rpc-reply/nc:data</dsrl:parent>
<dsrl:name>ex6:outer</dsrl:name>
<dsrl:default-content>
<ex6:leaf1>1</ex6:leaf1>
<ex6:one>
<ex6:leaf2>2</ex6:leaf2>
</ex6:one>
</dsrl:default-content>
</dsrl:element-map>
<dsrl:element-map>
<dsrl:parent>/nc:rpc-reply/nc:data/ex6:outer</dsrl:parent>
<dsrl:name>ex6:leaf1</dsrl:name>
<dsrl:default-content>1</dsrl:default-content>
</dsrl:element-map>
<dsrl:element-map>
<dsrl:parent>
/nc:rpc-reply/nc:data/ex6:outer[not(ex6:leaf3)]
</dsrl:parent>
<dsrl:name>ex6:one</dsrl:name>
<dsrl:default-content>
<ex6:leaf2>2</ex6:leaf2>
</dsrl:default-content>
</dsrl:element-map>
<dsrl:element-map>
<dsrl:parent>
/nc:rpc-reply/nc:data/ex6:outer/ex6:one
</dsrl:parent>
<dsrl:name>ex6:leaf2</dsrl:name>
<dsrl:default-content>2</dsrl:default-content>
</dsrl:element-map>
</dsrl:maps>
Note that the default value for "leaf3" defined in the YANG module is ignored because "leaf3" represents a non-default alternative of a choice and as such never becomes an implicit element.
Yangモジュールで定義されている「leaf3」のデフォルト値は無視されていることに注意してください。「leaf3」は選択の非デフォルトの代替品を表しているため、暗黙の要素になることはありません。
This section contains the mapping specification for the individual NETMOD-specific annotations. In each case, the result of the mapping must be inserted into an appropriate context of the target DSDL schema as described in Section 11. The context is determined by the element pattern in the hybrid schema to which the annotation is attached. In the rest of this section, CONTELEM will denote the name of this context element properly qualified with its namespace prefix.
このセクションには、個々のNetMod固有の注釈のマッピング仕様が含まれています。いずれの場合も、セクション11で説明されているように、マッピングの結果をターゲットDSDLスキーマの適切なコンテキストに挿入する必要があります。コンテキストは、注釈が付着するハイブリッドスキーマの要素パターンによって決定されます。このセクションの残りの部分では、Contelemは、名前空間プレフィックスで適切に適格になったこのコンテキスト要素の名前を示します。
If this annotation is present with the value of "false", the following rules MUST be observed for DSDL schemas of <nc:get-config> reply:
この注釈が「false」の値と存在する場合、<nc：get-config>のDSDLスキーマについては、次のルールを遵守する必要があります。
o When generating RELAX NG, the contents of the CONTELEM definition MUST be changed to <rng:notAllowed>.
o リラックスngを生成する場合、Contelem定義の内容を<rng：notallowed>に変更する必要があります。
o When generating Schematron or DSRL, the CONTELEM definition and all its descendants in the hybrid schema MUST be ignored.
o スキーマトロンまたはDSRLを生成する場合、ハイブリッドスキーマのコンテルム定義とそのすべての子孫は無視する必要があります。
This annotation is used for generating the DSRL schema as described in Section 11.3.
この注釈は、セクション11.3で説明されているDSRLスキーマの生成に使用されます。
This annotation currently has no mapping defined.
この注釈には現在、マッピングが定義されていません。
This annotation is handled within <nma:must>, see Section 12.13.
この注釈は、<nma：must>内で処理され、セクション12.13を参照してください。
The information about available features MAY be supplied as an input parameter to an implementation. In this case, the following changes MUST be performed for all features that are considered unavailable:
利用可能な機能に関する情報は、実装の入力パラメーターとして提供される場合があります。この場合、利用できないと見なされるすべての機能について、次の変更を実行する必要があります。
o When generating RELAX NG, the contents of the CONTELEM definition MUST be changed to <rng:notAllowed>.
o リラックスngを生成する場合、Contelem定義の内容を<rng：notallowed>に変更する必要があります。
o When generating Schematron or DSRL, the CONTELEM definition and all its descendants in the hybrid schema MUST be ignored.
o スキーマトロンまたはDSRLを生成する場合、ハイブリッドスキーマのコンテルム定義とそのすべての子孫は無視する必要があります。
This annotation is used for generating the DSRL schema as described in Section 11.3.
この注釈は、セクション11.3で説明されているDSRLスキーマの生成に使用されます。
If this annotation element has the @require-instance attribute with the value of "false", it is ignored. Otherwise, it is mapped to the following Schematron assert:
この注釈要素には、「false」の値を持つ @require-instance属性がある場合、それは無視されます。それ以外の場合は、次のスキマトロンのアサートにマッピングされます。
<sch:assert test="nmf:evaluate(.)">
The element pointed to by "CONTELEM" must exist.
</sch:assert>
The nmf:evaluate() function is an XSLT extension function (see Extension Functions in [XSLT]) that evaluates an XPath expression at run time. Such an extension function is available in Extended XSLT (EXSLT) or provided as a proprietary extension by some XSLT processors, for example Saxon.
NMF：evaluate（）関数は、実行時にXPath式を評価するXSLT拡張機能（[XSLT]の拡張機能を参照）です。このような拡張機能は、拡張XSLT（EXSLT）で利用可能であるか、一部のXSLTプロセッサ、たとえばSaxonによって独自の拡張機能として提供されます。
Assume this annotation attribute contains "k_1 k_2 ... k_n", i.e., specifies n children of CONTELEM as list keys. The annotation is then mapped to the following Schematron report:
このアノテーション属性には「k_1 k_2 ... k_n」が含まれていると仮定します。つまり、n contelemの子供をリストキーとして指定します。次に、注釈は次のSchematronレポートにマッピングされます。
<sch:report test="CONDITION">
Duplicate key of list "CONTELEM"
</sch:report>
where CONDITION has this form: preceding-sibling::CONTELEM[C_1 and C_2 and ... and C_n]
条件にはこの形式があります：先行するsibling :: contelem [c_1 and c_2 and ... and c_n]
Each sub-expression C_i, for i=1,2,...,n, specifies the condition for violated uniqueness of the key k_i, namely
i = 1,2、...、nの場合、各サブエクスペッションC_Iは、キーK_Iの違反の一意性の条件を指定します。
k_i=current()/k_i
k_i = current（）/k_i
This annotation is mapped to the following Schematron rule, which detects duplicate entries of a leaf-list:
この注釈は、葉のリストの重複エントリを検出する次のスキーマトロンルールにマッピングされます。
<sch:report test=". = preceding-sibling::PREFIX:sorted-entry"> Duplicate leaf-list entry "<sch:value-of select="."/>". </sch:report> See Section 11.2 for a complete example.
<sch：レポートtest = "。=先行者:: prefix：sorted-entry"> duplicate leaf-list enter "<sch：value-of select ="。 "/>"。</sch：レポート>完全な例については、セクション11.2を参照してください。
This annotation is mapped to the following assert:
この注釈は、次の主張にマッピングされます。
<sch:assert test="PATH=.">
Leaf "PATH" does not exist for leafref value "VALUE"
</sch:assert>
where PATH is the value of @nma:leafref and VALUE is the value of the context element in the instance document for which the referred leaf doesn't exist.
パスは@NMAの値です：leafrefと値は、参照された葉が存在しないインスタンスドキュメントのコンテキスト要素の値です。
This annotation is mapped to the following Schematron assert:
この注釈は、次のスキマトロンの主張にマッピングされます。
<sch:assert test="count(../CONTELEM)>=MIN">
List "CONTELEM" - item count must be at least MIN
</sch:assert>
where MIN is the value of @nma:min-elements.
ここで、最小は@NMAの値です：MIN-ELEMENTS。
This annotation is mapped to the following Schematron assert:
この注釈は、次のスキマトロンの主張にマッピングされます。
<sch:assert
test="count(../CONTELEM)<=MAX or preceding-sibling::../CONTELEM">
Number of list items must be at most MAX
</sch:assert>
where MAX is the value of @nma:min-elements.
ここで、最大は@NMA：MIN-ELEMENTSの値です。
This annotation is mapped to the following Schematron assert:
この注釈は、次のスキマトロンの主張にマッピングされます。
<sch:assert test="EXPRESSION">
MESSAGE
</sch:assert>
where EXPRESSION is the value of the mandatory @assert attribute of <nma:must>. If the <nma:error-message> subelement exists, MESSAGE is set to its contents; otherwise, it is set to the default message "Condition EXPRESSION must be true".
ここで、表現は<nma：bese>の必須@Assert属性の値です。<nma：error-message> subelementが存在する場合、メッセージはその内容に設定されます。それ以外の場合、デフォルトのメッセージ「条件式は真でなければならない」に設定されています。
This annotation currently has no mapping defined.
この注釈には現在、マッピングが定義されていません。
This annotation currently has no mapping defined.
この注釈には現在、マッピングが定義されていません。
The mapping of this annotation is almost identical as for @nma:key, see Section 12.8, with two small differences:
この注釈のマッピングは、@NMAとほぼ同じです。キー、セクション12.8を参照してください。2つの小さな違いがあります。
o The value of @nma:unique is a list of descendant schema node identifiers rather than simple leaf names. However, the XPath expressions specified in Section 12.8 work without any modifications if the descendant schema node identifiers are substituted for k_1, k_2, ..., k_n.
o @NMAの値：ユニークは、単純な葉の名前ではなく、子孫スキーマノード識別子のリストです。ただし、セクション12.8で指定されたXPath式は、K_1、K_2、...、K_Nに代わって置換されている場合、変更なしで修正なしで動作します。
o The message appearing as the text of <sch:report> is different: "Violated uniqueness for list CONTELEM".
o <sch：report>のテキストとして表示されるメッセージは異なります。
This annotation is mapped to the following Schematron assert:
この注釈は、次のスキマトロンの主張にマッピングされます。
<sch:assert test="EXPRESSION">
Node "CONTELEM" is only valid when "EXPRESSION" is true.
</sch:assert>
where EXPRESSION is the value of @nma:when.
ここで、表現は@NMAの値です：いつ。
This document requests the following two registrations of namespace URIs in the IETF XML registry [RFC3688]:
このドキュメントでは、IETF XMLレジストリ[RFC3688]の名前空間URIの次の2つの登録を要求します。
-----------------------------------------------------
URI: urn:ietf:params:xml:ns:netmod:dsdl-annotations:1
Registrant Contact: The IESG.
登録者の連絡先：IESG。
XML: N/A, the requested URI is an XML namespace.
-----------------------------------------------------
-----------------------------------------------------
URI: urn:ietf:params:xml:ns:netmod:xpath-extensions:1
Registrant Contact: The IESG.
登録者の連絡先：IESG。
XML: N/A, the requested URI is an XML namespace.
-----------------------------------------------------
This document defines a procedure that maps data models expressed in the YANG language to a coordinated set of DSDL schemas. The procedure itself has no security impact on the Internet.
このドキュメントでは、ヤン語で表現されたデータモデルをMaps DSDLスキーマの調整されたセットにマップする手順を定義します。手順自体は、インターネットにセキュリティの影響を与えません。
DSDL schemas obtained by the mapping procedure may be used for validating the contents of NETCONF messages or entire datastores, and thus they provide additional validity checks above those performed by NETCONF server and client implementations supporting YANG data models. The strictness of this validation is directly derived from the source YANG modules that the validated XML data adhere to.
マッピング手順で取得されたDSDLスキーマは、NetConfメッセージまたはデータストア全体の内容を検証するために使用される場合があります。したがって、YangデータモデルをサポートするNetConfサーバーおよびクライアント実装によって実行されたものよりも追加の妥当性チェックを提供します。この検証の厳格さは、検証されたXMLデータが接着するソースYangモジュールから直接導き出されます。
The following people contributed significantly to the initial version of this document:
次の人々は、このドキュメントの初期バージョンに大きく貢献しました。
o Rohan Mahy
o ロハン・マヒ
o Sharon Chisholm (Ciena)
o シャロン・チショルム（シエナ）
The editor wishes to thank the following individuals who provided helpful suggestions and/or comments on various versions of this document: Andy Bierman, Martin Bjorklund, Jirka Kosek, Juergen Schoenwaelder, and Phil Shafer.
編集者は、このドキュメントのさまざまなバージョンについて有益な提案やコメントを提供してくれた以下の個人に感謝したいと考えています：アンディ・ビアマン、マーティン・ビョルドンド、ジルカ・コセク、ジュエルゲン・シェーンワエルダー、フィル・シェーファー。
[DSDL] ISO/IEC, "Document Schema Definition Languages (DSDL) - Part 1: Overview", ISO/IEC 19757-1, November 2004.
[DSDL] ISO/IEC、「ドキュメントスキーマ定義言語（DSDL） - パート1：概要 "、ISO/IEC 19757-1、2004年11月。
[DSRL] ISO/IEC, "Information Technology - Document Schema Definition Languages (DSDL) - Part 8: Document Semantics Renaming Language - DSRL", ISO/ IEC 19757-8:2008(E), December 2008.
[DSRL] ISO/ IEC、「情報技術 - ドキュメントスキーマ定義言語（DSDL） - パート8：文書セマンティクスの名前を変更する言語-DSRL」、ISO/ IEC 19757-8：2008（e）、2008年12月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[RFC3688] Mealling、M。、「IETF XMLレジストリ」、BCP 81、RFC 3688、2004年1月。
[RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741, December 2006.
[RFC4741] ENNS、R。、「NetConf Configuration Protocol」、RFC 4741、2006年12月。
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for Network Configuration Protocol (NETCONF)", RFC 6020, October 2010.
[RFC6020] Bjorklund、M.、ed。、「Yang-ネットワーク構成プロトコル（NetConf）のデータモデリング言語」、RFC 6020、2010年10月。
[RFC6021] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6021, October 2010.
[RFC6021] Schoenwaelder、J.、ed。、「Common Yang Data型」、RFC 6021、2010年10月。
[RNG] ISO/IEC, "Information Technology - Document Schema Definition Languages (DSDL) - Part 2: Regular-Grammar-Based Validation - RELAX NG. Second Edition.", ISO/ IEC 19757-2:2008(E), December 2008.
[RNG] ISO/ IEC、「情報技術 - ドキュメントスキーマ定義言語（DSDL） - パート2：レギュラーグラマベースの検証 - リラックスNg。SecondEdition」、ISO/ IEC 19757-2：2008（e）、12月2008年。
[RNG-CS] ISO/IEC, "Information Technology - Document Schema Definition Languages (DSDL) - Part 2: Regular-Grammar-Based Validation - RELAX NG. AMENDMENT 1: Compact Syntax", ISO/IEC 19757-2:2003/Amd. 1:2006(E), January 2006.
[RNG-CS] ISO/IEC、「情報技術 - ドキュメントスキーマ定義言語（DSDL） - パート2：レギュラーグラマベースの検証-NG。修正1：コンパクト構文」、ISO/IEC 19757-2：2003/amd。1：2006（e）、2006年1月。
[RNG-DTD] Clark, J., Ed. and M. Murata, Ed., "RELAX NG DTD Compatibility", OASIS Committee Specification, 3 December 2001.
[RNG-DTD]クラーク、J。、編and M. Murata ed。、「ng ng dtd互換性をリラックス」、Oasis委員会の仕様、2001年12月3日。
[Schematron] ISO/IEC, "Information Technology - Document Schema Definition Languages (DSDL) - Part 3: Rule-Based Validation - Schematron", ISO/IEC 19757-3:2006(E), June 2006.
[Schematron] ISO/IEC、「情報技術 - ドキュメントスキーマ定義言語（DSDL） - パート3：ルールベースの検証 - スキーマトロン」、ISO/IEC 19757-3：2006（e）、2006年6月。
[XML] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth Edition)", World Wide Web Consortium Recommendation REC-xml-20081126, November 2008, <http://www.w3.org/TR/2006/REC-xml-20060816>.
[XML] Bray、T.、Paoli、J.、Sperberg-Mcqueen、C.、Maler、E。、およびF. Yergeau、「拡張可能なマークアップ言語（XML）1.0（第5版）」、World Wide Web Consortiumの推奨REC-XML-20081126、2008年11月、<http://www.w3.org/tr/2006/rec-xml-20060816>。
[XML-INFOSET] Tobin, R. and J. Cowan, "XML Information Set (Second Edition)", World Wide Web Consortium Recommendation REC-xml-infoset-20040204, February 2004, <http://www.w3.org/TR/2004/REC-xml-infoset-20040204>.
[XML-Infoset] Tobin、R。およびJ. Cowan、「XML Information Set（第2版）」、World Wide Web Consortiumの推奨REC-XML-INFOSET-20040204、2004年2月、<http://www.w3.org/TR/2004/REC-XML-INFOSET-20040204>。
[XPath] Clark, J. and S. DeRose, "XML Path Language (XPath) Version 1.0", World Wide Web Consortium Recommendation REC-xpath-19991116, November 1999, <http://www.w3.org/TR/1999/REC-xpath-19991116>.
[Xpath] Clark、J。and S. Derose、「XML Path Language（XPath）バージョン1.0」、World Wide Web Consortiumの推奨REC-XPATH-19991116、1999年11月、<http://www.w3.org/tr/1999/rec-xpath-1991116>。
[XSD-D] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes Second Edition", World Wide Web Consortium Recommendation REC-xmlschema-2-20041028, October 2004, <http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.
[XSD-D] Biron、P。and A. Malhotra、「XML Schema Part 2：DataTypes Second Edition」、World Wide Web Consortiumの推奨REC-XMLSCHEMA-2-20041028、2004年10月、<http：//www.w3。ORG/TR/2004/REC-XMLSCHEMA-2-20041028>。
[XSLT] Clark, J., "XSL Transformations (XSLT) Version 1.0", World Wide Web Consortium Recommendation REC-xslt-19991116, November 1999.
[XSLT] Clark、J。、「XSL Transformations（XSLT）バージョン1.0」、World Wide Web Consortiumの推奨REC-XSLT-1991116、1999年11月。
[DHCPtut] Bjorklund, M., "DHCP Tutorial", November 2007, <http:/ /www.yang-central.org/twiki/bin/view/Main/ DhcpTutorial>.
[dhcptut] Bjorklund、M。、 "dhcpチュートリアル"、2007年11月、<http：//www.yang-central.org/twiki/bin/view/main/ dhcptutorial>。
[RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol (SNMP)", RFC 1157, May 1990.
[RFC1157] Case、J.、Fedor、M.、Schoffstall、M。、およびJ. Davin、「Simple Network Management Protocol（SNMP）」、RFC 1157、1990年5月。
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[RFC2578] McCloghrie、K.、Ed。、Perkins、D.、ed。、およびJ. Schoenwaelder、ed。、「管理情報の構造バージョン2（SMIV2）」、STD 58、RFC 2578、1999年4月。
[RFC5013] Kunze, J., "The Dublin Core Metadata Element Set", RFC 5013, August 2007.
[RFC5013] Kunze、J。、「ダブリンコアメタデータエレメントセット」、RFC 5013、2007年8月。
[RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event Notifications", RFC 5277, July 2008.
[RFC5277] Chisholm、S。およびH. Trevino、「NetConf Event Notifications」、RFC 5277、2008年7月。
[Trang] Clark, J., "Trang: Multiformat schema converter based on RELAX NG", 2008, <http://www.thaiopensource.com/relaxng/trang.html>.
[Trang] Clark、J。、「Trang：Multiformat Schema Converter byruct ngに基づく」、2008年、<http://www.thaiopensource.com/relaxng/trang.html>。
[Vli04] van der Vlist, E., "RELAX NG", O'Reilly, 2004.
[VLI04] van der Vlist、E。、 "Relax ng"、O'Reilly、2004。
[XSD] Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, "XML Schema Part 1: Structures Second Edition", World Wide Web Consortium Recommendation REC-xmlschema-1-20041028, October 2004, <http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>.
[XSD] Thompson、H.、Beech、D.、Maloney、M。、およびN. Mendelsohn、「XML Schema Part 1：Structures Second Edition」、World Wide Web Consortiumの推奨REC-XMLSCHEMA-1-20041028、2004年10月、<http://www.w3.org/tr/2004/rec-xmlschema-1-20041028>。
[pyang] Bjorklund, M. and L. Lhotka, "pyang: An extensible YANG validator and converter in Python", 2010, <http://code.google.com/p/pyang/>.
[Pyang] Bjorklund、M。and L. Lhotka、「Pyang：Pythonの拡張可能なYang Validator and Converter」、2010、<http://code.google.com/p/pyang/>。
This appendix defines the content model for all NETMOD-specific annotations in the form of RELAX NG named pattern definitions.
この付録は、すべてのNetMod固有の注釈のコンテンツモデルを定義し、パターン定義という名前のリラックスNGの形式です。
<CODE BEGINS> file "nmannot.rng"
<code begins> file "nmannot.rng"
<?xml version="1.0" encoding="UTF-8"?>
<grammar xmlns="http://relaxng.org/ns/structure/1.0"
xmlns:nma="urn:ietf:params:xml:ns:netmod:dsdl-annotations:1"
datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes">
<define name="config-attribute">
<attribute name="nma:config">
<data type="boolean"/>
</attribute>
</define>
<define name="data-element">
<element name="nma:data">
<ref name="__anyxml__"/>
</element>
</define>
<define name="default-attribute">
<attribute name="nma:default">
<data type="string"/>
</attribute>
</define>
<define name="error-app-tag-element">
<element name="nma:error-app-tag">
<text/>
</element>
</define>
<define name="error-message-element">
<element name="nma:error-message">
<text/>
</element>
</define>
<define name="if-feature-attribute">
<attribute name="nma:if-feature">
<list>
<data type="QName"/>
</list>
</attribute>
</define>
<define name="implicit-attribute">
<attribute name="nma:implicit">
<data type="boolean"/>
</attribute>
</define>
<define name="instance-identifier-element">
<element name="nma:instance-identifier">
<optional>
<attribute name="nma:require-instance">
<data type="boolean"/>
</attribute>
</optional>
</element>
</define>
<define name="key-attribute">
<attribute name="nma:key">
<list>
<data type="QName"/>
</list>
</attribute>
</define>
<define name="leaf-list-attribute">
<attribute name="nma:leaf-list">
<data type="boolean"/>
</attribute>
</define>
<define name="leafref-attribute">
<attribute name="nma:leafref">
<data type="string"/>
</attribute>
</define>
<define name="mandatory-attribute">
<attribute name="nma:mandatory">
<data type="Name"/>
</attribute>
</define>
<define name="max-elements-attribute">
<attribute name="nma:max-elements">
<data type="nonNegativeInteger"/>
</attribute>
</define>
<define name="min-elements-attribute">
<attribute name="nma:min-elements">
<data type="nonNegativeInteger"/>
</attribute>
</define>
<define name="module-attribute">
<attribute name="nma:module">
<data type="Name"/>
</attribute>
</define>
<define name="must-element">
<element name="nma:must">
<attribute name="assert">
<data type="string"/>
</attribute>
<interleave>
<optional>
<ref name="error-app-tag-element"/>
</optional>
<optional>
<ref name="error-message-element"/>
</optional>
</interleave>
</element>
</define>
<define name="notifications-element">
<element name="nma:notifications">
<zeroOrMore>
<element name="nma:notification">
<ref name="__anyxml__"/>
</element>
</zeroOrMore>
</element>
</define>
<define name="rpcs-element">
<element name="nma:rpcs">
<zeroOrMore>
<element name="nma:rpc">
<interleave>
<element name="nma:input">
<ref name="__anyxml__"/>
</element>
<optional>
<element name="nma:output">
<ref name="__anyxml__"/>
</element>
</optional>
</interleave>
</element>
</zeroOrMore>
</element>
</define>
<define name="ordered-by-attribute">
<attribute name="nma:ordered-by">
<choice>
<value>user</value>
<value>system</value>
</choice>
</attribute>
</define>
<define name="status-attribute">
<optional>
<attribute name="nma:status">
<choice>
<value>current</value>
<value>deprecated</value>
<value>obsolete</value>
</choice>
</attribute>
</optional>
</define>
<define name="unique-attribute">
<optional>
<attribute name="nma:unique">
<list>
<data type="token"/>
</list>
</attribute>
</optional>
</define>
<define name="units-attribute">
<optional>
<attribute name="nma:units">
<data type="string"/>
</attribute>
</optional>
</define>
<define name="when-attribute">
<optional>
<attribute name="nma:when">
<data type="string"/>
</attribute>
</optional>
</define>
<define name="__anyxml__">
<zeroOrMore>
<choice>
<attribute>
<anyName/>
</attribute>
<element>
<anyName/>
<ref name="__anyxml__"/>
</element>
<text/>
</choice>
</zeroOrMore>
</define>
</grammar>
</grammar>
<CODE ENDS>
<コードエンド>
In order to avoid copying the common named pattern definitions to every RELAX NG schema generated in the second mapping step, the definitions are collected in a library file -- schema-independent library -- which is included by the validating schemas under the file name "relaxng-lib.rng" (XML syntax) and "relaxng-lib.rnc" (compact syntax). The included definitions cover patterns for common elements from base NETCONF [RFC4741] and event notifications [RFC5277].
2番目のマッピングステップで生成されたすべてのリラックスNGスキーマに共通の名前付きパターン定義をコピーすることを避けるために、定義はライブラリファイル（スキーマに依存しないライブラリ）に収集されます。rackng-lib.rng "（xml syntax）および" rackng-lib.rnc "（コンパクト構文）。含まれる定義は、ベースネットコン[RFC4741]およびイベント通知[RFC5277]の共通要素のパターンをカバーしています。
<CODE BEGINS> file "relaxng-lib.rng"
<code begins> file "rackng-lib.rng"
<?xml version="1.0" encoding="UTF-8"?>
<grammar xmlns="http://relaxng.org/ns/structure/1.0"
xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"
xmlns:en="urn:ietf:params:xml:ns:netconf:notification:1.0"
datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes">
<define name="message-id-attribute">
<attribute name="message-id">
<data type="string">
<param name="maxLength">4095</param>
</data>
</attribute>
</define>
<define name="ok-element">
<element name="nc:ok">
<empty/>
</element>
</define>
<define name="eventTime-element">
<element name="en:eventTime">
<data type="dateTime"/>
</element>
</define>
</grammar>
<CODE ENDS>
<コードエンド>
This appendix demonstrates both steps of the YANG-to-DSDL mapping applied to the "canonical" DHCP tutorial [DHCPtut] data model. The input YANG module is shown in Appendix C.1 and the output schemas in the following two subsections.
この付録は、「標準的な」DHCPチュートリアル[DHCPTUT]データモデルに適用されたYang-to-DSDLマッピングの両方のステップを示しています。入力Yangモジュールは、付録C.1と次の2つのサブセクションに出力スキーマに示されています。
The hybrid schema was obtained by the "dsdl" plugin of the pyang tool [pyang] and the validating DSDL schemas were obtained by XSLT stylesheets that are also part of pyang distribution.
ハイブリッドスキーマは、Pyangツール[Pyang]の「DSDL」プラグインによって取得され、検証済みのDSDLスキーマは、Pyang分布の一部でもあるXSLTスタイルシートによって取得されました。
Due to the limit of 72 characters per line, a few long strings required manual editing, in particular the regular expression patterns for IP addresses, etc. These were replaced by the placeholder string "... regex pattern ...". Also, line breaks were added to several documentation strings and Schematron messages.
1行あたり72文字の制限により、いくつかの長い文字列には手動編集、特にIPアドレスの正規表現パターンなどが必要でした。これらはプレースホルダー文字列「... regexパターン...」に置き換えられました。また、いくつかのドキュメンテーション文字列とスキーマトロンメッセージにラインブレークが追加されました。
Other than that, the results of the automatic translations were not changed.
それ以外は、自動翻訳の結果は変更されませんでした。
module dhcp { namespace "http://example.com/ns/dhcp"; prefix dhcp;
モジュールdhcp {namespace "http://example.com/ns/dhcp";プレフィックスDHCP;
import ietf-yang-types { prefix yang; }
import ietf-inet-types { prefix inet; }
organization
"yang-central.org";
description
"Partial data model for DHCP, based on the config of
the ISC DHCP reference implementation.";
container dhcp { description "configuration and operational parameters for a DHCP server.";
コンテナDHCP {説明 "DHCPサーバーの構成と動作パラメーター。";
leaf max-lease-time {
type uint32;
units seconds;
default 7200;
}
leaf default-lease-time {
type uint32;
units seconds;
must '. <= ../max-lease-time' {
error-message
"The default-lease-time must be less than max-lease-time";
}
default 600;
}
uses subnet-list;
サブネットリストを使用します。
container shared-networks {
list shared-network {
key name;
leaf name {
type string;
}
uses subnet-list;
}
}
container status {
config false;
list leases {
key address;
leaf address {
type inet:ip-address;
}
leaf starts {
type yang:date-and-time;
}
leaf ends {
type yang:date-and-time;
}
container hardware {
leaf type {
type enumeration {
enum "ethernet";
enum "token-ring";
enum "fddi";
}
}
leaf address {
type yang:phys-address;
}
}
}
}
}
grouping subnet-list {
description "A reusable list of subnets";
list subnet {
key net;
leaf net {
type inet:ip-prefix;
}
container range {
presence "enables dynamic address assignment";
leaf dynamic-bootp {
type empty;
description
"Allows BOOTP clients to get addresses in this range";
}
leaf low {
type inet:ip-address;
mandatory true;
}
leaf high {
type inet:ip-address;
mandatory true;
}
}
container dhcp-options {
description "Options in the DHCP protocol";
leaf-list router {
type inet:host;
ordered-by user;
reference "RFC 2132, sec. 3.8";
}
leaf domain-name {
type inet:domain-name;
reference "RFC 2132, sec. 3.17";
}
}
leaf max-lease-time {
type uint32;
units seconds;
default 7200;
}
}
}
}
<?xml version="1.0" encoding="UTF-8"?>
<grammar
xmlns="http://relaxng.org/ns/structure/1.0"
xmlns:nma="urn:ietf:params:xml:ns:netmod:dsdl-annotations:1"
xmlns:dc="http://purl.org/dc/terms"
xmlns:a="http://relaxng.org/ns/compatibility/annotations/1.0"
xmlns:dhcp="http://example.com/ns/dhcp"
datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes">
<dc:creator>Pyang 1.0a, DSDL plugin</dc:creator>
<dc:date>2010-06-17</dc:date>
<start>
<grammar nma:module="dhcp" ns="http://example.com/ns/dhcp">
<dc:source>YANG module 'dhcp'</dc:source>
<start>
<nma:data>
<optional>
<element nma:implicit="true" name="dhcp:dhcp">
<interleave>
<a:documentation>
configuration and operational parameters for a DHCP server.
</a:documentation>
<optional>
<element nma:default="7200"
name="dhcp:max-lease-time"
nma:units="seconds">
<data type="unsignedInt"/>
</element>
</optional>
<optional>
<element nma:default="600"
name="dhcp:default-lease-time"
nma:units="seconds">
<data type="unsignedInt"/>
<nma:must assert=". <= ../dhcp:max-lease-time">
<nma:error-message>
The default-lease-time must be less than max-lease-time
</nma:error-message>
</nma:must>
</element>
</optional>
<ref name="_dhcp__subnet-list"/>
<optional>
<element name="dhcp:shared-networks">
<zeroOrMore>
<element nma:key="dhcp:name"
name="dhcp:shared-network">
<element name="dhcp:name">
<data type="string"/>
</element>
<ref name="_dhcp__subnet-list"/>
</element>
</zeroOrMore>
</element>
</optional>
<optional>
<element name="dhcp:status" nma:config="false">
<zeroOrMore>
<element nma:key="dhcp:address"
name="dhcp:leases">
<element name="dhcp:address">
<ref name="ietf-inet-types__ip-address"/>
</element>
<interleave>
<optional>
<element name="dhcp:starts">
<ref name="ietf-yang-types__date-and-time"/>
</element>
</optional>
<optional>
<element name="dhcp:ends">
<ref name="ietf-yang-types__date-and-time"/>
</element>
</optional>
<optional>
<element name="dhcp:hardware">
<interleave>
<optional>
<element name="dhcp:type">
<choice>
<value>ethernet</value>
<value>token-ring</value>
<value>fddi</value>
</choice>
</element>
</optional>
<optional>
<element name="dhcp:address">
<ref name="ietf-yang-types__phys-address"/>
</element>
</optional>
</interleave>
</element>
</optional>
</interleave>
</element>
</zeroOrMore>
</element>
</optional>
</interleave>
</element>
</optional>
</nma:data>
<nma:rpcs/>
<nma:notifications/>
</start>
</grammar>
</start>
<define name="ietf-yang-types__phys-address">
<data type="string">
<param name="pattern">([0-9a-fA-F]{2}(:[0-9a-fA-F]{2})*)?</param>
</data>
</define>
<define name="ietf-inet-types__ipv6-address">
<data type="string">
<param name="pattern">... regex pattern ...</param>
<param name="pattern">... regex pattern ...</param>
</data>
</define>
<define name="ietf-inet-types__ip-prefix">
<choice>
<ref name="ietf-inet-types__ipv4-prefix"/>
<ref name="ietf-inet-types__ipv6-prefix"/>
</choice>
</define>
<define name="ietf-inet-types__host">
<choice>
<ref name="ietf-inet-types__ip-address"/>
<ref name="ietf-inet-types__domain-name"/>
</choice>
</define>
<define name="ietf-yang-types__date-and-time">
<data type="string">
<param name="pattern">... regex pattern ...</param>
</data>
</define>
<define name="_dhcp__subnet-list">
<a:documentation>A reusable list of subnets</a:documentation>
<zeroOrMore>
<element nma:key="net" name="subnet">
<element name="net">
<ref name="ietf-inet-types__ip-prefix"/>
</element>
<interleave>
<optional>
<element name="range">
<interleave>
<optional>
<element name="dynamic-bootp">
<a:documentation>
Allows BOOTP clients to get addresses in this range
</a:documentation>
<empty/>
</element>
</optional>
<element name="low">
<ref name="ietf-inet-types__ip-address"/>
</element>
<element name="high">
<ref name="ietf-inet-types__ip-address"/>
</element>
</interleave>
</element>
</optional>
<optional>
<element name="dhcp-options">
<interleave>
<a:documentation>
Options in the DHCP protocol
</a:documentation>
<zeroOrMore>
<element nma:leaf-list="true" name="router"
nma:ordered-by="user">
<a:documentation>
See: RFC 2132, sec. 3.8
</a:documentation>
<ref name="ietf-inet-types__host"/>
</element>
</zeroOrMore>
<optional>
<element name="domain-name">
<a:documentation>
See: RFC 2132, sec. 3.17
</a:documentation>
<ref name="ietf-inet-types__domain-name"/>
</element>
</optional>
</interleave>
</element>
</optional>
<optional>
<element nma:default="7200" name="max-lease-time"
nma:units="seconds">
<data type="unsignedInt"/>
</element>
</optional>
</interleave>
</element>
</zeroOrMore>
</define>
<define name="ietf-inet-types__domain-name">
<data type="string">
<param name="pattern">... regex pattern ...</param>
<param name="minLength">1</param>
<param name="maxLength">253</param>
</data>
</define>
<define name="ietf-inet-types__ipv4-prefix">
<data type="string">
<param name="pattern">... regex pattern ...</param>
</data>
</define>
<define name="ietf-inet-types__ipv4-address">
<data type="string">
<param name="pattern">... regex pattern ...</param>
</data>
</define>
<define name="ietf-inet-types__ipv6-prefix">
<data type="string">
<param name="pattern">... regex pattern ...</param>
<param name="pattern">... regex pattern ...</param>
</data>
</define>
<define name="ietf-inet-types__ip-address">
<choice>
<ref name="ietf-inet-types__ipv4-address"/>
<ref name="ietf-inet-types__ipv6-address"/>
</choice>
</define>
</grammar>
This appendix contains DSDL schemas that were obtained from the hybrid schema in Appendix C.2 by XSL transformations. These schemas can be directly used for validating a reply to unfiltered <nc:get> with the contents corresponding to the DHCP data model.
この付録には、XSL変換によって付録C.2のハイブリッドスキーマから得られたDSDLスキーマが含まれています。これらのスキーマは、DHCPデータモデルに対応する内容を使用して、フィルター処理されていない<NC：get>への返信を検証するために直接使用できます。
The RELAX NG schema (in two parts, as explained in Section 8.2) also includes the schema-independent library from Appendix B.
リラックスNGスキーマ（セクション8.2で説明されている2つの部分）には、付録Bのスキーマに依存しないライブラリも含まれています。
<?xml version="1.0" encoding="utf-8"?>
<grammar
xmlns="http://relaxng.org/ns/structure/1.0"
xmlns:nma="urn:ietf:params:xml:ns:netmod:dsdl-annotations:1"
xmlns:dhcp="http://example.com/ns/dhcp"
datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes"
ns="urn:ietf:params:xml:ns:netconf:base:1.0">
<include href="relaxng-lib.rng"/>
<start>
<element name="rpc-reply">
<ref name="message-id-attribute"/>
<element name="data">
<interleave>
<grammar ns="http://example.com/ns/dhcp">
<include href="dhcp-gdefs.rng"/>
<start>
<optional>
<element name="dhcp:dhcp">
<interleave>
<optional>
<element name="dhcp:max-lease-time">
<data type="unsignedInt"/>
</element>
</optional>
<optional>
<element name="dhcp:default-lease-time">
<data type="unsignedInt"/>
</element>
</optional>
<ref name="_dhcp__subnet-list"/>
<optional>
<element name="dhcp:shared-networks">
<zeroOrMore>
<element name="dhcp:shared-network">
<element name="dhcp:name">
<data type="string"/>
</element>
<ref name="_dhcp__subnet-list"/>
</element>
</zeroOrMore>
</element>
</optional>
<optional>
<element name="dhcp:status">
<zeroOrMore>
<element name="dhcp:leases">
<element name="dhcp:address">
<ref name="ietf-inet-types__ip-address"/>
</element>
<interleave>
<optional>
<element name="dhcp:starts">
<ref name="ietf-yang-types__date-and-time"/>
</element>
</optional>
<optional>
<element name="dhcp:ends">
<ref name="ietf-yang-types__date-and-time"/>
</element>
</optional>
<optional>
<element name="dhcp:hardware">
<interleave>
<optional>
<element name="dhcp:type">
<choice>
<value>ethernet</value>
<value>token-ring</value>
<value>fddi</value>
</choice>
</element>
</optional>
<optional>
<element name="dhcp:address">
<ref name="ietf-yang-types__phys-address"/>
</element>
</optional>
</interleave>
</element>
</optional>
</interleave>
</element>
</zeroOrMore>
</element>
</optional>
</interleave>
</element>
</optional>
</start>
</grammar>
</interleave>
</element>
</element>
</start>
</grammar>
<?xml version="1.0" encoding="utf-8"?>
<grammar
xmlns="http://relaxng.org/ns/structure/1.0"
xmlns:nma="urn:ietf:params:xml:ns:netmod:dsdl-annotations:1"
xmlns:dhcp="http://example.com/ns/dhcp"
datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes">
<define name="ietf-yang-types__phys-address">
<data type="string">
<param name="pattern">
([0-9a-fA-F]{2}(:[0-9a-fA-F]{2})*)?
</param>
</data>
</define>
<define name="ietf-inet-types__ipv6-address">
<data type="string">
<param name="pattern">... regex pattern ...</param>
</data>
</define>
<define name="ietf-inet-types__ip-prefix">
<choice>
<ref name="ietf-inet-types__ipv4-prefix"/>
<ref name="ietf-inet-types__ipv6-prefix"/>
</choice>
</define>
<define name="ietf-inet-types__host">
<choice>
<ref name="ietf-inet-types__ip-address"/>
<ref name="ietf-inet-types__domain-name"/>
</choice>
</define>
<define name="ietf-yang-types__date-and-time">
<data type="string">
<param name="pattern">... regex pattern ...</param>
</data>
</define>
<define name="_dhcp__subnet-list">
<zeroOrMore>
<element name="subnet">
<element name="net">
<ref name="ietf-inet-types__ip-prefix"/>
</element>
<interleave>
<optional>
<element name="range">
<interleave>
<optional>
<element name="dynamic-bootp">
<empty/>
</element>
</optional>
<element name="low">
<ref name="ietf-inet-types__ip-address"/>
</element>
<element name="high">
<ref name="ietf-inet-types__ip-address"/>
</element>
</interleave>
</element>
</optional>
<optional>
<element name="dhcp-options">
<interleave>
<zeroOrMore>
<element name="router">
<ref name="ietf-inet-types__host"/>
</element>
</zeroOrMore>
<optional>
<element name="domain-name">
<ref name="ietf-inet-types__domain-name"/>
</element>
</optional>
</interleave>
</element>
</optional>
<optional>
<element name="max-lease-time">
<data type="unsignedInt"/>
</element>
</optional>
</interleave>
</element>
</zeroOrMore>
</define>
<define name="ietf-inet-types__domain-name">
<data type="string">
<param name="pattern">... regex pattern ...</param>
<param name="minLength">1</param>
<param name="maxLength">253</param>
</data>
</define>
<define name="ietf-inet-types__ipv4-prefix">
<data type="string">
<param name="pattern">... regex pattern ...</param>
</data>
</define>
<define name="ietf-inet-types__ipv4-address">
<data type="string">
<param name="pattern">... regex pattern ...</param>
</data>
</define>
<define name="ietf-inet-types__ipv6-prefix">
<data type="string">
<param name="pattern">... regex pattern ...</param>
<param name="pattern">... regex pattern ...</param>
</data>
</define>
<define name="ietf-inet-types__ip-address">
<choice>
<ref name="ietf-inet-types__ipv4-address"/>
<ref name="ietf-inet-types__ipv6-address"/>
</choice>
</define>
</grammar>
<?xml version="1.0" encoding="utf-8"?>
<sch:schema xmlns:sch="http://purl.oclc.org/dsdl/schematron">
<sch:ns uri="http://example.com/ns/dhcp" prefix="dhcp"/>
<sch:ns uri="urn:ietf:params:xml:ns:netconf:base:1.0" prefix="nc"/>
<sch:pattern abstract="true" id="_dhcp__subnet-list">
<sch:rule context="$start/$pref:subnet">
<sch:report test="preceding-sibling::$pref:subnet
[$pref:net=current()/$pref:net]">
Duplicate key "net"
</sch:report>
</sch:rule>
<sch:rule
context="$start/$pref:subnet/$pref:dhcp-options/$pref:router">
<sch:report test=".=preceding-sibling::router">
Duplicate leaf-list value "<sch:value-of select="."/>"
</sch:report>
</sch:rule>
</sch:pattern>
<sch:pattern id="dhcp">
<sch:rule
context="/nc:rpc-reply/nc:data/dhcp:dhcp/dhcp:default-lease-time">
<sch:assert test=". <= ../dhcp:max-lease-time">
The default-lease-time must be less than max-lease-time
</sch:assert>
</sch:rule>
<sch:rule context="/nc:rpc-reply/nc:data/dhcp:dhcp/
dhcp:shared-networks/dhcp:shared-network">
<sch:report test="preceding-sibling::dhcp:shared-network
[dhcp:name=current()/dhcp:name]">
Duplicate key "dhcp:name"
</sch:report>
</sch:rule>
<sch:rule context="/nc:rpc-reply/nc:data/dhcp:dhcp/
dhcp:status/dhcp:leases">
<sch:report test="preceding-sibling::dhcp:leases
[dhcp:address=current()/dhcp:address]">
Duplicate key "dhcp:address"
</sch:report>
</sch:rule>
</sch:pattern>
<sch:pattern id="id2768196" is-a="_dhcp__subnet-list">
<sch:param name="start" value="/nc:rpc-reply/nc:data/dhcp:dhcp"/>
<sch:param name="pref" value="dhcp"/>
</sch:pattern>
<sch:pattern id="id2768215" is-a="_dhcp__subnet-list">
<sch:param name="start"
value="/nc:rpc-reply/nc:data/dhcp:dhcp/
dhcp:shared-networks/dhcp:shared-network"/>
<sch:param name="pref" value="dhcp"/>
</sch:pattern>
</sch:schema>
<?xml version="1.0" encoding="utf-8"?>
<dsrl:maps
xmlns:dsrl="http://purl.oclc.org/dsdl/dsrl"
xmlns:dhcp="http://example.com/ns/dhcp"
xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
<dsrl:element-map>
<dsrl:parent>/nc:rpc-reply/nc:data</dsrl:parent>
<dsrl:name>dhcp:dhcp</dsrl:name>
<dsrl:default-content>
<dhcp:max-lease-time>7200</dhcp:max-lease-time>
<dhcp:default-lease-time>600</dhcp:default-lease-time>
</dsrl:default-content>
</dsrl:element-map>
<dsrl:element-map>
<dsrl:parent>/nc:rpc-reply/nc:data/dhcp:dhcp</dsrl:parent>
<dsrl:name>dhcp:max-lease-time</dsrl:name>
<dsrl:default-content>7200</dsrl:default-content>
</dsrl:element-map>
<dsrl:element-map>
<dsrl:parent>/nc:rpc-reply/nc:data/dhcp:dhcp</dsrl:parent>
<dsrl:name>dhcp:default-lease-time</dsrl:name>
<dsrl:default-content>600</dsrl:default-content>
</dsrl:element-map>
<dsrl:element-map>
<dsrl:parent>
/nc:rpc-reply/nc:data/dhcp:dhcp/dhcp:subnet
</dsrl:parent>
<dsrl:name>dhcp:max-lease-time</dsrl:name>
<dsrl:default-content>7200</dsrl:default-content>
</dsrl:element-map>
<dsrl:element-map>
<dsrl:parent>
/nc:rpc-reply/nc:data/dhcp:dhcp/dhcp:shared-networks/
dhcp:shared-network/dhcp:subnet
</dsrl:parent>
<dsrl:name>dhcp:max-lease-time</dsrl:name>
<dsrl:default-content>7200</dsrl:default-content>
</dsrl:element-map>
</dsrl:maps>
Author's Address
著者の連絡先
Ladislav Lhotka (editor) CESNET
ladislav lhotka（編集者）cesnet
EMail: lhotka@cesnet.cz