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
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.
この文書は、文書スキーマ定義言語（DSDL）、以下のDSDLスキーマ言語をマッピングすることによって対処されているISO / IEC 19757.として標準XMLスキーマ言語の協調セットにYANGデータモデルを変換するためのマッピング規則を指定します：XML次のために定期的な言語世代（NGをRELAX）のSchematron、およびSchematronのとドキュメントのスキーマ名前変更言語（DSRL）。マッピングは、一つ以上のYANGモジュールを取得し、選択されたターゲットドキュメントタイプのDSDLスキーマのセットを生成 - データストアのコンテンツ、ネットワーク構成プロトコル（NETCONF）メッセージ等のようなドキュメントのスキーマベースの検証のための手順も議論されています。
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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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ワーキンググループは、「人への優しさ」、すなわち、読みやすさと使いやすさに焦点を当てて、運用データ、構成データ、イベント通知、および操作のセマンティクスを定義するモデリング言語を設計するためにチャーターされました。結果は現在NETCONFデータモデルの規範的な説明に役立つYANGデータモデリング言語[RFC6020]です。
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
NETCONFは、そのメッセージをエンコードするためのXMLを使用しているので、標準のXMLスキーマ言語を使用して、NETCONFコンテンツの制約を表現するのが自然です。この目的のために、NETMOD WGは、ISO / IEC 19757 [DSDL]として標準化された文書スキーマ定義言語（DSDL）を選択しました。 DSDLフレームワークは、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.
もっと重要なのは、スキーマの文法規則、意味的な制約、および他のデータモデリング側面に対処言語だけでなく、とは、協調と一貫性のある方法でそれを行います。いくつかのDSDLパーツはまだ標準化されておらず、まだ進行中の作業されていることは事実ですが、YANGツーDSDLマッピングが依存している三つの部分 - XML次世代（NGをRELAX）、Schematronのとドキュメントのスキーマのための規則的な言語言語（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.
この文書では、DSDLのスキーマ言語のサブセットを使用するXMLスキーマにYANGデータモデルを変換マッピングの仕様が含まれています。マッピング手順を2つの段階に分けられる：第1のステップでは、データツリーの構造は、リモートプロシージャコール（RPC）操作、および通知の署名が、いわゆる「ハイブリッドスキーマ」として表される - 単一RELAX NG追加のデータモデル情報（メタデータ、ドキュメント、意味制約、デフォルト値、など）を表す注釈付きスキーマ。第二段階は、おそらくも考慮に、このような能動的な機能や機能などの追加のコンテキストを取って、そのようなクライアント要求、サーバ応答や通知などの特定の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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
The following terms are defined in [RFC4741]:
以下の用語は[RFC4741]で定義されています。
o client
またはクライアント
o datastore
Oデータストア
o message
Oメッセージ
o operation
運用O
o server
Oサーバ
The following terms are defined in [RFC6020]:
以下の用語は[RFC6020]で定義されています。
o augment
または増加
o base type
Oベースタイプ
o built-in type o configuration data
OビルトインタイプO構成データ
o container
Oコンテナ
o data model
Oデータモデル
o data node
お だた ので
o data tree
Oデータツリー
o derived type
O派生型
o device deviation
Oデバイス偏差
o extension
O拡張
o feature
お ふぇあつれ
o grouping
Oのグループ化
o instance identifier
O体を識別
o leaf-list
リーフリスト
o list
手紙
o mandatory node
お まんだとｒｙ ので
o module
Oモジュール
o RPC
O RPC
o RPC operation
OのRPC操作
o schema node
お ｓちぇま ので
o schema tree
Oスキーマツリー
o state data
O状態データ
o submodule
Oサブモジュール
o top-level data node
Oトップレベル・データ・ノード
o uses
Oの使い方
The following terms are defined in [XML-INFOSET]:
以下の用語は[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];
"" DTD互換注釈[RNG-DTD]。
"dc" Dublin Core metadata elements [RFC5013];
"DC" のDublin Coreメタデータ・エレメント[RFC5013]。
"dsrl" Document Semantics Renaming Language [DSRL];
「デジタル一眼レフ」ドキュメント意味名前変更言語[DSLR]。
"en" NETCONF event notifications [RFC5277];
「エン」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]をRELAX。
"sch" ISO Schematron [Schematron];
ISO Schematronの[Schematronの] "SCH"。
"xsd" W3C XML Schema [XSD].
"XSD" W3C XML Schemaの[XSD]。
The following table shows the mapping of these prefixes to namespace URIs.
次の表では、名前空間URIにこれらのプレフィックスのマッピングを示しています。
+--------+-----------------------------------------------------+
| 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ハイブリッドスキーマ：注釈をRELAX 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.
この作品の主な目的はNG、のSchematron、およびDSRLをRELAXすなわち、DSDLスキーマ言語の検証機能を備えたデータモデリング言語としてYANGを補完することです。この文書は、YANGで発現文法、意味、及びデータ・タイプの制約と同等DSDLパターンとルールとの対応関係を記載しています。究極の目標は、YANGモジュールに含まれるすべてのかなりの情報をキャプチャし、DSDLスキーマでそれを表現することができることです。 YANGからDSDLへのマッピングは、原則的に可逆であり、この文書で説明したが、YANGへDSDLから逆マッピングは、このドキュメントの範囲を超えています。
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.
コンフィギュレーションデータストアの内容、RPCの要求と応答、および通知 - XMLベースの情報モデルとXMLでエンコードされたデータは、YANGデータモデリングとNETCONFワークフローのさまざまな段階で、いくつかの異なる形式で表示されます。また、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.最初のステップは、主データ・ツリーのための、並びにRPC操作および通知のための文法的制約を記述する単一RELAX NGスキーマ、いわゆるハイブリッドスキーマ、1つのまたは複数のYANGモジュールをマッピングします。セマンティック制約および入力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.第二のステップでは、ステップ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）DSDL]国際標準ISO / IEC 19757として開発されているスキーマ言語のフレームワークです。 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].
この文書に記載されたマッピングは、DSDLスキーマ言語のうち3つを使用して、すなわちNG [RNG]のSchematron [Schematronの]、およびDSRL [DSRL]をRELAX。
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).
RELAX NG（「リラックス」と発音）は規格のISO / IEC DSDLファミリーの文法ベースのバリデーションとパート2のためのXMLスキーマ言語[RNG]です。 XSDのように、それは構造上の制約とXML文書の内容を記述することができます。しかし、DTD [XML]とXSDスキーマ言語とは異なり、NGが意図的にそのようなデフォルト値を定義するように任意の情報セット増大を回避RELAX。 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.
その基本データ型ライブラリとして、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.
RELAX NGは、他の名前空間からの注釈を受け入れるには非常にリベラルです。いくつかの例外を除いて、そのような注釈は、スキーマ内の任意の場所に配置され、そのような<XSD：注釈>として全く封止要素必要なくてもよいXSDです。
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].
RELAX NGスキーマは、2つの等価な構文で表すことができます：XMLとコンパクト。コンパクトな構文はRELAX NG仕様の付属書C 2006年に標準に添加したRNG-CS]、（追補1）に記載されています。 2つの構文の間での自動双方向変換はいくつかのツールを使用して達成することができ、例えば、トラン[トラン]。
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:
その簡潔さと読みやすさのために、コンパクトな構文は、バリや他のソフトウェアツールは、通常、XML構文で動作するのに対し、公開用の好ましい形態は、RELAX NGスキーマをしばしばです。しかし、コンパクトな構文は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".
RELAX 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のは、[Schematronの] 2006年に完全なISO / IEC標準の状態に達しDSDLのパート3です。正式な文法の概念に基づいており、このような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アサート条件が偽またはレポートの状態にあるときに表示される人間が読めるメッセージはtrueです。
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の]と拡張スタイルシート言語変換（XSLT）XSLT]からその表現力の大部分を描きます。次のXMLクエリ言語を使用することができるようにISO Schematronのは、動的クエリ言語のために結合できます：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.
人間が読めるエラーメッセージは、他の一般的なスキーマ言語から離れたSchematronを設定し、別の機能です。メッセージでも、実際のコンテキストで評価されている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.
マッピングで使用されたSchematronのもう一つの特徴は、抽象的なパターンです。これらはマクロとして本質的に機能し、また抽象パターンが使用されるとき供給されるパラメータを含んでいてもよいです。
Schematron elements are qualified with namespace URI "http://purl.oclc.org/dsdl/schematron".
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は"）[DSRL] 2008年に完全なISO / IEC標準の状態に達しDSDLのパート8です。 RELAX NGとSchematronのとは異なり、DSRLが検証文書のXML情報セットを変更することが許可されています。 DSRLは主にXMLの要素と属性の名前を変更するためのものですが、それはまた、彼らは検証された文書に含まれていない場合、デフォルトの内容が挿入されるように、XML要素またはサブツリーのXML属性とデフォルトの内容のデフォルト値を定義することができます。後者の機能は、デフォルト値とその祖先の非存在下のコンテナとリーフノードからなるYANGのデフォルトの内容を表すためYANGツー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.
ダブリンコア要素と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.
第三のセットはNETMOD固有のアノテーションです。彼らは、具体的には、ハイブリッド・スキーマ用に設計されており、セマンティック制約と直接にRELAX 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".
ダブリンコア要素は、「http://purl.org/dc/terms」名前空間URIで修飾されています。
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互換性注釈は、RELAX NG DTD互換仕様[RNG-DTD]の一部です。 YANG「説明」と「参照」テキストを表現するための<ドキュメント>注釈YANGツーDSDLマッピングがのみ使用しています。
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-互換にする意図がないことに注意してください、これらのアノテーションを使用する主な理由は、技術である：彼らはよくサポートされており、適切にいくつかのRELAX 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で修飾されているXML要素や属性である「URN：IETF：のparams：XML：NS：netmod：DSDL-注釈：1」とそのハイブリッドスキーマのさまざまな場所に表示されます。 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は、この注釈の語彙のためのRELAX 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:
ノート：
3. Has a mandatory attribute @assert and two optional subelements <nma:error-app-tag> and <nma:error-message>.
<NMA：エラー・メッセージ>：3.必須属性の@assertと2つのオプションのサブ要素の<error-APP-タグNMA>を持っています。
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ツー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つまたは複数のYANGモジュールをマッピング（8.1節を参照）。 RELAX NGの中で直接表現できない制約（リストキー定義は、「しなければならない」文など）や、各種ドキュメントのテキストは、外国の名前空間注釈としてスキーマ内に記録されています。
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.第二のステップでは、ハイブリッド・スキーマは、特定のコンテキスト内の特定のデータ・オブジェクトを検証するために使用することができるDSDLスキーマの協調セットに複数の方法で変換することができます。図1は、例として3つの簡単な可能性を示しています。プロセスでは、ハイブリッド・スキーマの適切な部分が抽出され、特定の注釈は、Schematronのパターン、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つのモジュールが他のモジュールのデータツリーを増強する「増強」文によって結合されてもよいです。
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モジュールに含まれるその他の情報は、注釈などのハイブリッドスキーマに記録されている - 名前空間URI「URNで修飾XML属性または要素：IETF：のparams：XML：NS：netmod：dsdl-注釈：1" 。 YANGモジュールを記述するメタデータは、Dublin Coreの注釈要素（セクション5.1）にマッピングされます。 DTDの互換性の語彙（5.2節）に属する：<ドキュメント>要素の最後に、説明文字列はにマッピングされます。
The output of the second step is a coordinated set of three DSDL schemas corresponding to a specific data object and context:
第二段階の出力は、特定のデータオブジェクトと文脈に対応する3つのDSDLスキーマの協調セットです。
o RELAX NG schema describing the grammatical and data type constraints;
O文法とデータ型制約を記述するRELAX NGスキーマ。
o Schematron schema expressing other constraints such as uniqueness of list keys or user-specified semantic rules;
そのようなリストキーまたはユーザ指定のセマンティック規則の一意のような他の制約を発現OのSchematronスキーマ。
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ツー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文書の情報セットを変更することに注意してください。
+----------+ +----------+
| | | 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.
ハイブリッドスキーマ、RELAX NGの構文と追加の注釈を使用して、全体のデータモデルの全ての制約を指定 - セクション6で説明したように、マッピングの最初のステップは、中間文書を生成します。で直接検証に使用することはできません - それは特別な注釈要素によって画定複数のスキーマが含まれているため、実際の問題として、それはRELAX 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モジュールは、RELAX NGスキーマで表現できないその他の重要な情報を提供しています。そのような情報項目は、以下のURIと名前空間に属するXML属性および要素としてハイブリッドスキーマで表され：「URN：IETF：paramsは：XML：NS：netmod：DSDL-注釈：1」。これらのアノテーションの完全なリストは、第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モジュールは、[RFC5277]の構成と状態データのためだけでなく、（複数の）RPC操作[RFC4741]及び/又はイベント通知のためだけでなく、データモデルを定義します。あるスキーマ文書にデータモデルの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要素である（：IETF：URIのURNのparams：XML：NS：netmod：DSDL-注釈：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:
例えば、二つのYANGによって形成されたデータ・モデルを考慮すると、「実施例A」と名前空間内のノードの定義「の例-B」「http://example.com/ns/example-a」および「HTTPモジュール：// example.com/ns/example-b」。モジュール「の例は、」のみの構成/状態データを定義する「例-B」に対し、構成/状態データ、RPCメソッドと通知を定義します。次のようにハイブリッド・スキーマは、次に概略的に表すことができます。
<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>
<文法のxmlns = "http://relaxng.org/ns/structure/1.0" のxmlns：NMA = "URN：IETF：paramsは：XML：NS：netmod：DSDL-注釈：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"> <開始> <文法NMA：モジュール= "例 - " NS = "http://example.com/ns/example-a"> <起動> <NMA：データ> ...に定義されている構成と状態データ "例えば、」... </ NMA：データ> <NMA：のRPC> <NMA：RPC> <NMA：入力> <要素名= "EXA：myrpc"> ... </要素> </ NMA：入力> <NMA：出力> ... </ NMA：出力> </ NMA：RPC> ... </ NMA：RPCの> <NMA：通知> <NMA：通知> <要素名= "EXA：mynotif"> ... </要素> </ NMA：通知> ... </ NMA：通知が> </スタート> ...たとえば、... </文法> <文法NMAのローカル名前パターン定義：モジュール= "例B-" NS = "http://example.com/ns/example-a"> <起動> <NMA：データ> ... "例-B" で定義された構成と状態データ... </ NMA：データ> <NMA：RPCを/> <NMA：通知/> </スタート> ...ローカル命名パターン例-Bの定義... </文法> </スタート>
...global named pattern definitions... </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オファーは、別個のモジュールに完全なスキーマの内容を分割し、結合または様々な方法でそれらを再利用するため、すなわちモジュール、手段。しかし、アプローチはYANGで撮影したと異なり、RELAX NGを。 YANGは、SNMP MIBモジュールと同様のモジュールの大規模なセットを想定し、一方、NG RELAXにおけるモジュールは、スキーマの少数のアドホック組み合わせに適しています。次のような違いが重要です。
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では、定義（グルーピングとのtypedef）へのアクセスを取得するモジュールBの最上位に現れるが、モジュールBからのデータツリーのどの部分がそれとともにインポートされていません。対照的に、：NGが含まれるスキーマの名前パターンの両方の定義とスキーマ全体のツリーをインポートRELAXパターンを<RNGは、>。
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).
輸入YANGのグループとのtypedefの名前oをインポートされたモジュールの名前空間で修飾されています。一方、輸入モジュール内で使用されるインポートグループ、内部に含まれるデータノードの名前は、インポートモジュールの名前空間の一部となります。 RELAX NGをでは、パターンの名前は輸入、インポートモジュールを共有両方同じフラットな名前空間で定義された修飾されていないので、名前のパターンです。 RELAX 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.
NGを緩和する、可能な限り、YANGのモジュールをマッピングするために、検証がNGスキーマ（第2のマッピングステップの結果）は、2つのファイル、マップされたすべてのグローバル定義を含むそれらのいずれかに分割されなければならないRELAXすべての入力YANGモジュールに現れる最上位YANGのグループから。 @ns属性を経由してこのRELAX NGのスキーマは、任意の名前空間を定義してはなりません。
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.
他RELAX NGスキーマファイルは、それらのそれぞれの独自の埋め込み文法で囲まれた入力YANGモジュールからマッピングされた実際のデータツリーを定義します。グローバル定義の少なくとも一つが使用されるもの埋め込ま文法は、定義を持つ最初のスキーマを含まなければならないし、また@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).
<：文法RNG>要素（ハイブリッドスキーマのドキュメントルート）Oすべてのグローバル定義は、外側の子として配置されなければなりません。
o Every non-global definitions MUST be placed as a child of the corresponding embedded <rng:grammar> element.
<：文法RNG>要素Oすべての非グローバル定義は、対応する組み込みの子として置かなければなりません。
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スキーマ構造の異なるスタイルをサポートしています。多くの場合、「ロシア人形」と呼ばれる一方の極端では、単一階層内のXMLインスタンス文書の構造を指定します。すべてのXML要素は、名前のパターン定義に対応 - 他の極端では、フラットなスタイルは、データ型定義（DTD）スキーマ言語と同様のアプローチを採用しています。実際には、両極端の間にいくつかの妥協は通常、選択されています。
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をRELAXで必要とされているのでNGスキーマは、非常に平坦になりがちRELAX。 YANGについては、これはその「オーグメント」と既存の構造の任意の深さに、パス式を使用することにより、掘り下げることができます「絞り込み」ステートメント以来、問題ではありません。
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をRELAXで利用可能なものにYANGの強力な拡張メカニズムをマッピングすることは不可能です。 YANGのグループ化や派生型の定義は通常、RELAX NGスキーマを結果として生じるで名付けられたパターンの定義における直接の対応を持っています。このため、マッピングは、基本的に、元YANGデータモデルの精度を維持します。
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.
NG、Schematronの、そしてDSRL、複数の名前空間からの要素を含む、いわゆる複合XML文書のサポートをスキーマをRELAX含むほとんどの近代的なXMLスキーマ言語、。 YANGツーDSDLマッピングは自然に文書スキーマを化合物につながる複数の入力YANGモジュールを可能にするので、これは私たちの目的のために有用です。
RELAX NG offers two alternatives for defining the target namespaces in the schema:
NGスキーマにターゲット名前空間を定義するための2つの選択肢を提供していますRELAX：
1. First possibility is the traditional XML way via the @xmlns:xxx attribute.
XXX属性：1.まず可能性が@xmlnsを経由して、伝統的なXMLの方法です。
2. One of the target namespace URIs may be declared using the @ns attribute.
2.ターゲット名前空間URIの一つは@ns属性を使用して宣言することができます。
In both the hybrid schema and validation RELAX NG schemas generated in the second step, the namespaces MUST be declared as follows:
次のようにハイブリッド・スキーマと検証第二ステップで生成されたNGスキーマをRELAXの両方で、名前空間を宣言する必要があります。
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.ルート<RNG：文法は> @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：文法>要素属性@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.
XXX：標準XMLはのxmlns属性を経由してDSRLスキーマがターゲット名前空間の任意の数を宣言してもよいです。
In contrast, Schematron requires all used namespaces to be defined in the <sch:ns> subelements of the document element <sch:schema>.
文書要素<：スキーマSCH>のサブ要素：対照的に、Schematronのは<NS SCH>で定義されるすべての使用される名前空間を必要とします。
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.
個々YANG文のマッピングの詳細な仕様はセクション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のスキーマ言語では、ノードに対する出現制約は常にそのノードと一緒に局在しています。 RELAX NGスキーマでは、例えば、<RNG：オプション>パターンは、リーフまたは非リーフ要素を定義するパターンの親要素として現れます。同様に、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モジュールにおけるリーフノードのために、発生の制約も簡単に「葉」のサブステートメントから推測されます。一方、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のマッピングステップの目標の一つは、それに応じて、対応する<RNG：エレメント>すべてのデータノードとマークするための発生の制約を推論することであるハイブリッド・スキーマにパターンを任意の形質転換手順ように、第2のマッピングステップででき単にこの情報を使用して、再度サブツリーを調べる必要はありません。
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.
他の出現制約は、「デフォルト」の文の意味と空の非存在コンテナを除去する可能性に関係しています。結果として、有効な構成の情報セットは、コンフィギュレーションの意味を変更することなく、特定のリーフまたはコンテナ要素を追加または削除することによって修正することができます。この文書では、そのような要素は、暗黙的と呼ばれています。デフォルトまたは@nma：暗黙の属性ハイブリッドスキーマでは、彼らはNGパターンが@nmaのいずれかを有するRELAXとして同定することができます。
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:
両方の発生の制約がそれらの親ノードがインスタンス文書内に存在することを付加条件の下で、他のコンテナにも、データ・ツリーの最上位レベルのコンテナに適用され、ことに留意されたいです。たとえば、次のようYANGフラグメントを考えてみます。
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.
与えられたノードが必須かオプションであるかどうかの決定は、次の規則によって支配さ：葉、AnyXMLで、と選択肢のノードoを、彼らはサブステートメント「真の義務を、」含まれている場合は必須です。選択ノードの場合、これは、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.
それがゼロより大きい引数値を持つ 'MIN-要素のサプを含む場合、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コンテナノードは必須です。
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.
要素：RELAX NGでは、オプションであるノードの定義は明示的に<オプションRNG>でラップする必要があります。マッピングは、YANGノードはオプションであるかどうかを決定するために上記の規則を使用し、そうであれば、<RNG：オプション>を挿入しなければならないハイブリッド・スキーマの要素を。
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：選択>での代替案は、ハイブリッドスキーマでオプションとして定義されてはなりません。 YANGでの選択は必須ではありません場合は、<RNG：オプション> <：選択RNG>パターン全体をラップするために使用しなければなりません。
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でマークする必要があります：暗黙の属性が「真」の値を有します。
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のグループとのtypedefは、一般的にNGという名前のパターンを緩和するためにマッピングされます。マッピングは考慮に入れる必要があり、いくつかの注意点は、しかし、があります。
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:
まず、陽型定義とグループ化は、モジュールの階層のすべてのレベルで表示され、字句スコープの対象となっている、[RFC6020]セクション5.5を参照してもよいです。修飾名は、外部モジュールの名前空間接頭辞及び記号の名前を用いて表されるように、第2、外部モジュールからトップレベル・シンボルがインポートされてもよいです。その定義は、唯一の子としてトップレベルに表示される場合があります。< - 同じ名前空間を共有し、文法の中に、彼らは常にグローバルである：これとは対照的に、中に名前のパターンがNG（パターン<含まRNG>を介してローカルと輸入の両方を）RELAX RNG：文法>要素。 YANGのグループとのtypedefが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モジュール階層の最上位に表示されるグループとのtypedefの名前はモジュール名と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、他のグループとのtypedefの名前は、すなわち、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.
YANGでのグループとのtypedefの名前が異なる名前空間を持っているので、O最後に、追加のアンダースコア文字は、すべてのグループのマングルされた名前の先頭に追加されます。
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入力及び出力パラメータは、サブエレメントは、データ・モデルで指定された順序に従わなければなりません。そうでない場合は、順序は任意です。任意の順番で一定の順序を有するもの及び他の - グルーピングがRPC入力/出力パラメータに、他の場所の両方に使用される場合、結果として、2つの異なる名前パターンの定義にマッピングされなければなりません。それらを区別するために、「__rpc」サフィックスが一定の順序でバージョンに追加されなければなりません。
EXAMPLE. Consider the following YANG module that imports the standard module "ietf-inet-types" [RFC6021]:
例。 「IETF-INET-タイプの」標準モジュール[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：名前を定義= "example1__vowels"> <RNG：データタイプ= "文字列"> <RNG：PARAM名= "パターン"> [aeiouy] * </ RNG：param>の</ RNG：データ> </ RNG。定義>
<rng:define name="_example1__grp1"> <rng:optional> <rng:element name="void"> <rng:empty/> </rng:element> </rng:optional> </rng:define>
<RNG：定義名= "_ example1__grp1"> <RNG：オプション> <RNG：要素名= "ボイド"> <RNG：空/> </ RNG：要素> </ RNG：オプション> </ RNG：定義>
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のグループ分けは、RELAX NGの中に名前のパターンの定義と同様の概念を表し、両方の言語も、その後続の変更のためのメカニズムを提供します。しかし、YANGは、グループの拡張を変更する「用途」、二サブステートメントを提供する一方、NG、それ自体が変更された定義を、RELAXで：「絞り込み」Oステートメントは、親 'によって参照グルーピング内部スキーマ・ノードのパラメータを変更することができステートメントを使用しています。
o The 'augment' statement can be used for adding new schema nodes to the grouping contents.
O「オーグメント」ステートメントは、グループ化の内容に新しいスキーマのノードを追加するために使用することができます。
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風の式を使用して、彼らは対処できるという点で、非常に強力です。対照的に、RELAX NGの名前付きパターン定義の修飾は、名前パターン内容の最上位レベルで排他的に適用されます。 YANGに匹敵するという名前のパターンの修正可能性を達成するためには、RELAX 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.
グループ化の内容の内部、さらに「用途」の文がある場合、彼らは拡張が必要な場合があり、あまりにも：含まれているペアは「リファイン」の引数に指定した「修正パス」にある「グループ」/「が使用する」場合には必要ですまたはステートメントを「増やします」。
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：定義名= "_ example2__leaves"> <RNG：インターリーブ> <RNG：REF名= "_ example2__fr" /> <RNG：REF名= "_ example2__es" /> </ RNG：インタリーブ> </ RNG：定義>
<rng:define name="_example2__fr"> <rng:optional> <rng:element name="feuille"> <rng:data type="string"/> </rng:element> </rng:optional> </rng:define>
<RNG：定義名= "_ example2__fr"> <RNG：オプション> <RNG：要素名= "feuille"> <RNG：データタイプ= "文字列" /> </ RNG：要素> </ RNG：オプション> </ RNG：定義>
<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：定義名= "_ example2__es"> <RNG：オプション> <RNG：要素名= "hoja"> <RNG：データタイプ= "文字列" /> </ RNG：要素> </ RNG：オプション> </ RNG：定義>とハイブリッドスキーマのコンフィギュレーションデータの一部は、単一の名前付きパターン基準です。
<nma:data> <rng:ref name="_example2__leaves"/> </nma:data>
<NMA：データ> <RNG：参照名= "_ example2__leaves" /> </ NMA：データ>
Now assume that the "uses leaves" statement contains a 'refine' substatement, for example:
：今すぐ「葉を使用しています」文は、たとえば、「絞り込み」サブステートメントが含まれていることを前提とし
uses leaves { refine "hoja" { default "alamo"; } }
葉は{「hoja」{デフォルトの「アラモ」をリファイン使用しています。 }}
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:
「_example2__fr」 - 得られたハイブリッドスキーマは今ちょうど1という名前のパターン定義が含まれています。他の二つのグループ「葉」と「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>
<NMA：データ> <RNG：インターリーブ> <RNG：参照名= "_ example2__fr" /> <RNG：オプション> <RNG：要素名= "EX2：hoja" NMA：デフォルト= "アラモ"> <RNG：データ型= "文字列" /> </ RNG：要素> </ RNG：オプション> </ RNG：インタリーブ> </ NMA：データ>
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.
NGは、一つの新たな制約を追加することによって、（おそらく多段階で）内蔵タイプを制限することができYANGにおけるタイプ導出メカニズムの同等を持っていないRELAX。派生YANGタイプが制限なく使用されるたびに - 「葉」または他人のtypedef 'のいずれかのサブステートメントとして - その後、「タイプ」の文は、単に名前のパターンの参照<RNG：REF>にマップされ、型定義RELAX NGという名前のパターン定義にマッピングされ、<RNG：定義>。いずれかの制限が「タイプ」の文のサブステートメントとして指定されている場合、内蔵タイプのみの祖先は、ハイブリッドスキーマに表示されるようにしかし、型定義は、すべての組み合わせに対応面で制限、その時点で展開されなければなりません制限は、型派生のチェーンに沿って、さらに「タイプ」声明で見つかりました。
EXAMPLE. Consider this YANG module:
例。このYANGモジュールを考えてみます。
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:
「葉の月」の「タイプ」の文は、何の制限はありませんので、参照に単純にマッピングされている<RNG：参照名=「example3__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>
<RNG：定義名= "example3__dozen"> <RNG：データタイプ= "なunsignedByte"> <RNG：PARAM名= "のminInclusive"> 1 </ RNG：param>の<RNG：PARAM NAME = "maxInclusiveを"> 12 </ RNG：param>の</ RNG：データ> </ RNG：定義>
Assume now that the definition of leaf "month" is changed to:
「月」の葉の定義がに変更されたと仮定する：
leaf month { type dozen { range 7..max; } }
葉の月{型ダース{範囲7..max。 }}
The output RELAX NG schema then will not contain any named pattern definition and the leaf "month" will be mapped directly to:
出力は、任意の名前のパターン定義と葉「月」が含まれませんその後、RELAX 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>
<RNG：要素名= "EX3：月"> <RNG：データタイプ= "なunsignedByte"> <RNG：PARAM名= "のminInclusive"> 7 </ RNG：param>の<RNG：PARAM NAME = "maxInclusiveを"> 12 </ RNG：param>の</ RNG：データ> </ RNG：要素>
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.
タイプ導出チェーンのマッピングは、さらに型定義における「デフォルト」の文の存在によって複雑にすることができます。接続されるデフォルトの属性<RNG：定義>要素「デフォルト」の文を含む型定義が制限なく使用されたときに簡単な場合には、「デフォルト」の文は@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>
<RNG：定義名= "example3bis__dozen" @nma：デフォルト= "7"> <RNG：データタイプ= "なunsignedByte"> <RNG：PARAM名= "のminInclusive"> 1 </ RNG：param>の<RNG：PARAM名= "maxInclusiveを"> 12 </ RNG：param>の</ RNG：データ> </ RNG：定義>
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:
<：月ex3bis>要素の定義デフォルトはの属性になります：前の例のように、葉の「月」の定義に使用された場合、「ダース」タイプが制限されている場合は、「ダース」タイプが拡大し、@nmaする必要があります：
<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>
<RNG：要素名= "ex3bis：月" @nma：デフォルト= "7"> <RNG：データタイプ= "なunsignedByte"> <RNG：PARAM名= "のminInclusive"> 7 </ RNG：param>の<RNG： paramの名前= "maxInclusiveを"> 12 </ RNG：param>の</ RNG：データ> </ RNG：要素>
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「は必見」、「」、と「パス」ステートメントの引数のために完全なXPath 1.0構文[XPathの]を使用しています。内部の名前空間接頭辞を運ぶ必要はありませんノード名XPath式で：YANGモジュールで定義されたデータノードの名前は常にそのYANGモジュールの名前空間に属しているとして、YANGは、XPath 2.0のデフォルトの名前空間の概念に似簡素化を採用しました彼らが定義されていて、地元のモジュールの名前空間が想定されるモジュール。
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).
それらに含まれるすべての接頭辞ノード名がグループ化が使用されている各モジュール（参照、8.2節）の名前空間を採用しなければならないので、トップレベルのグループ内で表示されるXPath式は、特別な注意が必要です。これを達成するために、ローカルプレフィックスは、ハイブリッドスキーマで変数「$県」を使用して表現されなければなりません。次いで、XPath式に遭遇のSchematronスキーマ（セクション11.2を参照）YANGグルーピングがマッピングされた抽象パターンにパラメータを介してこの変数の適切な値を供給する。
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-リース時間」に変換されます。
o "$pref:dhcp/$pref:max-lease-time", if the expression is inside a top-level grouping;
O「$県：DHCP / $県：MAX-リース・タイム」、式はトップレベルのグループ内にある場合。
o "dhcp:dhcp/dhcp:max-lease-time", otherwise.
O "DHCP：DHCP / DHCP：MAX-リース・タイム"、それ以外の場合は。
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のような式、すなわち、キー識別子および「子孫スキーマノード識別子を」（のためのABNF生産と[RFC6020]のセクション12の「子孫-スキーマNODEID」を参照）を使用します。これらの表現は、同様にローカルモジュールのプレフィックスを追加することによって変換されなければなりません。
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要素と外来の名前空間からの名前の属性RELAX 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言語拡張は、またはDSDLスキーマの文脈で意味を持っていない可能性があります。そのため、実装は、拡張子のいずれかまたは全てを無視してもよいです。しかし、無視されていない拡張は、XML要素（複数可）及び/又は正確拡張のYIN形態と一致していること（複数の）属性にマップする必要があり、[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>
<RNG：要素名= "ACME：フォリオ"> <ACME：ドキュメントフラグ番号= "42" /> <RNG：データタイプ= "文字列" /> </ RNG：要素>
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.
このセクションの各サブセクションは、一の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：のRPC>内（即ち、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>で囲む必要がありますので、残りの（非キー）サブ要素の順序は、指定されていません。
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：インタリーブ>で囲む必要があり要素。
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.
結果のXMLフラグメントの親が親で示されなるRELAX NGスキーマの要素O。
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：要素>にマップされているプリペンドローカル名前空間接頭辞を持つ要素とARGUMENTその@name属性の値になります。 <RNG：要素>の内容は以下のとおりです。
<rng:ref name="__anyxml__"/>
<RNG：REF名= "__ __ AnyXMLで" />
Substatements of the 'anyxml' statement, if any, MAY be mapped to additional children of the <rng:element> element.
<：要素RNG>要素「AnyXMLで」ステートメントのサブステートメントは、もしあれば、追加の子供にマッピングされてもよいです。
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):
参照[Vli04]（<文法RNG>要素に、少なくとも一つの「AnyXMLで」文が入力YANGモジュールのいずれかで発生した場合、次のパターン定義は、ルートの子としてRELAX NGスキーマに正確に一度に添加しなければなりません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>
<RNG：定義名= "__ AnyXMLで__"> <RNG：zeroOrMore> <RNG：選択> <RNG：属性> <RNG：anyName /> </ RNG：属性> <RNG：要素> <RNG：anyName /> <RNG ：REF名= "__ __ AnyXMLで" /> </ RNG：要素> <RNG：テキスト/> </ RNG：選択> </ RNG：zeroOrMore> </ RNG：定義>
EXAMPLE: YANG statement in a module with namespace prefix "yam"
例：名前空間接頭辞「山芋」とモジュール内のYANG声明
anyxml data { description "Any XML content allowed here."; }
AnyXMLでデータ{説明「ここで許可され、任意のXMLコンテンツ。」; }
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>
<RNG：要素名= "山芋：データ"> <：ドキュメント>ここでは許可され、任意のXMLコンテンツ</：ドキュメント> <RNG：参照名= "__ __ AnyXMLで" /> </ RNG：要素>
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でノードがオプションである「真必須。」副文。 <RNG：要素>要素は、その後、<RNG：オプション>に包まれなければならない「AnyXMLで」ステートメントは、「選択」ステートメントの子であるため、その選択のための速記ケースを形成する場合を除いて、（のための第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.
モジュールまたはサブモジュールのトップレベルで、「オーグメント」ステートメントは、別のYANGモジュールのスキーマツリーを増強するために使用されています。増補モジュールは同じマッピングセッション内で処理されていない場合は、トップレベルの文は無視されなければならない「強化します」。それ以外の場合は、文の内容は、「オーグメント」ステートメントが表示されたモジュールの名前空間を持つ外国人のモジュールに追加されます。
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.
この文は、それがそのタイプ定義のサブステートメントとして表示される場合、セクション10.53.6を参照してください「アイデンティティ」のサブステートメントとして無視され、「identityref」タイプ内で処理されます。
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>要素、<グループRNG>またはこのステートメントは、にマッピングされます。兄弟「デフォルト」の文の引数は、引数に等しい場合、@nma：<：グループRNG>または<RNG：インターリーブ>要素「真」の値を持つ暗黙の属性は、それに加えなければなりません。 @nma：暗黙的な属性は、デフォルト以外のケースのトップレベルのノードのために使用してはいけません（[RFC6020]セクション7.9.3を参照）。
This statement is mapped to the <rng:choice> element.
<：選択RNG>要素この文はにマッピングされます。
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>.
「選択」は、「真」の価値の「必須」サブステートメントを持っている場合は、属性@nma：引数の値を持つ要素：必須の<選択肢RNG>に追加する必要があります。この場合は、11.2.1項を参照してください、追加的な取り扱いが必要な場合があります。そうでない場合、「必須真;」 <：選択RNG>要素でラップする必要があり、存在しない<RNG：オプション>。
The alternatives in <rng:choice> -- mapped from either the 'case' statement or a shorthand case -- MUST NOT be defined as optional.
<RNG：選択>での選択肢は - 「ケース」ステートメントまたは速記ケースのいずれかからマップ - オプションとして定義されてはなりません。
This statement is mapped to the @nma:config attribute, and ARGUMENT becomes its value.
設定属性、および引数がその値になります：この文は@nmaにマッピングされます。
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>を挿入するかどうかを判断しなければなりません。
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.
親の子になり、その@name属性の値としてプリペンドローカル名前空間接頭辞と引数を使用して要素、この文で定義されたコンテナは、<要素RNG>にマップされます。
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>要素を「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にマッピングされます。型定義が展開されていない場合は、@nma：O：親から得られるパターン：デフォルトでは<定義RNG>の属性になり、この属性の配置は、型定義は、それが使用されている場合、拡張する必要があるかどうかによって異なります'typedefは' マッピング。
o Otherwise, @nma:default becomes an attribute of the ancestor RELAX NG pattern inside which the expansion takes place.
Oそれ以外の場合は、@nma：デフォルトでは、祖先の属性が拡張が行われる内部のNGパターンをRELAXになります。
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を使用する場合：「真」の値に暗黙的属性は、簡単な表記法のデフォルトケースを表すノードに取り付けられた、あるいは、余分されますか<RNG：グループ>要素を挿入してもよいと@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; } }
選択肢の葉{デフォルトのfeuille。リーフfeuille {タイプ空。 }リーフhoja {タイプ空。 }}
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：選択> <RNG：要素名= "山芋：feuille" NMA：暗黙的= "真"> <RNG：空/> </ RNG：要素> <RNG：要素名= "山芋：hoja"> <RNG ：空/> </ RNG：要素/> </ RNG：グループ>：選択>またはデフォルトの場合は、余分な<RNG内にラップすることができます。
<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>
<RNG：選択> <RNG：グループNMA：暗黙的= "真"> <RNG：要素名= "山芋：feuille"> <RNG：空/> </ RNG：要素> </ RNG：グループ> <RNG：要素名= "山芋：hoja"> <RNG：空/> </ RNG：要素/> </ RNG：選択>
This statement is mapped to the DTD compatibility element <a:documentation> and ARGUMENT becomes its text.
この文は、DTDの互換性の要素にマッピングされ、<：ドキュメント>と引数は、そのテキストになります。
In order to get properly formatted in the RELAX NG compact syntax, this element SHOULD be inserted as the first child of PARENT.
適切RELAX NGコンパクト構文でフォーマットを取得するためには、この要素は、親の最初の子として挿入されるべきである（SHOULD）。
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：値>要素、および引数は、そのテキストになります。 <：値RNG>要素6節、[RNG]を参照して、注釈要素を含めることはできませんので、「状態」を除くすべてのサブステートメントは無視されます。
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>にマッピングされます。セクション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>にマッピングされます。セクション10.35も参照してください。
This statement is ignored. However, extensions to the YANG language MAY be mapped as described in Section 9.4.
この文は無視されます。 9.4節で説明したようにしかし、YANG言語の拡張がマッピングされる場合があります。
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.
この文で定義されたグループは、改良することなく使用され、入力モジュールの少なくとも一方に増大されている場合にのみ、このステートメントは、RELAX NG <定義RNG>パターン定義名前にマッピングされます。この場合は、名前のパターン定義がの子になり、<RNG：文法>要素と、その名前は、セクション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：文法>対応するグループが入力YANGモジュールのトップレベルで定義されている場合は素子。
o otherwise as a child of the embedded <rng:grammar> element corresponding to the module in which the grouping is defined.
Oさもなければ埋め込ま<RNG：文法>の子としてグループが定義されているモジュールに対応する要素。
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.
実装は、出力での名前のパターン定義などの文は、彼らが参照されていない場合でも、RELAX 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>要素この文は、ルートの子として配置され、以下の命名パターン定義にマップされます。
<rng:define name="__PREFIX_ARGUMENT"> <rng:choice> <rng:value type="QName">PREFIX:ARGUMENT</rng:value> <rng:ref name="IDENTITY1"/> ... </rng:choice> </rng:define>
<RNG：定義名= "__ PREFIX_ARGUMENT"> <RNG：選択> <RNG：値のタイプ= "のQName"> PREFIX：引数</ RNG：値> <RNG：参照名= "IDENTITY1" /> ... </ RNG：選択> </ RNG：定義>
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.
IDENTITY1は、現在のIDから派生されるIDに対応する名前のパターンの名前です。正確に一つの<RNG：ref>要素は、すべて、このようなアイデンティティのために存在しなければなりません。
EXAMPLE ([RFC6020], Section 7.16.3). Consider the following identities defined in two input YANG modules:
実施例（[RFC6020]、セクション7.16.3）。 2つの入力YANGモジュールで定義されている次のアイデンティティを考えてみましょう。
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>
<名前を定義= "__ crypto_crypto-ALG"> <選択> <値型= "のQName">暗号：暗号-ALG </ value>の<refの名前= "__ des_des" /> <refの名前= "__ des_des3" /> </選択肢> </定義> <定義名= "__ des_des"> <値型= "のQName">デ：デ</ value>の</定義> <定義名= "__ des_des3"> <値型= "のQName">デ：DES3 </ value>の</定義>
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.
一緒にすべての兄弟「であれば、機能」ステートメントの引数を持つの引数（追加のプレフィックスと、行方不明場合）@nmaの値になるスペースで区切られたリストに集めなければなりません：IF-機能属性。この属性は、親に装着されています。
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：要素>にマップされているプリペンドローカル名前空間接頭辞を持つ要素とARGUMENTその@name属性の値になります。
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>で囲む必要がありますこれ（詳細は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.
それはデフォルトではゼロである（要素「MIN-要素のサプの引数はそれぞれ「0」または正であるかに応じて、<：zeroOrMore RNG>または<oneOrMore RNG>このステートメントは、いずれかで囲まれたブロックにマッピングされます）。この<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：要素>は、その後プリペンドローカル名前空間接頭辞を持つ親と引数の子要素として追加され、その@name属性の値になります。別の属性、@nma：「真」の値を持つ要素：リーフリストは、また、この<要素RNG>に追加する必要があります。 「リーフリスト」ステートメントは、「最小要素のサブステートメントを有し、その引数が1、追加の属性@nmaよりも大きい場合：<：要素RNG>と「MIN-要素」の引数になりMIN-要素に取り付けられています。この属性の値。そこに「最大-要素のサブステートメントであり、その引数の値が「無制限」でない場合は同様に、@nma属性：MAX-要素は、この属性の値となり、この要素と「MAX-要素」の引数に装着されています。
EXAMPLE. Consider the following 'leaf-list' appearing in a module with the namespace prefix "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フラグメントをRELAX：
<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>
<RNG：oneOrMore> <RNG：要素名= "山芋：葉" NMA：リーフリスト= "true" をNMA：注文したバイ= "ユーザー" NMA：MIN-要素= "3" NMA：最大要素=」 6378 "> <RNG：データタイプ=" 文字列 "/> </ RNG：要素> </ 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があることです。
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フラグメントをRELAX：
<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>
<RNG：zeroOrMore> <RNG：要素名= "山芋：FOO" NMA：キー= "山芋：音部記号"> <RNG：要素名= "山芋：音部記号"> <RNG：データタイプ= "なunsignedByte" /> < / RNG：要素> <RNG：インターリーブ> <RNG：要素名= "山芋：バー"> <RNG：データタイプ= "文字列" /> </ RNG：要素> <RNG：要素名= "山芋：バズ" > <RNG：データタイプ= "文字列" /> </ RNG：要素> </ RNG：インタリーブ> </ RNG：要素> </ RNG：zeroOrMore>
Note that the "keygrp" grouping is expanded and the definition of "yam:clef" is moved before the <rng:interleave> pattern.
<：インタリーブRNG>パターン：「音部記号山芋」の前に移動させ、「keygrp」グループが展開されているとの定義があることに注意してください。
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で」ステートメントのサブステートメントとして表示されることがあります。引数が「真」である場合は、親データノードが必須としてマッピングされ、第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>にマップされます。また、<RNG：文法> <DC source>要素は、本の子として作成されるべき要素と入力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>要素。
o statements representing the contents of RPC requests or replies are mapped to descendants of the <nma:rpcs> element;
RPC要求または応答の内容を表すO文は、子孫にマッピングされる<NMA：のRPC>要素。
o statements representing the contents of event notifications are mapped to descendants of the <nma:notifications> element.
<：通知NMA>エレメントイベント通知の内容を表すO文は、子孫にマッピングされます。
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>にマップされます。これは、有効なXPath式（9.3項を参照）に変換引数が含まれています（名前空間なしで）1つの必須属性@assertを持っています。 ：要素が「エラーアプリタグ」および「エラーメッセージ」サブステートメントをマッピングから生じる他のサブエレメントを有していてもよい。<NMAなければなりません>。 「必須」、すなわち、「説明」および「参照」の他のサブステートメントは、無視されます。
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:
「現在の（）<= ../max-lease-time」{エラーメッセージしなければならない「デフォルトリース時間は、max-リース時間未満でなければなりません」。 }にマッピングされます。
<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>
<NMA =アサートしなければならない "（現在）|≦.. / DHCP：MAX-リース時間"> <NMA：エラーメッセージを>デフォルトリース時間は、/ <MAX-リース時間未満でなければなりませんNMA：エラーメッセージ> </ NMA：必要があります>
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;
@xmlns 1.：PREFIXは兄弟「プレフィックス」ステートメントで指定された名前空間接頭辞です。<文法RNG>要素ルートのPREFIX属性。引数には、この属性の値になります。
2. to the @ns attribute of PARENT, which is an embedded <rng: grammar> pattern. ARGUMENT becomes the value of this attribute.
<：文法RNG>パターン埋め込み親の@ns属性2.。引数には、この属性の値になります。
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：通知>（プレフィックスがローカルYANGモジュールの接頭辞である）ハイブリッド・スキーマの要素：
<nma:notification> <rng:element name="PREFIX:ARGUMENT"> ... </rng:element> </nma:notification>
<NMA：通知> <RNG：要素名= "PREFIX：ARGUMENT"> ... </ RNG：要素> </ NMA：通知>
Substatements of 'notification' are mapped under <rng:element name="PREFIX:ARGUMENT">.
<：要素名= "PREFIX：ARGUMENT" RNG> '通知' のサブステートメントは、下マッピングされています。
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モジュールからマップすることができるので、この文はマッピングによって無視されます。セクション10.34を参照して、<ソースDC>要素ハイブリッドスキーマはダブリンコア内のすべての入力モジュールへの参照を含むべきです。
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>でラップする必要があります。また、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: ".
要素とそのテキストは「を参照してください：」で始まるARGUMENTに設定されている。この文は、<ドキュメント>にマップされます。
This statement is handled within "instance-identifier" type (Section 10.53.7).
この文は、「インスタンス識別子」タイプ（セクション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]の現在のリビジョンを指定する引数で最新の日付と1の唯一の最新のインスタンスを使用しています。この形で、例えば：<DC電源>要素（セクション10.34を参照）、この日付は、対応するダブリンコアに、一緒にYANGモジュールの名前で、記録されるべきです。
<dc:source>YANG module 'foo', revision 2010-03-02</dc:source>
<DC：ソース> YANGモジュール 'foo' で、リビジョン2010-03-02 </ DC：ソース>
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):
このステートメントは、（PREFIXは、ローカルYANGモジュールのプレフィックスです）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>
<NMA：RPC> <NMA：入力> <RNG：要素名= "PREFIX：ARGUMENT"> ... '入力' のマップされたコンテンツ... </ RNG：要素> </ NMA：入力> <NMA：出力「> ... '出力' のマップされた内容... </ NMA：出力> </ 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.
<：要素名=「PREFIX：ARGUMENT」RNG>スキーマ断片に示されるように、「入力」サプ（もしあれば）の内容は下にマッピングされます。同様に、「出力」サプの内容は、<：出力NMA>の下にマッピングされます。 NO「出力」サブステートメントが存在しない場合は、<NMA：出力>要素が存在してはなりません。
The <nma:rpc> element is a child of <nma:rpcs>.
<NMA：RPC>要素は、<：RPCのNMA>の子です。
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.
最もYANGは、組み込みデータ型を表4に示すように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：YANGは、組み込みデータ型W3C XML Schemaのタイプライブラリで同等で
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データ型ライブラリの二つの重要なデータ型 - の「dateTime」と「anyURIの」 - YANGで種類内蔵されていないが、代わりに標準モジュール[RFC6021]で派生型として定義されています：「日時IETF-ヤン・タイプ 『モジュールと『URI」の』IETF-INET-タイプ『モジュール』で』。しかし、YANG型定義での正式な制限はかなり弱いです。したがって、YANGツー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>にマップされます。
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>
<RNG：選択> <RNG：値>真</ RNG：値> <RNG：値>偽</ RNG：値> </ RNG：選択>
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".
「真」のための「偽」で0と1：それができるため、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の」に設定されている（表4参照）。<RNGデータ>要素。
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：リスト>各「ビット」のための子として挿入され、次のXMLフラグメントをサプ<RNG：リスト>
<rng:optional> <rng:value>bit_name</rng:value> </rng:optional>
<RNG：オプション> <RNG：値> bit_name </ RNG：値> </ RNG：オプション>
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>要素これらのタイプはにマッピングされます。
This type is mapped to the following named pattern reference:
このタイプは、次の名前付きパターンの参照にマップされます。
<rng:ref name="__PREFIX_BASE"/>
<RNG：REF名= "__ PREFIX_BASE" />
where PREFIX:BASE is the qualified name of the identity appearing in the argument of the 'base' substatement.
どこPREFIX：BASEは、「基本」サブステートメントの引数に登場するアイデンティティの修飾名です。
For example, assume that module "des" in Section 10.21 contains the following leaf definition:
例えば、セクション10.21で「デ」というモジュールを前提とし、以下の葉の定義が含まれています。
leaf foo { type identityref { base crypto:crypto-alg; } }
リーフFOO {型identityref {ベース暗号：暗号ALG。 }}
This leaf would then be mapped to the following element pattern:
この葉は、次の要素パターンにマッピングされます。
<element name="des:foo"> <ref name="__crypto_crypto-alg"/> </element>
<要素名= "DES：FOO"> <refの名前= "__ crypto_crypto-ALG" /> </要素>
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属性を持つ：<データRNG>要素このタイプにマップされます。また、空の<NMA：インスタンス識別子>要素は、親の子として挿入されなければなりません。
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>要素が存在する場合は、「必要-インスタンス」をサブステートメントの引数は、、の@必要-インスタンス属性の値になります。
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に従って変換ARGUMENTに設定@type属性を持つ要素：彼らは、<データRNG>にマッピングされます。
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」タイプです。 19の値に設定された「totalDigits」ファセット（O）その精度と小数点以下の桁数は常に存在していなければなりません以下のファセット、により制御されます。
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; }
型decimal64 {フラクション桁2。 }
is mapped to the following RELAX NG data type:
次のRELAX NGデータ型にマップされます。
<rng:data type="decimal"> <rng:param name="totalDigits">19</rng:param> <rng:param name="fractionDigits">2</rng:param> </rng:data>
<RNG：データタイプ= "進"> <RNG：PARAM名= "Totldigits"> 19 </ RNG：アルティメット> <RNG：PARAM NAME = "Farchtiondigits"> 2 </ RNG：アルティメット> </ RNG：データ>
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:
範囲の表現は、1つだけの範囲LO..HIで構成されている場合、それはデータ型ファセットの対にマッピングされます。
<rng:param name="minInclusive">LO</rng:param>
<RNG：PARAM名= "Minitrchlusive"> </ RNG：アルティメット>取ります
and
そして
<rng:param name="maxInclusive">HI</rng:param>
<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は、文字列「分」に等しい場合、「のminInclusive」ファセットを省略しています。 HIは、文字列「最大」に等しい場合、「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：データ>要素は、すべての範囲の一部に一回繰り返されなければならないし、そのようなすべての要素<RNG：データは>要素は、<選択肢RNG>に包まれています。それぞれ：前の段落で説明したように、<RNGデータ>要素は、範囲式の一部は、「のminInclusive」および「maxInclusiveを」ファセットを含んでいます。
For the "decimal64" type, the "totalDigits" and "fractionDigits" must be repeated inside each of the <rng:data> elements.
<：データRNG>要素「decimal64」タイプの場合、「totalDigits」および「fractionDigits」との各内部繰り返さなければなりません。
For example,
例えば、
type int32 { range "-6378..0|42|100..max"; }
型INT32 {範囲 "-6378..0 | 42 | 100..max"。 }
is mapped to the following RELAX NG fragment:
NG断片をRELAX以下にマッピングされます。
<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>
<RNG：選択> <RNG：データタイプ= "INT"> <RNG：PARAM名= "Minitrchlusive"> - 6378 </ RNG：アルティメット> <RNG：PARAM NAME = "Mkshitrchlusive"> 0 </ RNG：アルティメット> </ RNG：データ> <RNG：データタイプ= "INT"> <RNG：PARAM名= "Minitrchlusive"> 42 </ RNG：究極> <RNG：PARAM名= "Mkshitrchlusive"> 42 </ RNG：究極> </ RNG：データ> <RNG：データタイプ= "INT"> <RNG：PARAM名= "Minitrchlusive"> 100 </ RNG：究極> </ RNG：データ> </ RNG：選択>
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>にマップされます。
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:
長さの表現は、単に1つの範囲を持っている場合：
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 </ 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:
長さの範囲、すなわちフォームLO..HI、である場合、O、それは両方の下限と上限から成ります。次の二つのデータ型ファセットは、次に挿入されます。
<rng:param name="minLength">LO</rng:param>
<RNG：PARAM名= "Minlaedagth"> </ RNG：アルティメット>取ります
and
そして
<rng:param name="maxLength">HI</rng:param>
<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は、文字列「分」に等しい場合、「はminLength」ファセットを省略しています。 HIは、文字列「最大」に等しい場合、「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：データ>要素は、すべての範囲の一部に一回繰り返されなければならないし、そのようなすべての要素<RNG：データは>要素は、<選択肢RNG>に包まれています。各<RNG：data>要素は、「長さ」または「はminLength」と前の段落で説明したように長さの表現の一部は、「maxLengthの」ファセットを含んでいます。
Every 'pattern' restriction of the "string" data type is mapped to the "pattern" facet:
「文字列」データ型のすべての「パターン」制限を「パターン」のファセットにマップされます。
<rng:param name="pattern">...</rng:param>
<RNG：PARAM名= "パターン"> ... </ RNG：アルティメット>
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>要素、すなわち、全てのそのような「パターン」ファセットの各コピーの内部に繰り返されなければなりません。
For example,
例えば、
type string {
length "1|3..8";
pattern "[A-Z][a-z]*";
}
is mapped to the following RELAX NG fragment:
NG断片をRELAX以下にマッピングされます。
<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>
<RNG：選択> <RNG：データタイプ= "文字列"> <RNG：PARAM名= "長さ"> 1 </ RNG：究極> <RNG：PARAM名= "パターン"> [AZ] [アッシュ] * < / RNG：究極> </ RNG：データ> <RNG：データタイプ= "文字列"> <RNG：PARAM名= "Minlaedagth"> 3 </ RNG：究極> <RNG：= "Mcshlaedagth" PARAM名> 8 < / RNG：究極> <RNG：PARAM名= "パターン"> [AZ] [アッシュ</ RNG：究極> </ RNG：データ> </ RNG：選択>
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.
1.制限がなければ、「タイプ」の文は、単に<RNG：REF>にマップされている要素、すなわち、名前のパターンを参照します。セクション10.54を参照して、エレメント：この命名パターンのRELAX NG定義がまだハイブリッド・スキーマに追加されていない場合、対応するタイプ定義が見つけなければならないし、そのマッピングは、ルートまたは埋め込みのいずれかのサブ要素としてインストール<文法RNG> 。所与の派生型が入力YANGモジュールにおいて複数回使用された場合でも、対応「のtypedef」のマッピングは一度だけインストールする必要があります。
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データ>要素。
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.
この文は、RELAX NGという名前のパターン定義<RNG：定義>にマップされますが、場合にのみ、この文で定義されたタイプは、入力モジュールの少なくとも一つに制限なく使用されます。 「typedefは」ステートメントは、YANGモジュールのトップレベルで表示されるかどうかに応じて、<文法RNG>要素、この場合は、名前のパターン定義は、ルートまたは埋め込まれたいずれかの子になります。この名前のパターン定義の名前は、セクション9.2で指定されたルールに従って台無しARGUMENTに設定されています。
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.
実装は、それらが参照されていない場合でも、RELAX 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"
ユニークな「フー・EX：バー/バズ」
is mapped to the following attribute/value pair:
次の属性/値のペアにマップされます。
nma:unique="ex:foo ex:bar/ex:baz"
NMA：ユニーク= "例：FOO例：バー/ EX：バズ"
This statement is mapped to the @nma:units attribute and ARGUMENT becomes its value.
このステートメントは@nmaにマップされます。単位は属性と引数がその値になります。
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節。参照命名パターンのRELAX NG定義がまだハイブリッド・スキーマに追加されていない場合、対応するグループが見出され、そのマッピングは、サブ要素としてインストールする必要があり、<RNG：文法>セクション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）によって宣言YANGバージョンと互換性があることを確認する必要があります。不一致の場合には、実装がエラーを報告して終了すべきです。
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ツーDSDLマッピングの第二段階は、ハイブリッド・スキーマを取り、インスタンスXML文書を検証することが可能な様々なDSDLスキーマに変換します。入力パラメータとして、このステップは、最も簡単な場合には、検証すべきであるNETCONF XMLドキュメントタイプの仕様だけをとります。その上、他のRPC要求/返信やイベント通知の内容、および<：：取得NC>または<取得・設定NC>これらのドキュメントタイプは、への応答、例えば、データストアの内容をすることができます。
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.要求されたドキュメントのタイプに適したハイブリッドスキーマの部分を抽出します。たとえば、<：データNMA>選択しなければならない<NC取得>返事は、下のサブツリーを検証することです。
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.
前記スキーマは、RPC層によって義務付け特定封入XML要素に適合させなければなりません。これらは、例えば、<NC：RPC>と<NC：データ>の場合の要素<NC：取得>：通知または<通知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マイナーな例外を除いて、ハイブリッドスキーマからRELAX NGスキーマの検証を得ることが唯一のハイブリッドスキーマの適切な部分を取り、新しいRELAX 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.
結果として生じる構造RELAX NGスキーマは、ハイブリッド・スキーマと同様である：ルート文法は、埋め込まれた文法、各入力YANGモジュールのいずれかを含んでいます。しかし、としては、8.2節で説明した、グローバルな名前のパターン定義（ルート<RNG：文法>の子要素）が別のスキーマファイルに移動する必要があります。
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>として、検証の対象となるXML文書のタイプに応じて返信、RPC操作または通知、対応する最上位レベルの情報項目を定義するパターンのような、追加しなければなりません< NC：RPC-返信> @メッセージ-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.
RELAX NGファイルを共通NETCONF要素に対する共通の命名パターンの定義をコピー避け、一つ一つの出力に属性をするためには、そのようなスキーマに依存しない定義は、その後、RELAX NGスキーマを検証することにより、含まれているライブラリファイルに収集することができるべきです。付録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.
設定、ターゲット文書タイプは<NCます。get-config>のへの返信である場合に観察する必要があります。上記のマイナーな例外は、注釈@nmaです。この場合には、「偽」の値でこの属性を持つ各要素の定義は、その子孫と一緒にスキーマから除去されなければなりません。詳細は、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>.
Schematronのスキーマは、RELAX NGのために比較してはるかに平坦でより均一になる傾向があります。 、および<SCH：スキーマ>、<SCH：パターン>、<ルールSCH>彼らは正確に4つのXML階層のレベルを持っている<SCH：主張>または<SCH：レポート>。
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のマッピングステップにより生成されたSchematronのスキーマに、組織の基本単位は<規則SCH>で表されるルールです。 （以後 "セマンティック注釈" と呼ばれる）ハイブリッドスキーマから次NETMOD固有のアノテーションは、Schematronのルールに対応するマッピングされます。<NMA：必要>：キー、@nma：ユニーク、@nma：MAX-要素、@nma、@nma ：最小要素、@nma：、@nma：leafref、@nma：リーフリスト、およびまた@nma：必須の<RNG：選択>の属性として登場する（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属性モジュール名に設定されているSchematronのパターンにマッピングされます。すべての<RNG：要素は>上記セマンティック注釈の少なくとも1つを含むパターンは、その後のSchematronルールにマッピングされます。
<sch:rule context="XELEM"> ... </sch:rule>
<SCH：ルールコンテキスト= "XELEM"> ... </ SCH：ルール>
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：ルール>の必須@Context属性の値（XELEMとして示される）は、データツリー内のコンテキスト要素の絶対パスを設定しなければなりません。 <SCH：ルール>要素のすべてのマッピングが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：定義>有するその祖先のうちの）それらは潜在的に異なる状況で使用することができるので、特別な処理を必要とします。これは、ローカルの名前空間接頭辞の代わりに「$県」変数を使用したSchematron抽象的なパターンを使用することによって達成されます。そのような抽象パターンの@id属性の値がマッピングされているという名前のパターン定義の名前に設定されなければならない（すなわち、元のYANGグルーピングのマングルされた名前）。
When the abstract pattern is instantiated, the values of the following two parameters MUST be provided:
抽象パターンがインスタンス化されるときには、次の2つのパラメータの値を提供しなければなりません。
o pref: the actual namespace prefix,
O県：実際の名前空間接頭辞、
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:
応答のための結果のSchematronスキーマ：次のように<NC GET>は次のようになります。
<?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>
<？xml version = "1.0" エンコード= "UTF-8"？> <SCH：スキーマのxmlns：SCH = "http://purl.oclc.org/dsdl/schematron"> <SCH：NS URI = "のhttp： //example.com/ns/example4" プレフィックス= "EX4" /> <SCH：NS URI = "壷：IETF：のparams：XML：NS：NETCONF：ベース：1.0" プレフィックス= "NC" /> <SCH：パターン抽象的な= "true" をID = "_ example4__sorted葉-リスト"> <SCH：ルールコンテキスト= "$スタート/ $県：ソート・エントリ"> <SCH：レポートテスト=」=先行兄弟:: $県。 ：ソート・エントリ「>重複リーフリストエントリ 『<SCH：』。」価値の選択= />」。 </ SCH：レポート> <SCH：断言テスト= "ではない（先行兄弟:: $県：ソートエントリー＆GT;）">エントリは昇順に現れなければなりません。 </ SCH：アサート> </ SCH：ルール> </ SCH：パターン> <SCH：パターンID = "example4" /> <SCH：パターンID = "id2573371" とは、A = "_ example4__sorted葉リスト"> <SCH：PARAM名= "開始" 値= "/ NC：RPC返信/ NC：データ" /> <SCH：PARAM NAME = "県" 値= "EX4" /> </ SCH：パターン> </ SCH ：スキーマ>
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葉リスト」の@id値抽象パターンにマッピングされ、<SCH：アサート>要素。抽象パターンは「開始」との値を適切にする「県」パラメータを設定する「id2573371」の@id値のパターンによってインスタンス化されます。
Note that another Schematron element, <sch:report>, was automatically added, checking for duplicate leaf-list entries.
重複リーフリストのエントリをチェックし、自動的に追加されました：別のSchematron要素は、<レポートSCH>ことに注意してください。
The mapping from the hybrid schema to Schematron proceeds in the following steps:
Schematronのにハイブリッド・スキーマのマッピングは、以下のステップに進みます。
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.
まず、ハイブリッド・スキーマのアクティブサブツリー（複数可）が要求されたターゲット文書の種類に応じて選択されなければなりません。設定をターゲット文書の種類がある場合は、<NC：取得-config>の回答が@nmaの取り扱いを含め、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:
例えば、<NS SCH>要素と共にベースNETCONF（「NC」接頭辞）または通知（「EN」接頭辞）の名前空間を持つすべての入力YANGモジュールの2ネームスペースは、使用して宣言しなければなりません。
<sch:ns uri="http://example.com/ns/example4" prefix="ex4"/>
<SCH：NS URI = "http://example.com/ns/example4" プレフィックス= "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つまたは複数の意味的な注釈を含むすべての名前のパターン定義のために作成されます。
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.
<：ルールSCH>要素<：アサートSCH>または子としてインストールされている<SCHレポート>要素、5あらゆるそのような注釈は、その後にマッピングされます。
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.
完全にYANGのチョイス 'ステートメントのセマンティクスを表現するために、「必須真;」サブステートメントは、RELAX NGの文法は、特別なSchematronのルールと組み合わせる必要があります。
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:
このモジュールでは、両方のケースブランチ内のすべての3つのリーフノードはオプションですが、理由の「必須真;」声明は、それらの少なくとも1つは、有効な構成に存在しなければなりません。このモジュールからのチョイス 'ステートメントは、RELAX NGスキーマの以下のフラグメントにマップされます。
<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>
<RNG：選択> <RNG：インターリーブ> <RNG：オプション> <RNG：要素名= "EX5：foo1の"> <RNG：データタイプ= "なunsignedByte" /> </ RNG：要素> </ RNG：オプション> <RNG：オプション> <RNG：要素名= "EX5：foo2は"> <RNG：データタイプ= "なunsignedByte" /> </ RNG：要素> </ RNG：オプション> </ RNG：インターリーブ> <RNG：要素名前= "EX5：バー"> <RNG：データタイプ= "なunsignedByte" /> </ RNG：要素> </ RNG：選択>
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.
第二の場合のブランチでは、この分岐が選択されている場合、この要素が有効な構成で存在しなければならないように「EX5バー」要素は必須として定義されます。それらのそれぞれが単独の有効な構成で十分しかし、最初の分岐「foo」という2つの要素の両方が必須として宣言することはできません。その結果、上記RELAX 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：選択> @nma持つ要素：必須の注釈、特別な方法で処理しなければならない：ケースの少なくとも一方が複数を含む各必須の選択のため一方のノードより、Schematronのルールは、症例のいずれかからの少なくとも一つの元素の存在を強制添加しなければなりません。 （RELAX NGスキーマの異なるケースの要素等、すべての必須のノードが存在することを、一緒に混合することができないことを保証します）。
For the example module above, the Schematron rule will be as follows:
次のように上記の例のモジュールのために、Schematronのルールは次のようになります。
<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>
選択した少なくとも一つのケースからノード（S）<SCH：ルールコンテキスト= "/ NC：RPC返信/ NC：データ"> <SCH：アサートテスト= "バーEX5：foo1の又はEX5：foo2はまたはEX5"> 「foobarに」存在している必要があります。 </ SCH：アサート> </ SCH：ルール>
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ツー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>要素、DSRLでは、要素のデフォルトの内容は、使用して指定されています。二つの兄弟要素<DSRL：デフォルト・コンテンツ>デフォルトのコンテンツのアプリケーションのコンテキストを決定する、[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;
0 <DSRL：親>要素は、親要素を指定するXSLTのパターンを含みます。デフォルトの内容は、親要素がインスタンス文書内に存在する場合にのみ適用されます。
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> <DSRL名>が見つからないか、空の場合は、内容と一緒に挿入された要素の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：親>要素は、YANGツーDSDLマッピングの目的のために、この要素はデフォルトの内容の適切な適用を保証するために、常に存在していなければならない、一般DSRLスキーマにオプションですが。
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:
（9.1.2項参照）暗黙のノードを定義するハイブリッドスキーマに<要素RNG>パターンDSRLマッピングのみを扱います。いずれか、暗黙の、すなわちデフォルトまたは@nma：そのような要素のパターンはNETMOD固有の注釈が@nma属性有することによって区別されます。
<rng:element name="ELEM" nma:default="DEFVALUE"> ... </rng:element>
<RNG：要素名= "ELEM" NMA：デフォルト= "DEFVALUE"> ... </ RNG：要素>
or
または
<rng:element name="ELEM" nma:implicit="true"> ... </rng:element>
<RNG：要素名= "ELEM" NMA：暗黙的= "真"> ... </ RNG：要素>
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.
デフォルト注釈：@nmaように、このタイプ定義は、9.2.2項の規則に従って展開されている場合に前者の場合は、「デフォルト」サプを有するリーフノードにだけでなく、タイプ定義のデフォルト値を取得するリーフノードに適用します葉の素子パターンに直接取り付けられています。
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>
<DSRL：要素マップ> <DSRL：親> XPARENT </ DSRL：親> <DSRL：名> ELEM </ DSRL：名> <DSRL：デフォルト・コンテンツ> DEFCONT </ DSRL：デフォルト・コンテンツ> </ DSRL ：要素マップ>
where XPARENT is the absolute XPath of ELEM's parent element in the data tree and DEFCONT is constructed as follows:
どこXPARENTは、データツリーでELEMの親要素の絶対XPathがあると、次のようにDEFCONTが構成されています：
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).
暗黙ノードELEMが葉であり@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.
暗黙のノードELEMが葉であると@nmaている場合○：「真」の値を持つ暗黙の属性を、デフォルト値は@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それ以外の場合は、暗黙のノードELEMはコンテナであり、DEFCONTはいずれか@nma有するELEMのすべての子孫要素を含むXMLフラグメントとして構成されている：暗黙的または@nma：デフォルト属性。
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>を設定することによって達成されます。
<dsrl:parent>XPARENT[not (ELEM1|ELEM2|...|ELEMn)]</dsrl:parent>
<DSRL：親> XPARENT [ない（ELEM1 |のElem2 | ... | ELEMn）] </ DSRL：親>
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:
「get-返信」用に生成DSRLスキーマは、対象文書の種類は次のようになります。
<?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>
<？xml version = "1.0" エンコード= "UTF-8"？> <DSRL：マップのxmlns：DSRL = "http://purl.oclc.org/dsdl/dsrl" のxmlns：EX6 = "のhttp：//例.COM / NS / example6" のxmlns：NC = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0"> <DSRL：要素マップ> <DSRL：親> / NC：RPC返信/ NC：データ</ DSRL：親> <DSRL：名> EX6：アウター</ DSRL：名> <DSRL：デフォルト・コンテンツ> <EX6：leaf1> 1 </ EX6：leaf1> <EX6：1> <EX6：leaf2> 2 </ EX6：leaf2> </ EX6一> </ DSRL：デフォルト・コンテンツ> </ DSRL：要素マップ> <DSRL：要素マップ> <DSRL：親> / NC：RPC返信/ NC：データ/ EX6：アウター</ DSRL：親> <DSRL：名> EX6：leaf1 </ DSRL：名> <DSRL：デフォルト-内容> 1 </ DSRL：デフォルト・コンテンツ> </ DSRL：要素マップ> < DSRL：要素マップ> <DSRL：親> / NC：RPC返信/ NC：データ/ EX6：外側[しない（EX6：leaf3）</ DSRL：親> <DSRL：名> EX6一</ DSRL ：名> <DSRL：デフォルト・コンテンツ> <EX6：leaf2> 2 </ EX6：leaf2> </ DSRL：デフォルト・コンテンツ> </ DSRL：要素マップ> <DSRL：要素マップ> <DSRL：親> / NC：RPC-返信/ NC：データ/ EX6：アウター/ EX6：1 </ DSRL：親> <DSRL：名> EX6：leaf2 </ DSRL：名> <DSRL：デフォルト-コンテンツ> 2 </ DSRL：デフォルト・コンテンツ> </ DSRL：要素マップ> </ DSRL：マップ>
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:
回答：この注釈は「偽」の値を持つ存在する場合は、次の規則が、<取得・設定NC>のDSDLスキーマのために認められなければなりません：
o When generating RELAX NG, the contents of the CONTELEM definition MUST be changed to <rng:notAllowed>.
<：のnotAllowed RNG> RELAX NGを生成する場合、O、CONTELEM定義の内容に変更しなければなりません。
o When generating Schematron or DSRL, the CONTELEM definition and all its descendants in the hybrid schema MUST be ignored.
Schematronの又はDSRLを生成する場合、O、ハイブリッドスキーマのCONTELEM定義とそのすべての子孫は無視しなければなりません。
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：しなければならない>、セクション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>.
<：のnotAllowed RNG> RELAX NGを生成する場合、O、CONTELEM定義の内容に変更しなければなりません。
o When generating Schematron or DSRL, the CONTELEM definition and all its descendants in the hybrid schema MUST be ignored.
Schematronの又はDSRLを生成する場合、O、ハイブリッドスキーマのCONTELEM定義とそのすべての子孫は無視しなければなりません。
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:
この注釈要素が「偽」の値を持つ@必要-インスタンスの属性を持っている場合、それは無視されます。それ以外の場合は、以下のSchematronアサートにマップされます。
<sch:assert test="nmf:evaluate(.)"> The element pointed to by "CONTELEM" must exist. </sch:assert>
<SCH：テスト= "（。）NMF評価" をアサート>要素が存在しなければならない "CONTELEM" によって指し示さ。 </ SCH：主張>
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：評価（）関数は、実行時にXPath式を評価し、XSLT拡張機能（[XSLT]で拡張関数を参照）です。そのような拡張機能が拡張XSLT（EXSLT）で入手可能であるか、または例えば、いくつかのXSLTプロセッサによって独自拡張、サクソンとして提供します。
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」、すなわち、リストのキーとしてCONTELEMのn個の子を指定します。注釈は、次のSchematronレポートにマップされます。
<sch:report test="CONDITION"> Duplicate key of list "CONTELEM" </sch:report>
<SCH：レポートテスト= "CONDITION">リストの重複キー "CONTELEM" </ SCH：レポート>
where CONDITION has this form: preceding-sibling::CONTELEM[C_1 and C_2 and ... and C_n]
先行兄弟:: CONTELEM [C_1とC_2と...と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ためC_I、...、N、即ち、キーK_Iの違反一意性の条件を指定します
k_i=current()/k_i
K_I =現在の（）/ K_I
This annotation is mapped to the following Schematron rule, which detects duplicate entries of a leaf-list:
この注釈は、リーフ・リストの重複したエントリを検出し、次のSchematronルールにマップされます。
<sch:report test=". = preceding-sibling::PREFIX:sorted-entry"> Duplicate leaf-list entry "<sch:value-of select="."/>". </sch:report>
<SCH：レポートテスト= "=先行兄弟:: PREFIX：ソートエントリ ">重複リーフリストエントリ "<SCH：価値の選択="。"/>"。 </ SCH：レポート>
See Section 11.2 for a complete example.
完全な例については、セクション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>
<SCH：テストをアサート= "PATH =。">リーフ "PATH" leafref値 "VALUE" には存在しない</ SCH：アサート>
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.
PATHは@nmaの値である：leafrefとVALUEをいう葉が存在しないため、インスタンス文書内のコンテキスト要素の値です。
This annotation is mapped to the following Schematron assert:
この注釈は、次のSchematronアサートにマップされます。
<sch:assert test="count(../CONTELEM)>=MIN"> List "CONTELEM" - item count must be at least MIN </sch:assert>
<SCH：テスト= "カウント（../ CONTELEM）＆GT; = MIN" アサート>リスト "CONTELEMを" - アイテム数が少なくともMINでなければならない</ SCH：アサート>
where MIN is the value of @nma:min-elements.
最小要素：MINは@nmaの値です。
This annotation is mapped to the following Schematron assert:
この注釈は、次のSchematronアサートにマップされます。
<sch:assert test="count(../CONTELEM)<=MAX or preceding-sibling::../CONTELEM"> Number of list items must be at most MAX </sch:assert>
<SCH：テスト=アサート "カウント（../ CONTELEM）|≦MAXまたは先行の兄弟:: ../ CONTELEM">リスト項目の数でなければならないが、ほとんどのMAX </ SCH：アサート>
where MAX is the value of @nma:min-elements.
最小要素：MAXは@nmaの値です。
This annotation is mapped to the following Schematron assert:
この注釈は、次のSchematronアサートにマップされます。
<sch:assert test="EXPRESSION"> MESSAGE </sch:assert>
<SCH：断言テスト= "EXPRESSION"> MESSAGE </ SCH：主張>
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".
EXPRESSIONは必須@assert属性の値である。ここで、<NMA：必要があります>。 <NMA：エラーメッセージ>場合はサブ要素が存在し、メッセージがその内容に設定されています。それ以外の場合は、デフォルトのメッセージ「条件式が真でなければならない」に設定されています。
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項を参照してください：
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.
@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：レポート>のテキストとして表示されるメッセージが異なります。「リストCONTELEM用に違反ユニークさ」。
This annotation is mapped to the following Schematron assert:
この注釈は、次のSchematronアサートにマップされます。
<sch:assert test="EXPRESSION"> Node "CONTELEM" is only valid when "EXPRESSION" is true. </sch:assert>
<SCH：テスト= "EXPRESSION" 主張>ノード "CONTELEMを" "EXPRESSION" がtrueの場合にのみ有効です。 </ SCH：主張>
where EXPRESSION is the value of @nma:when.
EXPRESSIONは@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.
この文書では、DSDLスキーマの協調セットにYANG言語で表現されたデータモデルをマップする手順を定義します。手順自体は、インターネット上ではセキュリティへの影響はありません。
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サーバとクライアントの実装によって実行される上記追加の妥当性チェックを提供します。この検証の厳密直接YANGが検証XMLデータに付着することモジュール源に由来します。
The following people contributed significantly to the initial version of this document:
次の人は、このドキュメントの初期のバージョンに大きく貢献しました：
o Rohan Mahy
Oロハンマーイ
o Sharon Chisholm (Ciena)
お しゃろん ちしょｌｍ （しえな）
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.
アンディBierman、マーティンBjorklund、Jirka Kosek、ユルゲンSchoenwaelder、そしてフィル・シェーファー：編集者は、このドキュメントのさまざまなバージョンに役立つ情報および/またはコメントを提供し、以下の個人に感謝したいです。
[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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]エンス、R.、 "NETCONF構成プロトコル"、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.、エド、 "YANG - ネットワーク構成プロトコルのためのデータモデリング言語（NETCONF）"、RFC 6020、2010年10月。
[RFC6021] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6021, October 2010.
[RFC6021] Schoenwaelder、J.、エド。、 "共通YANGデータ型"、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：レギュラー文法ベースの検証 - RELAX NGの第二版。。"、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：レギュラー文法ベースの検証 - RELAX NGのAMENDMENT 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.、エド。そして、M.村田、エド。、OASIS委員会仕様、2001年12月3日 "NG DTD互換性をRELAX"。
[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部：ルールベースの検証 - のSchematron"、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]ブレイ、T.、パオリ、J.、Sperberg-マックィーン、C.、MALER、E.、およびF. Yergeau、 "拡張マークアップ言語（XML）1.0（第5版）"、ワールドワイドウェブコンソーシアム推薦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]トービン、R.とJ.コーワン、 "XML情報セット（第二版）"、World Wide Web Consortium（W3C）の勧告REC-XML-インフォセット-20040204、2004年2月、<http://www.w3.org / TR / 2004 / REC-XML-インフォセット-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の]クラーク、J.とS. DeRose、 "XMLパス言語（XPath）バージョン1.0"、World Wide Web Consortium（W3C）の勧告REC-のxpath-19991116、1999年11月、<http://www.w3.org/TR/ 1999 / REC-のxpath-19991116>。
[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]ビロン、P.およびA.マルホトラ、 "XMLスキーマパート2：データ型第二版"、ワールドワイドウェブコンソーシアム勧告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]クラーク、J.、 "XSL変換（XSLT）バージョン1.0"、World Wide Web Consortium（W3C）の勧告REC-XSLT-19991116、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]ケース、J.、ヒョードル、M.、Schoffstall、M.、およびJ.デーヴィン、 "簡易ネットワーク管理プロトコル（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.、エド。、パーキンス、D.、編、及びJ. Schoenwaelder、編、STD 58、RFC 2578、1999年4月、 "管理情報バージョン2（SMIv2）の構造"。
[RFC5013] Kunze, J., "The Dublin Core Metadata Element Set", RFC 5013, August 2007.
[RFC5013]クンツェ、J.、 "ダブリンコアメタデータエレメントセット"、RFC 5013、2007年8月。
[RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event Notifications", RFC 5277, July 2008.
[RFC5277]チザム、S.およびH.トレビノ、 "NETCONFイベント通知"、RFC 5277、2008年7月。
[Trang] Clark, J., "Trang: Multiformat schema converter based on RELAX NG", 2008, <http://www.thaiopensource.com/relaxng/trang.html>.
[トラン]クラーク、J.、 "トラン：NGをRELAXに基づいて、マルチフォーマットのスキーマ変換器" 2008年、<http://www.thaiopensource.com/relaxng/trang.html>。
[Vli04] van der Vlist, E., "RELAX NG", O'Reilly, 2004.
[Vli04]ファンデVLIST、E.、オライリー、2004年 "NGをRELAX"。
[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]トンプソン、H.、ブナ、D.、マロニー、M.、およびN.メンデルゾーン、 "XMLスキーマパート1：構造第二版"、World Wide Web Consortium（W3C）の勧告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.およびL. Lhotka、 "pyang：Pythonで拡張可能YANGバリデータとコンバータ"、2010年<http://code.google.com/p/pyang/>。
Appendix A. RELAX NG Schema for NETMOD-Specific Annotations
付録A. NETMOD固有のアノテーションのためにNGスキーマをRELAX
This appendix defines the content model for all NETMOD-specific annotations in the form of RELAX NG named pattern definitions.
この付録では、RELAX NGという名前のパターン定義のフォーム内のすべてのNETMOD固有のアノテーションのコンテンツモデルを定義します。
<CODE BEGINS> file "nmannot.rng"
ファイル "nmannot.rng" <CODEが開始されます>
<?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">
<文法のxmlns = "http://relaxng.org/ns/structure/1.0" のxmlns <xmlのバージョン= "1.0" エンコード= "UTF-8"？>：NMA = "壷：IETF：のparams：XML：NS ：netmod：DSDL-注釈：1" datatypeLibrary = "http://www.w3.org/2001/XMLSchema-datatypes">
<define name="config-attribute"> <attribute name="nma:config"> <data type="boolean"/> </attribute> </define>
<定義名= "設定属性"> <属性名= "NMAます。config"> <データタイプ= "ブール" /> </属性> </定義>
<define name="data-element"> <element name="nma:data"> <ref name="__anyxml__"/> </element> </define>
<定義名= "データ要素"> <要素名= "NMA：データ"> <refの名前= "__ __ AnyXMLで" /> </要素> </定義>
<define name="default-attribute"> <attribute name="nma:default"> <data type="string"/> </attribute> </define>
<定義名= "デフォルト属性"> <属性名= "NMA：デフォルト"> <データタイプ= "文字列" /> </属性> </定義>
<define name="error-app-tag-element"> <element name="nma:error-app-tag"> <text/> </element> </define>
<=「エラーアプリタグ要素を」名前を定義> <要素名=「NMA：エラーアプリタグ」> <テキスト/> </要素> </定義>
<define name="error-message-element"> <element name="nma:error-message"> <text/> </element> </define>
<定義名= "エラーメッセージ要素"> <要素名= "NMA：エラーメッセージ"> <テキスト/> </要素> </定義>
<define name="if-feature-attribute"> <attribute name="nma:if-feature"> <list> <data type="QName"/> </list> </attribute> </define>
<定義名= "IF-機能属性"> <属性名= "NMA：IF-機能"> <リスト> <データタイプ= "QNameの" /> </リスト> </属性> </定義>
<define name="implicit-attribute"> <attribute name="nma:implicit"> <data type="boolean"/> </attribute> </define>
<データタイプ= "ブール" /> </属性> </定義>：<名前= "暗黙のNMAを" 属性> <名前= "暗黙の属性" を定義>
<define name="instance-identifier-element"> <element name="nma:instance-identifier"> <optional> <attribute name="nma:require-instance"> <data type="boolean"/> </attribute> </optional> </element> </define>
<データタイプ=「ブール」/> </ <オプション> <「必要インスタンスNMA」名=属性>：<要素名=「インスタンス識別子NMA」> <名前=「インスタンス識別子要素」を定義>属性> </オプション> </要素> </定義>
<define name="key-attribute"> <attribute name="nma:key"> <list> <data type="QName"/> </list> </attribute> </define>
<定義名= "キー属性"> <属性名= "NMA：キー"> <リスト> <データタイプ= "QNameの" /> </リスト> </属性> </定義>
<define name="leaf-list-attribute"> <attribute name="nma:leaf-list"> <data type="boolean"/> </attribute> </define>
<= "リーフリスト属性を" 名前を定義します> <名前=属性 "NMA：リーフリスト"> <データタイプ= "ブール" /> </属性> </定義>
<define name="leafref-attribute"> <attribute name="nma:leafref"> <data type="string"/> </attribute> </define>
<属性名= "NMA：leafref"> <名前= "leafref属性" を定義> <データタイプ= "文字列" /> </属性> </定義>を
<define name="mandatory-attribute"> <attribute name="nma:mandatory"> <data type="Name"/> </attribute> </define>
<データタイプ= "名前" /> </属性> </定義>：<名前= "必須NMAの" 属性> <名前= "必須属性" を定義>
<define name="max-elements-attribute"> <attribute name="nma:max-elements"> <data type="nonNegativeInteger"/> </attribute> </define>
<データタイプ= "NonNegativeIntegerの" /> </属性> </定義>：<名前= "MAX-要素NMAの" 属性> <名前= "MAX-要素属性" を定義>
<define name="min-elements-attribute"> <attribute name="nma:min-elements"> <data type="nonNegativeInteger"/> </attribute> </define>
<定義名= "MIN-要素属性"> <属性名= "NMA：MIN-要素"> <データタイプ= "NonNegativeIntegerの" /> </属性> </定義>
<define name="module-attribute"> <attribute name="nma:module"> <data type="Name"/> </attribute> </define>
<定義名= "モジュール属性"> <属性名= "NMA：モジュール"> <データタイプ= "名前" /> </属性> </定義>
<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>
<要素名= "NMA：しなければならない"> <名前= "しなければならない要素" を定義> <<データタイプ= "文字列" /> </属性> <インターリーブ> <オプション> <属性名= "主張"> refの名前= "エラーアプリタグ要素" /> </オプション> <オプション> <REF名= "エラーメッセージ要素" /> </オプション> </インターリーブ> </要素> </定義>
<define name="notifications-element"> <element name="nma:notifications"> <zeroOrMore> <element name="nma:notification"> <ref name="__anyxml__"/> </element> </zeroOrMore> </element> </define>
<名前を定義= "通知-要素"> <要素名= "NMA：通知"> <zeroOrMore> <要素名= "NMA：通知"> <refの名前= "__ AnyXMLで__" /> </要素> </ zeroOrMore> </要素> </定義>
<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>
<定義名= "のRPC-要素"> <要素名= "NMA：のRPC"> <zeroOrMore> <要素名= "NMA：RPC"> <インターリーブ> <要素名= "NMA：入力"> <REF名= "__anyxml __" /> </要素> <オプション> <要素名= "NMA：出力"> <refの名前= "__ AnyXMLで__" /> </要素> </オプション> </インタリーブ> </要素> </ zeroOrMore > </要素> </定義>
<define name="ordered-by-attribute"> <attribute name="nma:ordered-by"> <choice> <value>user</value> <value>system</value> </choice> </attribute> </define>
<選択肢> <value>のユーザー</ value>の<値>システム</ value>の</選択> </属性：<名前= "注文-でNMA" 属性>を<= "注文ごとの属性" 名を定義します> > </定義>
<define name="status-attribute"> <optional> <attribute name="nma:status"> <choice> <value>current</value> <value>deprecated</value> <value>obsolete</value> </choice> </attribute> </optional> </define>
<名前を定義= "ステータス属性"> <オプション> <属性名= "NMA：状態"> <選択肢>は<値>現在の</ value>の<値>非推奨</ value>の<値>時代遅れ</ value>の</選択> </属性> </オプション> </定義>
<define name="unique-attribute"> <optional> <attribute name="nma:unique"> <list> <data type="token"/> </list> </attribute> </optional> </define>
<データタイプ= "トークン" /> </リスト> </属性> </オプション> </定義<リスト>：<オプション> <属性名= "ユニークNMA"> <名前= "ユニークな属性" を定義>を>
<define name="units-attribute"> <optional> <attribute name="nma:units"> <data type="string"/> </attribute> </optional> </define>
<名前= "単位属性" を定義> <オプション> <名前=属性 "NMA：単位"> <データタイプ= "文字列" /> </属性> </オプション> </定義>
<define name="when-attribute"> <optional> <attribute name="nma:when"> <data type="string"/> </attribute> </optional> </define>
<定義名= "属性"> <オプション> <属性名= "NMA：とき"> <データタイプ= "文字列" /> </属性> </オプション> </定義>
<define name="__anyxml__"> <zeroOrMore> <choice> <attribute> <anyName/> </attribute> <element> <anyName/> <ref name="__anyxml__"/> </element> <text/> </choice> </zeroOrMore> </define>
<定義名= "__ AnyXMLで__"> <zeroOrMore> <選択> <属性> <anyName /> </属性> <要素> <anyName /> <refの名前= "__ AnyXMLで__" /> </要素> <テキスト/> < /選択> </ zeroOrMore> </定義>
</grammar>
</文法>
<CODE ENDS>
<CODEはENDS>
Appendix B. Schema-Independent Library
付録B.スキーマに依存しないライブラリ
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のマッピングステップで生成されたすべてのRELAX NGスキーマに共通の命名パターンの定義をコピーしないようにするためには、定義はライブラリファイルに収集されています「（XML構文）と "relaxNGで-lib.rnc"（コンパクト構文） - lib.rngをRELAXNG。付属の定義がベースNETCONF [RFC4741]とイベント通知[RFC5277]から共通の要素のためのパターンを覆います。
<CODE BEGINS> file "relaxng-lib.rng"
<CODE BEGINS>ファイル "をrelaxNG-lib.rng"
<?xml version="1.0" encoding="UTF-8"?>
<？xml version = "1.0" エンコード= "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">
<文法のxmlns = "http://relaxng.org/ns/structure/1.0" のxmlns：NC = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0" のxmlns：EN = "URN：IETF：paramsは：XML：NS：NETCONF：通知：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>
<名= "メッセージID" を属性> <名前= "メッセージID属性" を定義> <データタイプ= "文字列"> <PARAM NAME = "maxLengthの"> 4095 </ param>の</データ> </属性> </定義>
<define name="ok-element"> <element name="nc:ok"> <empty/> </element> </define>
<名前を定義= "の要素"> <要素名= "NC：ON"> <空/> </要素> </定義>
<define name="eventTime-element"> <element name="en:eventTime"> <data type="dateTime"/> </element> </define> </grammar>
<定義名= "イベント時刻要素"> <要素名= "EN：イベント時刻"> <データタイプ= "dateTimeの" /> </要素> </定義> </文法>
<CODE ENDS>
<CODEはENDS>
Appendix C. Mapping DHCP Data Model - A Complete Example
付録C.マッピングDHCPデータモデル - 完全な例
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ツー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.
等により行あたり72文字の制限、特に手動で編集する必要少数の長い文字列、IPアドレスの正規表現パターンにこれらは「... ...正規表現パターン」プレースホルダ文字列に置き換えられました。また、改行は、いくつかの説明文字列とのSchematronメッセージに追加されました。
Other than that, the results of the automatic translations were not changed.
それ以外は、自動翻訳の結果が変化しませんでした。
C.1. Input YANG Module
C.1。入力YANGモジュール
module dhcp {
namespace "http://example.com/ns/dhcp";
prefix 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;
}
}
}
}
C.2. Hybrid Schema
C.2。ハイブリッドスキーマ
<?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>
<文法のxmlns = "http://relaxng.org/ns/structure/1.0" のxmlns <xmlのバージョン= "1.0" エンコード= "UTF-8"？>：NMA = "壷：IETF：のparams：XML：NS ：netmod：DSDL-注釈：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：クリエーター> Pyang 1.0aに、DSDLプラグイン</ DC：クリエイター> <DC：日付> 2010-06-17 </ DC：日付> <起動> <文法NMA：モジュール= "DHCP" NS = "http://example.com/ns/dhcp"> <DC：ソース> YANGモジュール 'DHCP' </ DC：ソース> <スタート>
<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>
<インターリーブ> <オプション> <要素名= "DHCP：開始"> <REF名= "IETF陽-types__date・アンド・タイム" /> </要素> </オプション> <オプション> <要素名=「DHCP ：終了 "> <REF名=" IETF陽-types__date・アンド・タイム "/> </要素> </オプション> <オプション> <要素名=" DHCP：ハードウェア "> <インターリーブ> <オプション> <要素名前= "DHCP：タイプ"> <選択> <値>イーサネット</ value>の<値>トークンリング</ value>の<値> FDDI </ value>の</選択> </要素> </オプション> <オプション> <要素名= "DHCP：アドレス"> <refの名前= "IETF陽-types__physアドレス" /> </要素> </オプション> </インタリーブ> </要素> </オプション> </インターリーブ> </要素> </ zeroOrMore> </要素> </オプション> </インターリーブ> </要素> </オプション> </ NMA：データ> <NMA：のRPC /> <NMA：通知/> </開始> </文法> </開始> <定義名= "IETF陽-types__physアドレス"> <データタイプ= "文字列">の<param = "パターン" 名前>（[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">
</データ> </定義> <データタイプ= "文字列"> <PARAM NAME = "パターン"> ...正規表現パターン<名前= "IETF-INET-types__ipv6アドレス" を定義> ... </ param>の<PARAM NAME = "パターン"> ...正規表現パターン... </ param>の</データ> </定義> <= "IETF-INET-types__ipプレフィックス" 名を定義> <選択> <refの名前=」 IETF-INET-types__ipv4-接頭辞 "/> <refの名前=" IETF-INET-types__ipv6-接頭辞 "/> </選択> </定義> <定義名=" IETF-INET-types__host "> <選択> <REF名前= "IETF-INET-types__ipアドレス" /> <refの名前= "IETF-INET-types__domain名" /> </選択> </定義> <名前を定義= "IETF-ヤン・types__date-と時刻"> <データタイプ=" 文字列 "> <PARAM NAME =" パターン "> ...正規表現パターン... </ param>の</データ> </定義> <定義名=" _ dhcp__subnetリスト "> <A ：ドキュメント>サブネットの再利用可能なリスト</：ドキュメント> <zeroOrMore> <要素NMA：キー= "ネット" 名前= "サブネット"> <要素名= "ネット"> <refの名前= "IETF-INET-types__ip -prefix "/> </要素> <インターリーブ> <オプション> <要素名=" 範囲 "> <インターリーブ> <オプション> <要素名=" ダイナミックBOOTP "> <：ドキュメント>アロWS BOOTPクライアントは、この範囲のアドレスを取得する</ A：ドキュメンテーション> <空/> </要素> </オプション> <要素名= "低"> <refの名前= "IETF-INET-types__ipアドレス" /> </要素> <要素名= "高">
<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>
<refの名前= "IETF-INET-types__ipアドレス" /> </要素> </インタリーブ> </要素> </オプション> <オプション> <要素名= "DHCP-オプション"> <インターリーブ> <A：ドキュメント> DHCPプロトコル</ Aでのオプション：ドキュメント> <zeroOrMore> <要素NMA：葉のリスト= "true" の名= "ルータ" NMA：注文したバイ= "ユーザー"> <：ドキュメント>を参照してください：RFCを2132年、秒。 3.8 </ A：ドキュメンテーション> <refの名前= "IETF-INET-types__host" /> </要素> </ zeroOrMore> <オプション> <要素名= "ドメイン名"> <：ドキュメント>を参照してください。RFC 2132 、秒。 3.17 </：ドキュメント> <refの名前= "IETF-INET-types__domain名" /> </要素> </オプション> </インタリーブ> </要素> </オプション> <オプション> <要素NMA：デフォルト= "7200" 名前= "MAX-リース・タイム" NMA：単位= "秒"> <データタイプ= "unsignedInt型" /> </要素> </オプション> </インタリーブ> </要素> </ zeroOrMore> </定義> <名前を定義= "IETF-INET-types__domain名"> <データタイプ= "文字列"> <PARAM NAME = "パターン"> ...正規表現パターン... </ param>のの<paramの名前= "はminLength"> 1 </ PARAM> <PARAM NAME = "maxLengthの"> 253 </ param>の</データ> </定義>
<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>
</データ> </定義> ...正規表現パターン... </ param>の<データ型が= "文字列"> <PARAM NAME = "パターン"> <名前= "IETF-INET-types__ipv4プレフィックス" を定義> </データ> </定義> ...正規表現パターン... </ param>の<データ型が= "文字列"> <PARAM NAME = "パターン"> <名前= "IETF-INET-types__ipv4アドレス" を定義> <データ型が= "文字列"> <PARAM NAME = "パターン"> ...正規表現パターンが... </ param>の<PARAM NAME = "パターン"> <名前= "IETF-INET-types__ipv6プレフィックス" を定義> ...正規表現パターン... </ param>の</データ> </定義> <名前を定義= "IETF-INET-types__ipアドレス"> <選択> <refの名前= "IETF-INET-types__ipv4アドレス" /> <refの名前= "IETF-INET-types__ipv6アドレス" /> </選択> </定義> </文法>
C.3. Final DSDL Schemas
C.3。最終DSDLスキーマ
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スキーマを含んでいます。これらのスキーマは、直接への応答を検証するために使用することができるフィルタリングされていない<NC：取得> DHCPデータモデルに対応する内容で。
The RELAX NG schema (in two parts, as explained in Section 8.2) also includes the schema-independent library from Appendix B.
（セクション8.2で説明したように、二つの部分）も付録B.からスキーマに依存しないライブラリを含むRELAX NGスキーマ
C.3.1. Main RELAX NG Schema for <nc:get> Reply
C.3.1。メイン<NC：取得>のためにNGスキーマをRELAX返信
<?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">
<文法のxmlns = "http://relaxng.org/ns/structure/1.0" のxmlns <XMLバージョン= "1.0" エンコード= "UTF-8"？>：NMA = "URN：IETF：paramsは：XML：NS ：netmod：DSDL-注釈：1" のxmlns：DHCP = "http://example.com/ns/dhcp" datatypeLibrary = "http://www.w3.org/2001/XMLSchema-datatypes" NS = "URN： IETF：paramsは：XML：NS：NETCONF：塩基：1.0 "> <HREF =含む" relaxNGで-lib.rng "/> <> <要素名=開始" RPC返信 "> <REF名=" メッセージを-ID-属性 "/> <要素名=" データ ">
<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>
<オプション> <要素名= "DHCP：ハードウェア"> <インターリーブ> <オプション> <要素名= "DHCP：タイプ"> <選択> <値>イーサネット</値> <値>トークンリング</値> <値> FDDI </ value>の</選択> </要素> </オプション> <オプション> <要素名= "DHCP：アドレス"> <refの名前= "IETF陽-types__physアドレス" /> </要素> </オプション> </インターリーブ> </要素> </オプション> </インターリーブ> </要素> </ zeroOrMore> </要素> </オプション> </インターリーブ> </要素> </オプション> <開始/> </文法> </インターリーブ> </要素> </要素> <開始/> </文法>
C.3.2. RELAX NG Schema - Global Named Pattern Definitions
C.3.2。 NGスキーマをRELAX - グローバル名前付きパターンの定義
<?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})*)?
<文法のxmlns = "http://relaxng.org/ns/structure/1.0" のxmlns <XMLバージョン= "1.0" エンコード= "UTF-8"？>：NMA = "URN：IETF：paramsは：XML：NS ：netmod：DSDL-注釈：1" のxmlns：DHCP = "http://example.com/ns/dhcp" datatypeLibrary = "http://www.w3.org/2001/XMLSchema-datatypes"> <名前を定義し= "IETF陽-types__physアドレス"> <データタイプ= "文字列"> <PARAM NAME = "パターン">（[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>
</ param>の</データ> </定義> <名前を定義= "IETF-INET-types__ipv6アドレス"> <データタイプ= "文字列"> <PARAM NAME = "パターン"> ...正規表現パターン... </ param>の</データ> </定義> <定義名= "IETF-INET-types__ipプレフィックス"> <選択> <refの名前= "IETF-INET-types__ipv4-接頭辞" /> <refの名前= "IETF -inet-types__ipv6-接頭辞 "/> </選択> </定義> <定義名=" IETF-INET-types__host "> <選択> <refの名前=" IETF-INET-types__ipアドレス "/> <refの名前= "IETF-INET-types__domain名" /> </選択> </定義> <名前を定義= "IETF-ヤン・types__date-とタイム"> <データタイプ= "文字列">ます。<param name = "パターン"> ...正規表現パターン... </ param>の</データ> </定義> <定義名=" _ dhcp__subnetリスト "> <zeroOrMore> <要素名=" サブネット "> <要素名=" ネット」 > <REF名= "IETF-INET-types__ipプレフィックス" /> </要素> <インターリーブ> <オプション> <要素名= "範囲"> <インターリーブ> <オプション> <要素名= "ダイナミックBOOTP"> <空/> </要素> </オプション> <要素名= "ロー"> <REF名= "IETF-INET-types__ipアドレス" /> </要素> <要素名= "ハイ"> <REF名= "すなわちTF-INET-types__ipアドレス "/> </要素> </インタリーブ> </要素>
</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>
</オプション> <オプション> <要素名= "DHCP-オプション"> <インターリーブ> <zeroOrMore> <要素名= "ルータ"> <refの名前= "IETF-INET-types__host" /> </要素> </ zeroOrMore> <オプション> <要素名= "ドメイン名"> <refの名前= "IETF-INET-types__domain名" /> </要素> </オプション> </インタリーブ> </要素> </オプション> <オプション> <要素名= "MAX-リースタイム"> <データタイプ= "unsignedInt型" /> </要素> </オプション> </インターリーブ> </要素> </ zeroOrMore> </定義> <定義名前= "IETF-INET-types__domain名"> <データタイプ= "文字列"> <PARAM NAME = "パターン"> ...正規表現パターン... </ param>の<PARAM NAME = "はminLength"> 1 < / param>の<PARAM NAME = "maxLengthの"> 253 </ param>の</データ> </定義> <定義名= "IETF-INET-types__ipv4プレフィックス"> <データタイプ= "文字列"> <PARAM NAME = "パターン"> ...正規表現パターン... </ param>の</データ> </定義> <名前= "IETF-INET-types__ipv4アドレス" を定義> <データタイプ= "文字列">の<paramの名前= "パターン"> ...正規表現パターン... </ param>の</データ> </定義> <定義名= "IETF-INET-types__ipv6プレフィックス"> <データタイプ= "文字列">の<param名前= "パターン"> ...正規表現パターン... </ param>の<PARAM NAME = "パターン"> ...正規表現パターン... </ param>の</データ>
</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>
</定義> <定義名= "IETF-INET-types__ipアドレス"> <選択> <refの名前は= "IETF-INET-types__ipv4アドレス" /> <refの名前= "IETF-INET-types__ipv6アドレス" / > </選択> </定義> </文法>
C.3.3. Schematron Schema for <nc:get> Reply
C.3.3。 <：取得NC>返信用のSchematronスキーマ
<?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"
<？xml version = "1.0" エンコード= "UTF-8"？> <SCH：スキーマのxmlns：SCH = "http://purl.oclc.org/dsdl/schematron"> <SCH：NS URI = "のhttp： //example.com/ns/dhcp」プレフィックス= "DHCP" /> <SCH：NS URI = "壷：IETF：のparams：XML：NS：NETCONF：ベース：1.0" プレフィックス= "NC" /> <SCH：パターン抽象的な= "true" をID = "_ dhcp__subnetリスト"> <SCH：ルールコンテキスト= "$スタート/ $県：サブネット"> <SCH：レポートテスト= "先行兄弟:: $県：サブネット[$県：ネット=現在（）/ $県：ネット] ">キー重複 "ネット"</ SCHを：レポート> </ SCH：ルール> <SCH：ルールコンテキスト=" $スタート/ $県：サブネット/ $県：dhcp-オプション/ $県：ルータ "> <SCH：レポートテスト=" =先行兄弟::ルータ ">重複リーフリスト値 "<SCH：。"。" 選択値-の= />」</ SCH：レポート> </ SCH：ルール> </ SCH：パターン> <SCH：パターンID = "DHCP"> <SCH：ルールコンテキスト= "/ NC：RPC返信/ NC：データ/ DHCP：DHCP / DHCP：デフォルトリース-time "> <SCH：=テストをアサート" ＆LT; = ../ DHCP：MAX-リースタイム ">デフォルトリース時間が</ SCH MAX-リース時間よりも小さくなければならない：アサート> < / SCH：ルール> <SCH：ルールコンテキスト= "/ NC：RPC返信/ NC：データ/ DHCP：DHCP / DHCP：共有ネットワーク/ DHCP：共有ネットワーク"> <S CH：レポートテスト= "先行兄弟:: DHCP：共有ネットワーク[DHCP：名=現在の（）/ DHCP：名]">重複キー "DHCP：名" </ SCH：レポート> </ SCH：ルール> <SCH：ルールコンテキスト= "/ NC：RPC返信/ NC：データ/ DHCP：DHCP / DHCP：ステータス/ DHCP：リース"> <SCH：レポートテスト= "先行兄弟:: DHCP：リース[DHCP：アドレス=現在の（）/ DHCP：アドレス] ">重複キー "DHCP：アドレス"
</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>
</ SCH：レポート> </ SCH：ルール> </ SCH：パターン> <SCH：パターンID = "id2768196" は、A = "_ dhcp__subnetリスト"> <SCH：PARAM NAME = "開始" 値= "/ NC：RPC返信/ NC：データ/ DHCP：DHCP "/> <SCH：PARAM名=" 県」値= "DHCP" /> </ SCH：パターン> <SCH：パターンID = "id2768215" は、Aであります= "_ dhcp__subnetリスト"> <SCH：PARAM名= "開始" 値= "/ NC：RPC返信/ NC：データ/ DHCP：DHCP / DHCP：共有ネットワーク/ DHCP：共有ネットワーク" /> <SCH ：PARAM名= "県" 値= "DHCP" /> </ SCH：パターン> </ SCH：スキーマ>
C.3.4. DSRL Schema for <nc:get> Reply
C.3.4。 <：取得NC>返信用DSRLスキーマ
<?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>
<？xml version = "1.0" エンコード= "UTF-8"？> <DSRL：マップのxmlns：DSRL = "http://purl.oclc.org/dsdl/dsrl" のxmlns：DHCP = "のhttp：//例.COM / NS / DHCP」のxmlns：NC = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0"> <DSRL：要素マップ> <DSRL：親> / NC：RPC返信/ NC：データ</ DSRL：親> <DSRL：名> DHCP：DHCP </ DSRL：名> <DSRL：デフォルト・コンテンツ> <DHCP：MAX-リース時間> 7200 </ DHCP：MAX-リース時間> <DHCP ：デフォルト・リース・タイム> 600 </ DHCP：デフォルト・リース・タイム> </ DSRL：デフォルト・コンテンツ> </ DSRL：要素マップ> <DSRL：要素マップ> <DSRL：親> / NC：RPC -reply / NC：データ/ DHCP：DHCP </ DSRL：親> <DSRL：名> DHCP：MAX-リース・タイム</ DSRL：名> <DSRL：デフォルト・コンテンツ> 7200 </ DSRL：デフォルトのコンテンツ> </ DSRL：要素マップ> <DSRL：要素マップ> <DSRL：親> / NC：RPC-返信/ NC：データ/ DHCP：DHCP </ DSRL：親> <DSRL：名> DHCP：デフォルトのリース-time </ DSRL：名> <DSRL：デフォルト・コンテンツ> 600 </ DSRL：デフォルト・コンテンツ> </ DSRL：要素マップ> <DSRL：要素マップ> <DSRL：親> / NC：RPC返信/ NC：データ/ DHCP：DHCP / DHCP：サブネット</ DSRL：親> <DSRL：名> DHCP：MAX-リース・タイム</ DSRL：名> <DSRL：デフォルト・コンテンツ> 7 200 </ DSRL：デフォルト・コンテンツ> </ DSRL：要素マップ> <DSRL：要素マップ>
<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>
<DSRL：親> / NC：RPC返信/ NC：データ/ DHCP：DHCP / DHCP：共有ネットワーク/ DHCP：共有ネットワーク/ DHCP：サブネット</ DSRL：親> <DSRL：名> DHCP：MAX-リース・タイム</ DSRL：名> <DSRL：デフォルト・コンテンツ> 7200 </ DSRL：デフォルト・コンテンツ> </ DSRL：要素マップ> </ DSRL：マップ>
Author's Address
著者のアドレス
Ladislav Lhotka (editor) CESNET
ラディスラフLhotka（編集者）CESNET
EMail: lhotka@cesnet.cz
メールアドレス：lhotka@cesnet.cz