summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6110.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6110.txt')
-rw-r--r--doc/rfc/rfc6110.txt5603
1 files changed, 5603 insertions, 0 deletions
diff --git a/doc/rfc/rfc6110.txt b/doc/rfc/rfc6110.txt
new file mode 100644
index 0000000..cb8dbc6
--- /dev/null
+++ b/doc/rfc/rfc6110.txt
@@ -0,0 +1,5603 @@
+
+
+
+
+
+
+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.
+
+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.
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lhotka Standards Track [Page 1]
+
+RFC 6110 Mapping YANG to DSDL February 2011
+
+
+Copyright Notice
+
+ Copyright (c) 2011 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ 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.
+
+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
+
+
+
+Lhotka Standards Track [Page 2]
+
+RFC 6110 Mapping YANG to DSDL February 2011
+
+
+ 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
+
+
+
+Lhotka Standards Track [Page 3]
+
+RFC 6110 Mapping YANG to DSDL February 2011
+
+
+ 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
+
+
+
+Lhotka Standards Track [Page 4]
+
+RFC 6110 Mapping YANG to DSDL February 2011
+
+
+ 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
+
+1. Introduction
+
+ 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.
+
+ 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.
+
+ 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
+
+
+
+Lhotka Standards Track [Page 5]
+
+RFC 6110 Mapping YANG to DSDL February 2011
+
+
+ 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.
+
+ 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.
+
+2. Terminology and Notation
+
+ 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].
+
+ The following terms are defined in [RFC4741]:
+
+ o client
+
+ o datastore
+
+ o message
+
+ o operation
+
+ o server
+
+ The following terms are defined in [RFC6020]:
+
+ o augment
+
+ o base type
+
+ o built-in type
+
+
+
+Lhotka Standards Track [Page 6]
+
+RFC 6110 Mapping YANG to DSDL February 2011
+
+
+ o configuration data
+
+ o container
+
+ o data model
+
+ o data node
+
+ o data tree
+
+ o derived type
+
+ o device deviation
+
+ o extension
+
+ o feature
+
+ o grouping
+
+ o instance identifier
+
+ o leaf-list
+
+ o list
+
+ o mandatory node
+
+ o module
+
+ o RPC
+
+ o RPC operation
+
+ o schema node
+
+ o schema tree
+
+ o state data
+
+ o submodule
+
+ o top-level data node
+
+ o uses
+
+
+
+
+
+
+Lhotka Standards Track [Page 7]
+
+RFC 6110 Mapping YANG to DSDL February 2011
+
+
+ The following terms are defined in [XML-INFOSET]:
+
+ o attribute
+
+ o document
+
+ o document element
+
+ o document type declaration (DTD)
+
+ o element
+
+ o information set
+
+ o namespace
+
+ In the text, the following typographic conventions are used:
+
+ o YANG statement keywords are delimited by single quotes.
+
+ o XML element names are delimited by "<" and ">" characters.
+
+ o Names of XML attributes are prefixed by the "@" character.
+
+ o Other literal values are delimited by double quotes.
+
+ XML element names are always written with explicit namespace prefixes
+ corresponding to the following XML vocabularies:
+
+ "a" DTD compatibility annotations [RNG-DTD];
+
+ "dc" Dublin Core metadata elements [RFC5013];
+
+ "dsrl" Document Semantics Renaming Language [DSRL];
+
+ "en" NETCONF event notifications [RFC5277];
+
+ "nc" NETCONF protocol [RFC4741];
+
+ "nma" NETMOD-specific schema annotations (see Section 5.3);
+
+ "nmf" NETMOD-specific XML Path Language (XPath) extension functions
+ (see Section 12.7);
+
+ "rng" RELAX NG [RNG];
+
+ "sch" ISO Schematron [Schematron];
+
+
+
+
+Lhotka Standards Track [Page 8]
+
+RFC 6110 Mapping YANG to DSDL February 2011
+
+
+ "xsd" W3C XML Schema [XSD].
+
+ The following table shows the mapping of these prefixes to namespace
+ URIs.
+
+ +--------+-----------------------------------------------------+
+ | Prefix | Namespace URI |
+ +--------+-----------------------------------------------------+
+ | a | http://relaxng.org/ns/compatibility/annotations/1.0 |
+ | | |
+ | dc | http://purl.org/dc/terms |
+ | | |
+ | dsrl | http://purl.oclc.org/dsdl/dsrl |
+ | | |
+ | en | urn:ietf:params:xml:ns:netconf:notification:1.0 |
+ | | |
+ | nc | urn:ietf:params:xml:ns:netconf:base:1.0 |
+ | | |
+ | nma | urn:ietf:params:xml:ns:netmod:dsdl-annotations:1 |
+ | | |
+ | nmf | urn:ietf:params:xml:ns:netmod:xpath-extensions:1 |
+ | | |
+ | rng | http://relaxng.org/ns/structure/1.0 |
+ | | |
+ | sch | http://purl.oclc.org/dsdl/schematron |
+ | | |
+ | xsd | http://www.w3.org/2001/XMLSchema |
+ +--------+-----------------------------------------------------+
+
+ Table 1: Used namespace prefixes and corresponding URIs
+
+2.1. Glossary of New Terms
+
+ o ancestor data type: Any data type from which a given data type is
+ (transitively) derived.
+
+ 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 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 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.
+
+
+
+
+Lhotka Standards Track [Page 9]
+
+RFC 6110 Mapping YANG to DSDL February 2011
+
+
+3. Objectives and Motivation
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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:
+
+ 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.
+
+
+
+Lhotka Standards Track [Page 10]
+
+RFC 6110 Mapping YANG to DSDL February 2011
+
+
+ 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.
+
+4. DSDL Schema Languages
+
+ 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.
+
+ The mapping described in this document uses three of the DSDL schema
+ languages, namely RELAX NG [RNG], Schematron [Schematron], and DSRL
+ [DSRL].
+
+4.1. RELAX NG
+
+ 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).
+
+ 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.
+
+ 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.
+
+
+
+
+
+
+
+
+
+Lhotka Standards Track [Page 11]
+
+RFC 6110 Mapping YANG to DSDL February 2011
+
+
+ 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].
+
+ 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:
+
+ 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 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.
+
+ 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.
+
+ 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".
+
+4.2. Schematron
+
+ 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:
+
+ o context - an XPath expression that defines the set of locations
+ where the rule is to be applied;
+
+
+
+Lhotka Standards Track [Page 12]
+
+RFC 6110 Mapping YANG to DSDL February 2011
+
+
+ o assert or report condition - another XPath expression that is
+ evaluated relative to the location matched by the context
+ expression;
+
+ o human-readable message that is displayed when the assert condition
+ is false or report condition is 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).
+
+ 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.
+
+ 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 elements are qualified with namespace URI
+ "http://purl.oclc.org/dsdl/schematron".
+
+4.3. Document Semantics Renaming Language (DSRL)
+
+ 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 elements are qualified with namespace URI
+ "http://purl.oclc.org/dsdl/dsrl".
+
+
+
+Lhotka Standards Track [Page 13]
+
+RFC 6110 Mapping YANG to DSDL February 2011
+
+
+5. Additional Annotations
+
+ 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.
+
+ 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.
+
+ 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.
+
+5.1. Dublin Core Metadata Elements
+
+ 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].
+
+ Dublin Core elements are qualified with namespace URI
+ "http://purl.org/dc/terms".
+
+5.2. RELAX NG DTD Compatibility Annotations
+
+ 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.
+
+ 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 compatibility annotations are qualified with namespace URI
+ "http://relaxng.org/ns/compatibility/annotations/1.0".
+
+
+
+
+
+
+Lhotka Standards Track [Page 14]
+
+RFC 6110 Mapping YANG to DSDL February 2011
+
+
+5.3. NETMOD-Specific Annotations
+
+ 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.
+
+ 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.
+
+ +---------------------------+--------------------+------+
+ | 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 | |
+
+
+
+Lhotka Standards Track [Page 15]
+
+RFC 6110 Mapping YANG to DSDL February 2011
+
+
+ | | | |
+ | @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
+
+ Notes:
+
+ 1. Appears only as a subelement of <nma:must>.
+
+ 2. Has an optional attribute @require-instance.
+
+ 3. Has a mandatory attribute @assert and two optional subelements
+ <nma:error-app-tag> and <nma:error-message>.
+
+ 4. Marker element in the hybrid schema.
+
+6. Overview of the Mapping
+
+ This section gives an overview of the YANG-to-DSDL mapping, its
+ inputs and outputs. Figure 1 presents an overall structure of the
+ mapping:
+
+
+
+
+
+
+
+
+Lhotka Standards Track [Page 16]
+
+RFC 6110 Mapping YANG to DSDL February 2011
+
+
+ +----------------+
+ | YANG module(s) |
+ +----------------+
+ |
+ |T
+ |
+ +------------------------------------+
+ | hybrid schema |
+ +------------------------------------+
+ / | | \
+ / | | \
+ Tg/ Tr| |Tn \
+ / | | \
+ +---------+ +-----+ +-------+ +------+
+ |get reply| | rpc | | notif | | .... |
+ +---------+ +-----+ +-------+ +------+
+
+ Figure 1: Structure of the mapping
+
+ The mapping procedure is divided into two steps:
+
+ 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.
+
+ 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.
+
+ 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.
+
+
+
+
+
+
+Lhotka Standards Track [Page 17]
+
+RFC 6110 Mapping YANG to DSDL February 2011
+
+
+ It is also assumed that the algorithm has access, perhaps on demand,
+ to all YANG modules that the input modules import (directly or
+ transitively).
+
+ 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).
+
+ The output of the second step is a coordinated set of three DSDL
+ schemas corresponding to a specific data object and context:
+
+ o RELAX NG schema describing the grammatical and data type
+ constraints;
+
+ o Schematron schema expressing other constraints such as uniqueness
+ of list keys or user-specified semantic rules;
+
+ o DSRL schema containing the specification of default contents.
+
+7. NETCONF Content Validation
+
+ 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.
+
+ The validation proceeds in the following steps, which are also
+ illustrated in Figure 2:
+
+ 1. The XML instance document is checked for grammatical and data
+ type validity using the RELAX NG schema.
+
+ 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.
+
+ 3. The semantic constraints are checked using the Schematron schema.
+
+
+
+
+
+Lhotka Standards Track [Page 18]
+
+RFC 6110 Mapping YANG to DSDL February 2011
+
+
+ +----------+ +----------+
+ | | | 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
+
+8. Design Considerations
+
+ 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.
+
+8.1. Hybrid Schema
+
+ 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.
+
+ 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).
+
+ 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
+
+
+
+
+
+
+Lhotka Standards Track [Page 19]
+
+RFC 6110 Mapping YANG to DSDL February 2011
+
+
+ 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 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.
+
+ The markers are the following XML elements in the namespace of
+ NETMOD-specific annotations (URI
+ urn:ietf:params:xml:ns:netmod:dsdl-annotations:1):
+
+ +-------------------+---------------------------------------+
+ | Element name | Role |
+ +-------------------+---------------------------------------+
+ | nma:data | encloses configuration and state data |
+ | | |
+ | nma:rpcs | encloses all RPC operations |
+ | | |
+ | nma:rpc | encloses an individual RPC operation |
+ | | |
+ | nma:input | encloses an RPC request |
+ | | |
+ | nma:output | encloses an RPC reply |
+ | | |
+ | nma:notifications | encloses all notifications |
+ | | |
+ | nma:notification | encloses an individual notification |
+ +-------------------+---------------------------------------+
+
+ Table 3: Marker elements in the hybrid schema
+
+ 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:
+
+
+
+
+
+
+Lhotka Standards Track [Page 20]
+
+RFC 6110 Mapping YANG to DSDL February 2011
+
+
+ <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>
+
+
+
+Lhotka Standards Track [Page 21]
+
+RFC 6110 Mapping YANG to DSDL February 2011
+
+
+ ...global named pattern definitions...
+ </grammar>
+
+ A complete hybrid schema for the data model of a DHCP server is given
+ in Appendix C.2.
+
+8.2. Modularity
+
+ 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:
+
+ 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 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).
+
+ 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.
+
+ 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
+
+
+
+Lhotka Standards Track [Page 22]
+
+RFC 6110 Mapping YANG to DSDL February 2011
+
+
+ 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.
+
+ 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.
+
+ 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:
+
+ o Every global definition MUST be placed as a child of the outer
+ <rng:grammar> element (the document root of the hybrid schema).
+
+ o Every non-global definitions MUST be placed as a child of the
+ corresponding embedded <rng:grammar> element.
+
+ 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.
+
+8.3. Granularity
+
+ 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.
+
+ 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.
+
+
+
+
+Lhotka Standards Track [Page 23]
+
+RFC 6110 Mapping YANG to DSDL February 2011
+
+
+ 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.
+
+8.4. Handling of XML Namespaces
+
+ Most modern XML schema languages, including RELAX NG, Schematron, and
+ DSRL, support schemas for so-called compound XML documents that
+ contain elements from multiple namespaces. This is useful for our
+ purpose since the YANG-to-DSDL mapping allows for multiple input YANG
+ modules, which naturally leads to compound document schemas.
+
+ RELAX NG offers two alternatives for defining the target namespaces
+ in the schema:
+
+ 1. First possibility is the traditional XML way via the @xmlns:xxx
+ attribute.
+
+ 2. One of the target namespace URIs may be declared using the @ns
+ attribute.
+
+ In both the hybrid schema and validation RELAX NG schemas generated
+ in the second step, the namespaces MUST be declared as follows:
+
+ 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.
+
+ 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.
+
+ This setup is illustrated by the example at the end of Section 8.1.
+
+ DSRL schemas may declare any number of target namespaces via the
+ standard XML attributes xmlns:xxx.
+
+ In contrast, Schematron requires all used namespaces to be defined in
+ the <sch:ns> subelements of the document element <sch:schema>.
+
+
+
+
+Lhotka Standards Track [Page 24]
+
+RFC 6110 Mapping YANG to DSDL February 2011
+
+
+9. Mapping YANG Data Models to the Hybrid Schema
+
+ This section explains the main principles governing the first step of
+ the mapping. Its result is the hybrid schema that is described in
+ Section 8.1.
+
+ A detailed specification of the mapping of individual YANG statements
+ is contained in Section 10.
+
+9.1. Occurrence Rules for Data Nodes
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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.
+
+
+
+
+
+
+
+Lhotka Standards Track [Page 25]
+
+RFC 6110 Mapping YANG to DSDL February 2011
+
+
+ Note that both occurrence constraints apply to containers at the top
+ level of the data tree, and then also to other containers under the
+ additional condition that their parent node exists in the instance
+ document. For example, consider the following YANG fragment:
+
+ container outer {
+ presence 'Presence of "outer" means something.';
+ container c1 {
+ leaf foo {
+ type uint8;
+ default 1;
+ }
+ }
+ container c2 {
+ leaf-list bar {
+ type uint8;
+ min-elements 0;
+ }
+ }
+ container c3 {
+ leaf baz {
+ type uint8;
+ mandatory true;
+ }
+ }
+ }
+
+ Here, container "outer" has the 'presence' substatement, which means
+ that it is optional and not implicit. If "outer" is not present in a
+ configuration, its child containers are not present as well.
+ However, if "outer" does exist, it makes sense to ask which of its
+ child containers are optional and which are implicit. In this case,
+ "c1" is optional and implicit, "c2" is optional but not implicit, and
+ "c3" is mandatory (and therefore not implicit).
+
+ 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.
+
+9.1.1. Optional and Mandatory Nodes
+
+ The decision whether a given node is mandatory or optional is
+ governed by the following rules:
+
+
+
+
+
+
+Lhotka Standards Track [Page 26]
+
+RFC 6110 Mapping YANG to DSDL February 2011
+
+
+ o Leaf, anyxml, and choice nodes are mandatory if they contain the
+ substatement "mandatory true;". For a choice node, this means
+ that at least one node from exactly one case branch must exist.
+
+ o In addition, a leaf node is mandatory if it is declared as a list
+ key.
+
+ o A list or leaf-list node is mandatory if it contains the 'min-
+ elements' substatement with an argument value greater than zero.
+
+ 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.
+
+ 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.
+
+ 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.
+
+9.1.2. Implicit Nodes
+
+ 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 A leaf node is implicit if and only if it has a default value,
+ defined either directly or via its data type.
+
+ 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.
+
+ 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".
+
+ 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
+
+
+
+Lhotka Standards Track [Page 27]
+
+RFC 6110 Mapping YANG to DSDL February 2011
+
+
+ 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.
+
+9.2. Mapping YANG Groupings and Typedefs
+
+ 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.
+
+ 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:
+
+ 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 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 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.
+
+ 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.
+
+
+
+Lhotka Standards Track [Page 28]
+
+RFC 6110 Mapping YANG to DSDL February 2011
+
+
+ EXAMPLE. Consider the following YANG module that imports the
+ standard module "ietf-inet-types" [RFC6021]:
+
+ 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:
+
+ <rng:define name="example1__vowels">
+ <rng:data type="string">
+ <rng:param name="pattern">[aeiouy]*</rng:param>
+ </rng:data>
+ </rng:define>
+
+ <rng:define name="_example1__grp1">
+ <rng:optional>
+ <rng:element name="void">
+ <rng:empty/>
+ </rng:element>
+ </rng:optional>
+ </rng:define>
+
+9.2.1. YANG Refinements and Augments
+
+ 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:
+
+
+
+Lhotka Standards Track [Page 29]
+
+RFC 6110 Mapping YANG to DSDL February 2011
+
+
+ o The 'refine' statement allows for changing parameters of a schema
+ node inside the grouping referenced by the parent 'uses'
+ statement;
+
+ o The 'augment' statement can be used for adding new schema nodes to
+ the grouping contents.
+
+ 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.
+
+ 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.
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lhotka Standards Track [Page 30]
+
+RFC 6110 Mapping YANG to DSDL February 2011
+
+
+ EXAMPLE. Consider the following YANG module:
+
+ 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:
+
+ <rng:define name="_example2__leaves">
+ <rng:interleave>
+ <rng:ref name="_example2__fr"/>
+ <rng:ref name="_example2__es"/>
+ </rng:interleave>
+ </rng:define>
+
+ <rng:define name="_example2__fr">
+ <rng:optional>
+ <rng:element name="feuille">
+ <rng:data type="string"/>
+ </rng:element>
+ </rng:optional>
+ </rng:define>
+
+ <rng:define name="_example2__es">
+ <rng:optional>
+ <rng:element name="hoja">
+ <rng:data type="string"/>
+ </rng:element>
+ </rng:optional>
+ </rng:define>
+
+
+
+
+Lhotka Standards Track [Page 31]
+
+RFC 6110 Mapping YANG to DSDL February 2011
+
+
+ and the configuration data part of the hybrid schema is a single
+ named pattern reference:
+
+ <nma:data>
+ <rng:ref name="_example2__leaves"/>
+ </nma:data>
+
+ Now assume that the "uses leaves" statement contains a 'refine'
+ substatement, for example:
+
+ uses leaves {
+ refine "hoja" {
+ default "alamo";
+ }
+ }
+
+ The resulting hybrid schema now contains just one named pattern
+ definition - "_example2__fr". The other two groupings "leaves" and
+ "es" have to be expanded because they both lie on the "modification
+ path", i.e., contain the leaf "hoja" that is being refined. The
+ configuration data part of the hybrid schema now looks like this:
+
+ <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>
+
+9.2.2. Type Derivation Chains
+
+ 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.
+
+
+
+
+Lhotka Standards Track [Page 32]
+
+RFC 6110 Mapping YANG to DSDL February 2011
+
+
+ EXAMPLE. Consider this YANG module:
+
+ module example3 {
+ namespace "http://example.com/ns/example3";
+ prefix ex3;
+ typedef dozen {
+ type uint8 {
+ range 1..12;
+ }
+ }
+ leaf month {
+ type dozen;
+ }
+ }
+
+ The 'type' statement in "leaf month" has no restrictions and is
+ therefore mapped simply to the reference <rng:ref
+ name="example3__dozen"/> and the corresponding named pattern is
+ defined as follows:
+
+ <rng:define name="example3__dozen">
+ <rng:data type="unsignedByte">
+ <rng:param name="minInclusive">1</rng:param>
+ <rng:param name="maxInclusive">12</rng:param>
+ </rng:data>
+ </rng:define>
+
+ Assume now that the definition of leaf "month" is changed to:
+
+ leaf month {
+ type dozen {
+ range 7..max;
+ }
+ }
+
+ The output RELAX NG schema then will not contain any named pattern
+ definition and the leaf "month" will be mapped directly to:
+
+ <rng:element name="ex3:month">
+ <rng:data type="unsignedByte">
+ <rng:param name="minInclusive">7</rng:param>
+ <rng:param name="maxInclusive">12</rng:param>
+ </rng:data>
+ </rng:element>
+
+ The mapping of type derivation chains may be further complicated by
+ the presence of the 'default' statement in type definitions. In the
+ simple case, when a type definition containing the 'default'
+
+
+
+Lhotka Standards Track [Page 33]
+
+RFC 6110 Mapping YANG to DSDL February 2011
+
+
+ statement is used without restrictions, the 'default' statement is
+ mapped to the @nma:default attribute attached to the <rng:define>
+ element.
+
+ 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.
+
+ 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:
+
+ <rng:define name="example3bis__dozen" @nma:default="7">
+ <rng:data type="unsignedByte">
+ <rng:param name="minInclusive">1</rng:param>
+ <rng:param name="maxInclusive">12</rng:param>
+ </rng:data>
+ </rng:define>
+
+ If the "dozen" type is restricted when used in the leaf "month"
+ definition, as in the previous example, the "dozen" type has to be
+ expanded and @nma:default becomes an attribute of the <ex3bis:month>
+ element definition:
+
+
+
+
+
+
+
+
+
+Lhotka Standards Track [Page 34]
+
+RFC 6110 Mapping YANG to DSDL February 2011
+
+
+ <rng:element name="ex3bis:month" @nma:default="7">
+ <rng:data type="unsignedByte">
+ <rng:param name="minInclusive">7</rng:param>
+ <rng:param name="maxInclusive">12</rng:param>
+ </rng:data>
+ </rng:element>
+
+ However, if the definition of the leaf "month" itself contained the
+ 'default' substatement, the default specified for the "dozen" type
+ would be ignored.
+
+9.3. Translation of XPath Expressions
+
+ 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.
+
+ 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 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).
+
+ For example, XPath expression "/dhcp/max-lease-time" appearing in a
+ YANG module with the "dhcp" prefix will be translated to:
+
+ o "$pref:dhcp/$pref:max-lease-time", if the expression is inside a
+ top-level grouping;
+
+ o "dhcp:dhcp/dhcp:max-lease-time", otherwise.
+
+
+
+
+
+
+
+
+Lhotka Standards Track [Page 35]
+
+RFC 6110 Mapping YANG to DSDL February 2011
+
+
+ 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.
+
+9.4. YANG Language Extensions
+
+ 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 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].
+
+ EXAMPLE. Consider the following extension defined by the "acme"
+ module:
+
+ extension documentation-flag {
+ argument number;
+ }
+
+ This extension can then be used in the same or another module, for
+ instance like this:
+
+ leaf folio {
+ acme:documentation-flag 42;
+ type string;
+ }
+
+ If this extension is honored by the mapping, it will be mapped to:
+
+ <rng:element name="acme:folio">
+ <acme:documentation-flag number="42"/>
+ <rng:data type="string"/>
+ </rng:element>
+
+ Note that the 'extension' statement itself is not mapped in any way.
+
+
+
+
+
+Lhotka Standards Track [Page 36]
+
+RFC 6110 Mapping YANG to DSDL February 2011
+
+
+10. Mapping YANG Statements to the Hybrid Schema
+
+ 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.
+
+ 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 encoding rules translate to the following rules for ordering
+ multiple subelements:
+
+ 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.
+
+ 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.
+
+ 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.
+
+ The following conventions are used in this section:
+
+ o The argument of the statement being mapped is denoted by ARGUMENT.
+
+ o The element in the RELAX NG schema that becomes the parent of the
+ resulting XML fragment is denoted by PARENT.
+
+10.1. The 'anyxml' Statement
+
+ 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:ref name="__anyxml__"/>
+
+
+
+Lhotka Standards Track [Page 37]
+
+RFC 6110 Mapping YANG to DSDL February 2011
+
+
+ Substatements of the 'anyxml' statement, if any, MAY be mapped to
+ additional children of the <rng:element> element.
+
+ If at least one 'anyxml' statement occurs in any of the input YANG
+ modules, the following pattern definition MUST be added exactly once
+ to the RELAX NG schema as a child of the root <rng:grammar> element
+ (cf. [Vli04], p. 172):
+
+ <rng:define name="__anyxml__">
+ <rng:zeroOrMore>
+ <rng:choice>
+ <rng:attribute>
+ <rng:anyName/>
+ </rng:attribute>
+ <rng:element>
+ <rng:anyName/>
+ <rng:ref name="__anyxml__"/>
+ </rng:element>
+ <rng:text/>
+ </rng:choice>
+ </rng:zeroOrMore>
+ </rng:define>
+
+ EXAMPLE: YANG statement in a module with namespace prefix "yam"
+
+ anyxml data {
+ description "Any XML content allowed here.";
+ }
+
+ is mapped to the following fragment:
+
+ <rng:element name="yam:data">
+ <a:documentation>Any XML content allowed here</a:documentation>
+ <rng:ref name="__anyxml__"/>
+ </rng:element>
+
+ An anyxml node is optional if there is no "mandatory true;"
+ substatement. The <rng:element> element then MUST be wrapped in
+ <rng:optional>, except when the 'anyxml' statement is a child of the
+ 'choice' statement and thus forms a shorthand case for that choice
+ (see Section 9.1.1 for details).
+
+10.2. The 'argument' Statement
+
+ This statement is not mapped to the output schema, but see the rules
+ for handling extensions in Section 9.4.
+
+
+
+
+
+Lhotka Standards Track [Page 38]
+
+RFC 6110 Mapping YANG to DSDL February 2011
+
+
+10.3. The 'augment' Statement
+
+ As a substatement of 'uses', this statement is handled as a part of
+ 'uses' mapping, see Section 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.
+
+10.4. The 'base' Statement
+
+ 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.5. The 'belongs-to' Statement
+
+ This statement is not used since the processing of submodules is
+ always initiated from the main module, see Section 10.24.
+
+10.6. The 'bit' Statement
+
+ This statement is handled within the "bits" type, see
+ Section 10.53.4.
+
+10.7. The 'case' Statement
+
+ 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]).
+
+10.8. The 'choice' Statement
+
+ This statement is mapped to the <rng:choice> element.
+
+ 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
+
+
+
+
+
+Lhotka Standards Track [Page 39]
+
+RFC 6110 Mapping YANG to DSDL February 2011
+
+
+ additional handling, see Section 11.2.1. Otherwise, if "mandatory
+ true;" is not present, the <rng:choice> element MUST be wrapped in
+ <rng:optional>.
+
+ The alternatives in <rng:choice> -- mapped from either the 'case'
+ statement or a shorthand case -- MUST NOT be defined as optional.
+
+10.9. The 'config' Statement
+
+ This statement is mapped to the @nma:config attribute, and ARGUMENT
+ becomes its value.
+
+10.10. The 'contact' Statement
+
+ 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.
+
+10.11. The 'container' Statement
+
+ 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.
+
+ 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.
+
+ 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.
+
+10.12. The 'default' Statement
+
+ If this statement is a substatement of 'leaf', it is mapped to the
+ @nma:default attribute of PARENT and ARGUMENT becomes its value.
+
+ 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:
+
+
+
+
+Lhotka Standards Track [Page 40]
+
+RFC 6110 Mapping YANG to DSDL February 2011
+
+
+ o If the type definition is not expanded, @nma:default becomes an
+ attribute of the <rng:define> pattern resulting from the parent
+ 'typedef' mapping.
+
+ o Otherwise, @nma:default becomes an attribute of the ancestor RELAX
+ NG pattern inside which the expansion takes place.
+
+ Details and an example are given in Section 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.
+
+ EXAMPLE. The following 'choice' statement in a module with namespace
+ prefix "yam"
+
+ choice leaves {
+ default feuille;
+ leaf feuille { type empty; }
+ leaf hoja { type empty; }
+ }
+
+ is either mapped directly to:
+
+ <rng:choice>
+ <rng:element name="yam:feuille" nma:implicit="true">
+ <rng:empty/>
+ </rng:element>
+ <rng:element name="yam:hoja">
+ <rng:empty/>
+ </rng:element/>
+ </rng:choice>
+
+
+
+
+
+
+
+
+
+
+
+
+Lhotka Standards Track [Page 41]
+
+RFC 6110 Mapping YANG to DSDL February 2011
+
+
+ or the default case may be wrapped in an extra <rng:group>:
+
+ <rng:choice>
+ <rng:group nma:implicit="true">
+ <rng:element name="yam:feuille">
+ <rng:empty/>
+ </rng:element>
+ </rng:group>
+ <rng:element name="yam:hoja">
+ <rng:empty/>
+ </rng:element/>
+ </rng:choice>
+
+10.13. The 'description' Statement
+
+ This statement is mapped to the DTD compatibility element
+ <a:documentation> and ARGUMENT becomes its text.
+
+ In order to get properly formatted in the RELAX NG compact syntax,
+ this element SHOULD be inserted as the first child of PARENT.
+
+10.14. The 'deviation' Statement
+
+ 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.
+
+10.15. The 'enum' Statement
+
+ 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.
+
+10.16. The 'error-app-tag' Statement
+
+ 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.
+
+10.17. The 'error-message' Statement
+
+ 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.
+
+
+
+
+
+
+Lhotka Standards Track [Page 42]
+
+RFC 6110 Mapping YANG to DSDL February 2011
+
+
+10.18. The 'extension' Statement
+
+ This statement is ignored. However, extensions to the YANG language
+ MAY be mapped as described in Section 9.4.
+
+10.19. The 'feature' Statement
+
+ This statement is ignored.
+
+10.20. The 'grouping' Statement
+
+ 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.
+
+ As explained in Section 8.2, a named pattern definition MUST be
+ placed:
+
+ 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 otherwise as a child of the embedded <rng:grammar> element
+ corresponding to the module in which the grouping is defined.
+
+ 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.
+
+ 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.
+
+10.21. The 'identity' Statement
+
+ This statement is mapped to the following named pattern definition
+ which is placed as a child of the root <rng:grammar> element:
+
+
+
+
+
+
+
+
+
+Lhotka Standards Track [Page 43]
+
+RFC 6110 Mapping YANG to DSDL February 2011
+
+
+ <rng:define name="__PREFIX_ARGUMENT">
+ <rng:choice>
+ <rng:value type="QName">PREFIX:ARGUMENT</rng:value>
+ <rng:ref name="IDENTITY1"/>
+ ...
+ </rng:choice>
+ </rng:define>
+
+ where:
+
+ PREFIX is the prefix used in the hybrid schema for the namespace
+ of the module where the current identity is defined.
+
+ 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.
+
+ EXAMPLE ([RFC6020], Section 7.16.3). Consider the following
+ identities defined in two input YANG modules:
+
+ 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";
+ }
+ }
+
+
+
+
+
+
+Lhotka Standards Track [Page 44]
+
+RFC 6110 Mapping YANG to DSDL February 2011
+
+
+ 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>
+
+10.22. The 'if-feature' Statement
+
+ 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.
+
+10.23. The 'import' Statement
+
+ 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.
+
+ 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.
+
+10.24. The 'include' Statement
+
+ 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.
+
+
+
+
+
+Lhotka Standards Track [Page 45]
+
+RFC 6110 Mapping YANG to DSDL February 2011
+
+
+10.25. The 'input' Statement
+
+ This statement is handled within 'rpc' statement, see Section 10.50.
+
+10.26. The 'key' Statement
+
+ 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.
+
+10.27. The 'leaf' Statement
+
+ This statement is mapped to the <rng:element> element and ARGUMENT
+ with prepended local namespace prefix becomes the value of its @name
+ attribute.
+
+ 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).
+
+10.28. The 'leaf-list' Statement
+
+ This statement is mapped to a block enclosed by either the <rng:
+ zeroOrMore> or the <rng:oneOrMore> element depending on whether the
+ argument of 'min-elements' substatement is "0" or positive,
+ respectively (it is zero by default). This <rng:zeroOrMore> or <rng:
+ oneOrMore> element becomes the PARENT.
+
+ <rng: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.
+
+
+
+
+
+
+
+
+Lhotka Standards Track [Page 46]
+
+RFC 6110 Mapping YANG to DSDL February 2011
+
+
+ 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:
+
+ <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>
+
+10.29. The 'length' Statement
+
+ This statement is handled within the "string" type, see
+ Section 10.53.10.
+
+10.30. The 'list' Statement
+
+ 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".
+
+ 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.
+
+ For example, consider the following YANG fragment of a module with
+ the prefix "yam":
+
+
+
+
+
+
+
+Lhotka Standards Track [Page 47]
+
+RFC 6110 Mapping YANG to DSDL February 2011
+
+
+ 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:
+
+ <rng:zeroOrMore>
+ <rng:element name="yam:foo" nma:key="yam:clef">
+ <rng:element name="yam:clef">
+ <rng:data type="unsignedByte"/>
+ </rng:element>
+ <rng:interleave>
+ <rng:element name="yam:bar">
+ <rng:data type="string"/>
+ </rng:element>
+ <rng:element name="yam:baz">
+ <rng:data type="string"/>
+ </rng:element>
+ </rng:interleave>
+ </rng:element>
+ </rng:zeroOrMore>
+
+ Note that the "keygrp" grouping is expanded and the definition of
+ "yam:clef" is moved before the <rng:interleave> pattern.
+
+10.31. The 'mandatory' Statement
+
+ 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.
+
+ 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.
+
+
+
+
+
+Lhotka Standards Track [Page 48]
+
+RFC 6110 Mapping YANG to DSDL February 2011
+
+
+10.32. The 'max-elements' Statement
+
+ This statement is handled within 'leaf-list' or 'list' statements,
+ see Section 10.28.
+
+10.33. The 'min-elements' Statement
+
+ This statement is handled within 'leaf-list' or 'list' statements,
+ see Section 10.28.
+
+10.34. The 'module' Statement
+
+ 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.
+
+ 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 statements representing the contents of RPC requests or replies
+ are mapped to descendants of the <nma:rpcs> element;
+
+ o statements representing the contents of event notifications are
+ mapped to descendants of the <nma:notifications> element.
+
+10.35. The 'must' Statement
+
+ 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.
+
+ EXAMPLE. YANG statement in the "dhcp" module
+
+ must 'current() <= ../max-lease-time' {
+ error-message
+ "The default-lease-time must be less than max-lease-time";
+ }
+
+
+
+
+
+
+Lhotka Standards Track [Page 49]
+
+RFC 6110 Mapping YANG to DSDL February 2011
+
+
+ is mapped to:
+
+ <nma:must assert="current()&lt;=../dhcp:max-lease-time">
+ <nma:error-message>
+ The default-lease-time must be less than max-lease-time
+ </nma:error-message>
+ </nma:must>
+
+10.36. The 'namespace' Statement
+
+ This statement is mapped simultaneously in two ways:
+
+ 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;
+
+ 2. to the @ns attribute of PARENT, which is an embedded <rng:
+ grammar> pattern. ARGUMENT becomes the value of this attribute.
+
+10.37. The 'notification' Statement
+
+ 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:notification>
+ <rng:element name="PREFIX:ARGUMENT">
+ ...
+ </rng:element>
+ </nma:notification>
+
+ Substatements of 'notification' are mapped under <rng:element
+ name="PREFIX:ARGUMENT">.
+
+10.38. The 'ordered-by' Statement
+
+ This statement is mapped to @nma:ordered-by attribute and ARGUMENT
+ becomes the value of this attribute. See Section 10.28 for an
+ example.
+
+10.39. The 'organization' Statement
+
+ 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.
+
+
+
+
+Lhotka Standards Track [Page 50]
+
+RFC 6110 Mapping YANG to DSDL February 2011
+
+
+ The original YANG modules are the authoritative sources of the
+ authorship information.
+
+10.40. The 'output' Statement
+
+ This statement is handled within the 'rpc' statement, see
+ Section 10.50.
+
+10.41. The 'path' Statement
+
+ This statement is handled within the "leafref" type, see
+ Section 10.53.8.
+
+10.42. The 'pattern' Statement
+
+ This statement is handled within the "string" type, see
+ Section 10.53.10.
+
+10.43. The 'position' Statement
+
+ This statement is ignored.
+
+10.44. The 'prefix' Statement
+
+ 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.45. The 'presence' Statement
+
+ 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.46. The 'range' Statement
+
+ This statement is handled within numeric types, see Section 10.53.9.
+
+10.47. The 'reference' Statement
+
+ This statement is mapped to <a:documentation> element and its text is
+ set to ARGUMENT prefixed with "See: ".
+
+10.48. The 'require-instance' Statement
+
+ This statement is handled within "instance-identifier" type
+ (Section 10.53.7).
+
+
+
+Lhotka Standards Track [Page 51]
+
+RFC 6110 Mapping YANG to DSDL February 2011
+
+
+10.49. The 'revision' Statement
+
+ 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:
+
+ <dc:source>YANG module 'foo', revision 2010-03-02</dc:source>
+
+ The 'description' substatement of 'revision' is ignored.
+
+10.50. The 'rpc' Statement
+
+ This statement is mapped to the following subtree in the RELAX NG
+ schema (where PREFIX is the prefix of the local YANG module):
+
+ <nma:rpc>
+ <nma:input>
+ <rng:element name="PREFIX:ARGUMENT">
+ ... mapped contents of 'input' ...
+ </rng:element>
+ </nma:input>
+ <nma:output">
+ ... mapped contents of 'output' ...
+ </nma:output>
+ </nma:rpc>
+
+ As indicated in the schema fragment, contents of the 'input'
+ substatement (if any) are mapped under <rng:element name="PREFIX:
+ ARGUMENT">. Similarly, contents of the 'output' substatement are
+ mapped under <nma:output>. If there is no 'output' substatement, the
+ <nma:output> element MUST NOT be present.
+
+ The <nma:rpc> element is a child of <nma:rpcs>.
+
+10.51. The 'status' Statement
+
+ This statement MAY be ignored. Otherwise, it is mapped to @nma:
+ status attribute and ARGUMENT becomes its value.
+
+10.52. The 'submodule' Statement
+
+ This statement is not specifically mapped. Its substatements are
+ mapped as if they appeared directly in the module to which the
+ submodule belongs.
+
+
+
+
+Lhotka Standards Track [Page 52]
+
+RFC 6110 Mapping YANG to DSDL February 2011
+
+
+10.53. The 'type' Statement
+
+ Most YANG built-in data types have an equivalent in the XSD data type
+ library [XSD-D] as shown in Table 4.
+
+ +-----------+---------------+--------------------------------+
+ | 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
+
+ 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.
+
+ Details about the mapping of individual YANG built-in types are given
+ in the following subsections.
+
+
+
+
+
+
+
+
+Lhotka Standards Track [Page 53]
+
+RFC 6110 Mapping YANG to DSDL February 2011
+
+
+10.53.1. The "empty" Type
+
+ This type is mapped to <rng:empty/>.
+
+10.53.2. The "boolean" Type
+
+ This built-in type does not allow any restrictions and is mapped to
+ the following XML fragment:
+
+ <rng:choice>
+ <rng:value>true</rng:value>
+ <rng:value>false</rng:value>
+ </rng:choice>
+
+ Note that the XSD "boolean" type cannot be used here because it
+ allows, unlike YANG, an alternative numeric representation of boolean
+ values: 0 for "false" and 1 for "true".
+
+10.53.3. The "binary" Type
+
+ 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).
+
+10.53.4. The "bits" Type
+
+ 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:optional>
+ <rng:value>bit_name</rng:value>
+ </rng:optional>
+
+ where bit_name is the name of the bit as found in the argument of a
+ 'bit' substatement.
+
+10.53.5. The "enumeration" and "union" Types
+
+ These types are mapped to the <rng:choice> element.
+
+10.53.6. The "identityref" Type
+
+ This type is mapped to the following named pattern reference:
+
+ <rng:ref name="__PREFIX_BASE"/>
+
+ where PREFIX:BASE is the qualified name of the identity appearing in
+ the argument of the 'base' substatement.
+
+
+
+Lhotka Standards Track [Page 54]
+
+RFC 6110 Mapping YANG to DSDL February 2011
+
+
+ For example, assume that module "des" in Section 10.21 contains the
+ following leaf definition:
+
+ leaf foo {
+ type identityref {
+ base crypto:crypto-alg;
+ }
+ }
+
+ This leaf would then be mapped to the following element pattern:
+
+ <element name="des:foo">
+ <ref name="__crypto_crypto-alg"/>
+ </element>
+
+10.53.7. The "instance-identifier" Type
+
+ 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.
+
+ The argument of the 'require-instance' substatement, if it exists,
+ becomes the value of the @require-instance attribute of the <nma:
+ instance-identifier> element.
+
+10.53.8. The "leafref" Type
+
+ 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.
+
+10.53.9. The Numeric Types
+
+ 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.
+
+ 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:
+
+
+
+
+Lhotka Standards Track [Page 55]
+
+RFC 6110 Mapping YANG to DSDL February 2011
+
+
+ o "totalDigits" facet set to the value of 19.
+
+ o "fractionDigits" facet set to the argument of the 'fraction-
+ digits' substatement.
+
+ The fixed value of "totalDigits" corresponds to the maximum of 19
+ decimal digits for 64-bit integers.
+
+ For example, the statement:
+
+ type decimal64 {
+ fraction-digits 2;
+ }
+
+ is mapped to the following RELAX NG data type:
+
+ <rng:data type="decimal">
+ <rng:param name="totalDigits">19</rng:param>
+ <rng:param name="fractionDigits">2</rng:param>
+ </rng:data>
+
+ All numeric types support the 'range' restriction, which is mapped as
+ follows:
+
+ If the range expression consists of just a single range LO..HI, then
+ it is mapped to a pair of data type facets:
+
+ <rng:param name="minInclusive">LO</rng:param>
+
+ and
+
+ <rng:param name="maxInclusive">HI</rng:param>
+
+ If the range consists of a single number, the values of both facets
+ are set to this value. If LO is equal to the string "min", the
+ "minInclusive" facet is omitted. If HI is equal to the string "max",
+ the "maxInclusive" facet is omitted.
+
+ 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.
+
+ For the "decimal64" type, the "totalDigits" and "fractionDigits" must
+ be repeated inside each of the <rng:data> elements.
+
+
+
+
+Lhotka Standards Track [Page 56]
+
+RFC 6110 Mapping YANG to DSDL February 2011
+
+
+ For example,
+
+ type int32 {
+ range "-6378..0|42|100..max";
+ }
+
+ is mapped to the following RELAX NG fragment:
+
+ <rng:choice>
+ <rng:data type="int">
+ <rng:param name="minInclusive">-6378</rng:param>
+ <rng:param name="maxInclusive">0</rng:param>
+ </rng:data>
+ <rng:data type="int">
+ <rng:param name="minInclusive">42</rng:param>
+ <rng:param name="maxInclusive">42</rng:param>
+ </rng:data>
+ <rng:data type="int">
+ <rng:param name="minInclusive">100</rng:param>
+ </rng:data>
+ </rng:choice>
+
+ See Section 9.2.2 for further details on mapping the restrictions.
+
+10.53.10. The "string" Type
+
+ This type is mapped to the <rng:data> element with the @type
+ attribute set to "string".
+
+ The 'length' restriction is handled analogically to the 'range'
+ restriction for the numeric types (Section 10.53.9):
+
+ If the length expression has just a single range:
+
+ o and if the length range consists of a single number LENGTH, the
+ following data type facet is inserted:
+
+ <rng:param name="length">LENGTH</rng:param>.
+
+ o if the length range is of the form LO..HI, i.e., it consists of
+ both the lower and upper bound. The following two data type
+ facets are then inserted:
+
+ <rng:param name="minLength">LO</rng:param>
+
+ and
+
+ <rng:param name="maxLength">HI</rng:param>
+
+
+
+Lhotka Standards Track [Page 57]
+
+RFC 6110 Mapping YANG to DSDL February 2011
+
+
+ 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.
+
+ 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.
+
+ Every 'pattern' restriction of the "string" data type is mapped to
+ the "pattern" facet:
+
+ <rng:param name="pattern">...</rng:param>
+
+ with text equal to the argument of the 'pattern' statement. All such
+ "pattern" facets must be repeated inside each copy of the <rng:data>
+ element, i.e., once for each length range.
+
+ For example,
+
+ type string {
+ length "1|3..8";
+ pattern "[A-Z][a-z]*";
+ }
+
+ is mapped to the following RELAX NG fragment:
+
+ <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>
+
+10.53.11. Derived Types
+
+ 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:
+
+
+
+
+
+
+Lhotka Standards Track [Page 58]
+
+RFC 6110 Mapping YANG to DSDL February 2011
+
+
+ 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.
+
+ 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.
+
+ See Section 9.2.2 for more details and an example.
+
+10.54. The 'typedef' Statement
+
+ 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.
+
+ 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.
+
+ 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.
+
+10.55. The 'unique' Statement
+
+ 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.
+
+
+
+Lhotka Standards Track [Page 59]
+
+RFC 6110 Mapping YANG to DSDL February 2011
+
+
+ For example, assuming that the local module prefix is "ex",
+
+ unique "foo ex:bar/baz"
+
+ is mapped to the following attribute/value pair:
+
+ nma:unique="ex:foo ex:bar/ex:baz"
+
+10.56. The 'units' Statement
+
+ This statement is mapped to the @nma:units attribute and ARGUMENT
+ becomes its value.
+
+10.57. The 'uses' Statement
+
+ 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.
+
+ 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.
+
+10.58. The 'value' Statement
+
+ This statement is ignored.
+
+10.59. The 'when' Statement
+
+ This statement is mapped to the @nma:when attribute and ARGUMENT,
+ translated according to Section 9.3, becomes it value.
+
+10.60. The 'yang-version' Statement
+
+ 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.
+
+
+
+
+
+
+
+Lhotka Standards Track [Page 60]
+
+RFC 6110 Mapping YANG to DSDL February 2011
+
+
+10.61. The 'yin-element' Statement
+
+ This statement is not mapped to the output schema, but see the rules
+ for extension handling in Section 9.4.
+
+11. Mapping the Hybrid Schema to DSDL
+
+ 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.
+
+ The second mapping step has to accomplish the following three general
+ tasks:
+
+ 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.
+
+ 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.
+
+ 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.
+
+ These three tasks are together much simpler than the first mapping
+ step and can be effectively implemented using XSL transformations
+ [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.
+
+11.1. Generating RELAX NG Schemas for Various Document Types
+
+ 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.
+
+
+
+
+Lhotka Standards Track [Page 61]
+
+RFC 6110 Mapping YANG to DSDL February 2011
+
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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.
+
+11.2. Mapping Semantic Constraints to Schematron
+
+ 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>.
+
+ 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).
+
+ 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:
+
+ <sch:rule context="XELEM">
+ ...
+ </sch:rule>
+
+
+
+
+Lhotka Standards Track [Page 62]
+
+RFC 6110 Mapping YANG to DSDL February 2011
+
+
+ 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.
+
+ 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).
+
+ When the abstract pattern is instantiated, the values of the
+ following two parameters MUST be provided:
+
+ o pref: the actual namespace prefix,
+
+ o start: XPath expression defining the context in which the grouping
+ is used.
+
+ EXAMPLE. Consider the following YANG module:
+
+ 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;
+ }
+ }
+ }
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lhotka Standards Track [Page 63]
+
+RFC 6110 Mapping YANG to DSDL February 2011
+
+
+ The resulting Schematron schema for a reply to <nc:get> is then as
+ follows:
+
+ <?xml version="1.0" encoding="utf-8"?>
+ <sch:schema xmlns:sch="http://purl.oclc.org/dsdl/schematron">
+ <sch:ns uri="http://example.com/ns/example4" prefix="ex4"/>
+ <sch:ns uri="urn:ietf:params:xml:ns:netconf:base:1.0"
+ prefix="nc"/>
+ <sch:pattern abstract="true"
+ id="_example4__sorted-leaf-list">
+ <sch:rule context="$start/$pref:sorted-entry">
+ <sch:report
+ test=". = preceding-sibling::$pref:sorted-entry">
+ Duplicate leaf-list entry "<sch:value-of select="."/>".
+ </sch:report>
+ <sch:assert
+ test="not(preceding-sibling::$pref:sorted-entry &gt; .)">
+ Entries must appear in ascending order.
+ </sch:assert>
+ </sch:rule>
+ </sch:pattern>
+ <sch:pattern id="example4"/>
+ <sch:pattern id="id2573371" is-a="_example4__sorted-leaf-list">
+ <sch:param name="start" value="/nc:rpc-reply/nc:data"/>
+ <sch:param name="pref" value="ex4"/>
+ </sch:pattern>
+ </sch:schema>
+
+ The "sorted-leaf-list" grouping from the input module is mapped to an
+ abstract pattern with an @id value of "_example4__sorted-leaf-list"
+ in which the 'must' statement corresponds to the <sch:assert>
+ element. The abstract pattern is the instantiated by the pattern
+ with an @id value of "id2573371", which sets the "start" and "pref"
+ parameters to appropriate values.
+
+ Note that another Schematron element, <sch:report>, was automatically
+ added, checking for duplicate leaf-list entries.
+
+ The mapping from the hybrid schema to Schematron proceeds in the
+ following steps:
+
+ 1. First, the active subtree(s) of the hybrid schema must be
+ selected depending on the requested target document type. This
+ procedure is identical to the RELAX NG case, including the
+ handling of @nma:config if the target document type is <nc:get-
+ config> reply.
+
+
+
+
+
+Lhotka Standards Track [Page 64]
+
+RFC 6110 Mapping YANG to DSDL February 2011
+
+
+ 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:
+
+ <sch:ns uri="http://example.com/ns/example4" prefix="ex4"/>
+
+ 3. One pattern is created for every input module. In addition, an
+ abstract pattern is created for every named pattern definition
+ containing one or more semantic annotations.
+
+ 4. A <sch:rule> element is created for each element pattern
+ containing semantic annotations.
+
+ 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.
+
+11.2.1. Constraints on Mandatory Choice
+
+ 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.
+
+ 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;
+ }
+ }
+ }
+
+
+
+
+
+
+
+
+Lhotka Standards Track [Page 65]
+
+RFC 6110 Mapping YANG to DSDL February 2011
+
+
+ In this module, all three leaf nodes in both case branches are
+ optional but because of the "mandatory true;" statement, at least one
+ of them must be present in a valid configuration. The 'choice'
+ statement from this module is mapped to the following fragment of the
+ RELAX NG schema:
+
+ <rng:choice>
+ <rng:interleave>
+ <rng:optional>
+ <rng:element name="ex5:foo1">
+ <rng:data type="unsignedByte"/>
+ </rng:element>
+ </rng:optional>
+ <rng:optional>
+ <rng:element name="ex5:foo2">
+ <rng:data type="unsignedByte"/>
+ </rng:element>
+ </rng:optional>
+ </rng:interleave>
+ <rng:element name="ex5:bar">
+ <rng:data type="unsignedByte"/>
+ </rng:element>
+ </rng:choice>
+
+ In the second case branch, the "ex5:bar" element is defined as
+ mandatory so that this element must be present in a valid
+ configuration if this branch is selected. However, the two elements
+ in the first branch "foo" cannot be both declared as mandatory since
+ each of them alone suffices for a valid configuration. As a result,
+ the above RELAX NG fragment would successfully validate
+ configurations where none of the three leaf elements are present.
+
+ 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.).
+
+ For the example module above, the Schematron rule will be as follows:
+
+ <sch:rule context="/nc:rpc-reply/nc:data">
+ <sch:assert test="ex5:foo1 or ex5:foo2 or ex5:bar">
+ Node(s) from at least one case of choice "foobar" must exist.
+ </sch:assert>
+ </sch:rule>
+
+
+
+Lhotka Standards Track [Page 66]
+
+RFC 6110 Mapping YANG to DSDL February 2011
+
+
+11.3. Mapping Default Values to DSRL
+
+ 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.
+
+ 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]:
+
+ o the <dsrl:parent> element contains an XSLT pattern specifying the
+ parent element; the default contents are applied only if the
+ parent element exists in the instance document;
+
+ o 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>.
+
+ 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 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:
+
+ <rng:element name="ELEM" nma:default="DEFVALUE">
+ ...
+ </rng:element>
+
+ or
+
+ <rng:element name="ELEM" nma:implicit="true">
+ ...
+ </rng:element>
+
+ The former case applies to leaf nodes having the 'default'
+ substatement, but also to leaf nodes that obtain their default value
+ from a typedef, if this typedef is expanded according to the rules in
+ Section 9.2.2 so that the @nma:default annotation is attached
+ directly to the leaf's element pattern.
+
+
+
+
+Lhotka Standards Track [Page 67]
+
+RFC 6110 Mapping YANG to DSDL February 2011
+
+
+ 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.
+
+ In the simplest case, both element patterns are mapped to the
+ following DSRL element map:
+
+ <dsrl:element-map>
+ <dsrl:parent>XPARENT</dsrl:parent>
+ <dsrl:name>ELEM</dsrl:name>
+ <dsrl:default-content>DEFCONT</dsrl:default-content>
+ </dsrl:element-map>
+
+ where XPARENT is the absolute XPath of ELEM's parent element in the
+ data tree and DEFCONT is constructed as follows:
+
+ o If the implicit node ELEM is a leaf and has the @nma:default
+ attribute, DEFCONT is set to the value of this attribute (denoted
+ above as DEFVALUE).
+
+ o If the implicit node ELEM is a leaf and has the @nma:implicit
+ attribute with the value of "true", the default value has to be
+ determined from the @nma:default attribute of the definition of
+ ELEM's type (perhaps recursively) and used in place of DEFCONT in
+ the above DSRL element map. See also Section 9.2.2.
+
+ o 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.
+
+ In addition, when mapping the default case of a choice, it has to be
+ guaranteed that the default contents are not applied if any node from
+ any non-default case is present. This is accomplished by setting
+ <dsrl:parent> in a special way:
+
+ <dsrl:parent>XPARENT[not (ELEM1|ELEM2|...|ELEMn)]</dsrl:parent>
+
+ where ELEM1, ELEM2, ... ELEMn are the names of all top-level nodes
+ from all non-default cases. The rest of the element map is exactly
+ as before.
+
+
+
+
+
+
+
+
+
+
+Lhotka Standards Track [Page 68]
+
+RFC 6110 Mapping YANG to DSDL February 2011
+
+
+ EXAMPLE. Consider the following YANG module:
+
+ 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;
+ }
+ }
+ }
+ }
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lhotka Standards Track [Page 69]
+
+RFC 6110 Mapping YANG to DSDL February 2011
+
+
+ The DSRL schema generated for the "get-reply" target document type
+ will be:
+
+ <?xml version="1.0" encoding="utf-8"?>
+ <dsrl:maps xmlns:dsrl="http://purl.oclc.org/dsdl/dsrl"
+ xmlns:ex6="http://example.com/ns/example6"
+ xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
+ <dsrl:element-map>
+ <dsrl:parent>/nc:rpc-reply/nc:data</dsrl:parent>
+ <dsrl:name>ex6:outer</dsrl:name>
+ <dsrl:default-content>
+ <ex6:leaf1>1</ex6:leaf1>
+ <ex6:one>
+ <ex6:leaf2>2</ex6:leaf2>
+ </ex6:one>
+ </dsrl:default-content>
+ </dsrl:element-map>
+ <dsrl:element-map>
+ <dsrl:parent>/nc:rpc-reply/nc:data/ex6:outer</dsrl:parent>
+ <dsrl:name>ex6:leaf1</dsrl:name>
+ <dsrl:default-content>1</dsrl:default-content>
+ </dsrl:element-map>
+ <dsrl:element-map>
+ <dsrl:parent>
+ /nc:rpc-reply/nc:data/ex6:outer[not(ex6:leaf3)]
+ </dsrl:parent>
+ <dsrl:name>ex6:one</dsrl:name>
+ <dsrl:default-content>
+ <ex6:leaf2>2</ex6:leaf2>
+ </dsrl:default-content>
+ </dsrl:element-map>
+ <dsrl:element-map>
+ <dsrl:parent>
+ /nc:rpc-reply/nc:data/ex6:outer/ex6:one
+ </dsrl:parent>
+ <dsrl:name>ex6:leaf2</dsrl:name>
+ <dsrl:default-content>2</dsrl:default-content>
+ </dsrl:element-map>
+ </dsrl:maps>
+
+ Note that the default value for "leaf3" defined in the YANG module is
+ ignored because "leaf3" represents a non-default alternative of a
+ choice and as such never becomes an implicit element.
+
+
+
+
+
+
+
+
+Lhotka Standards Track [Page 70]
+
+RFC 6110 Mapping YANG to DSDL February 2011
+
+
+12. Mapping NETMOD-Specific Annotations to DSDL Schema Languages
+
+ 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.
+
+12.1. The @nma:config Annotation
+
+ If this annotation is present with the value of "false", the
+ following rules MUST be observed for DSDL schemas of <nc:get-config>
+ reply:
+
+ o When generating RELAX NG, the contents of the CONTELEM definition
+ MUST be changed to <rng:notAllowed>.
+
+ o When generating Schematron or DSRL, the CONTELEM definition and
+ all its descendants in the hybrid schema MUST be ignored.
+
+12.2. The @nma:default Annotation
+
+ This annotation is used for generating the DSRL schema as described
+ in Section 11.3.
+
+12.3. The <nma:error-app-tag> Annotation
+
+ This annotation currently has no mapping defined.
+
+12.4. The <nma:error-message> Annotation
+
+ This annotation is handled within <nma:must>, see Section 12.13.
+
+12.5. The @if-feature Annotation
+
+ The information about available features MAY be supplied as an input
+ parameter to an implementation. In this case, the following changes
+ MUST be performed for all features that are considered unavailable:
+
+ o When generating RELAX NG, the contents of the CONTELEM definition
+ MUST be changed to <rng:notAllowed>.
+
+ o When generating Schematron or DSRL, the CONTELEM definition and
+ all its descendants in the hybrid schema MUST be ignored.
+
+
+
+
+
+Lhotka Standards Track [Page 71]
+
+RFC 6110 Mapping YANG to DSDL February 2011
+
+
+12.6. The @nma:implicit Annotation
+
+ This annotation is used for generating the DSRL schema as described
+ in Section 11.3.
+
+12.7. The <nma:instance-identifier> Annotation
+
+ 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:
+
+ <sch:assert test="nmf:evaluate(.)">
+ The element pointed to by "CONTELEM" must exist.
+ </sch:assert>
+
+ The nmf:evaluate() function is an XSLT extension function (see
+ Extension Functions in [XSLT]) that evaluates an XPath expression at
+ run time. Such an extension function is available in Extended XSLT
+ (EXSLT) or provided as a proprietary extension by some XSLT
+ processors, for example Saxon.
+
+12.8. The @nma:key Annotation
+
+ 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:
+
+ <sch:report test="CONDITION">
+ Duplicate key of list "CONTELEM"
+ </sch:report>
+
+ where CONDITION has this form:
+ preceding-sibling::CONTELEM[C_1 and C_2 and ... and C_n]
+
+ Each sub-expression C_i, for i=1,2,...,n, specifies the condition for
+ violated uniqueness of the key k_i, namely
+
+ k_i=current()/k_i
+
+12.9. The @nma:leaf-list Annotation
+
+ This annotation is mapped to the following Schematron rule, which
+ detects duplicate entries of a leaf-list:
+
+ <sch:report
+ test=". = preceding-sibling::PREFIX:sorted-entry">
+ Duplicate leaf-list entry "<sch:value-of select="."/>".
+ </sch:report>
+
+
+
+Lhotka Standards Track [Page 72]
+
+RFC 6110 Mapping YANG to DSDL February 2011
+
+
+ See Section 11.2 for a complete example.
+
+12.10. The @nma:leafref Annotation
+
+ This annotation is mapped to the following assert:
+
+ <sch:assert test="PATH=.">
+ Leaf "PATH" does not exist for leafref value "VALUE"
+ </sch:assert>
+
+ where PATH is the value of @nma:leafref and VALUE is the value of the
+ context element in the instance document for which the referred leaf
+ doesn't exist.
+
+12.11. The @nma:min-elements Annotation
+
+ This annotation is mapped to the following Schematron assert:
+
+ <sch:assert test="count(../CONTELEM)&gt;=MIN">
+ List "CONTELEM" - item count must be at least MIN
+ </sch:assert>
+
+ where MIN is the value of @nma:min-elements.
+
+12.12. The @nma:max-elements Annotation
+
+ This annotation is mapped to the following Schematron assert:
+
+<sch:assert
+ test="count(../CONTELEM)&lt;=MAX or preceding-sibling::../CONTELEM">
+ Number of list items must be at most MAX
+</sch:assert>
+
+ where MAX is the value of @nma:min-elements.
+
+12.13. The <nma:must> Annotation
+
+ This annotation is mapped to the following Schematron assert:
+
+ <sch:assert test="EXPRESSION">
+ MESSAGE
+ </sch:assert>
+
+ where EXPRESSION is the value of the mandatory @assert attribute of
+ <nma:must>. If the <nma:error-message> subelement exists, MESSAGE is
+ set to its contents; otherwise, it is set to the default message
+ "Condition EXPRESSION must be true".
+
+
+
+
+Lhotka Standards Track [Page 73]
+
+RFC 6110 Mapping YANG to DSDL February 2011
+
+
+12.14. The <nma:ordered-by> Annotation
+
+ This annotation currently has no mapping defined.
+
+12.15. The <nma:status> Annotation
+
+ This annotation currently has no mapping defined.
+
+12.16. The @nma:unique Annotation
+
+ The mapping of this annotation is almost identical as for @nma:key,
+ see Section 12.8, with two small differences:
+
+ o The value of @nma:unique is a list of descendant schema node
+ identifiers rather than simple leaf names. However, the XPath
+ expressions specified in Section 12.8 work without any
+ modifications if the descendant schema node identifiers are
+ substituted for k_1, k_2, ..., k_n.
+
+ o The message appearing as the text of <sch:report> is different:
+ "Violated uniqueness for list CONTELEM".
+
+12.17. The @nma:when Annotation
+
+ This annotation is mapped to the following Schematron assert:
+
+ <sch:assert test="EXPRESSION">
+ Node "CONTELEM" is only valid when "EXPRESSION" is true.
+ </sch:assert>
+
+ where EXPRESSION is the value of @nma:when.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lhotka Standards Track [Page 74]
+
+RFC 6110 Mapping YANG to DSDL February 2011
+
+
+13. IANA Considerations
+
+ This document requests the following two registrations of namespace
+ URIs in the IETF XML registry [RFC3688]:
+
+ -----------------------------------------------------
+ URI: urn:ietf:params:xml:ns:netmod:dsdl-annotations:1
+
+ Registrant Contact: The 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.
+
+ XML: N/A, the requested URI is an XML namespace.
+ -----------------------------------------------------
+
+14. Security Considerations
+
+ 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 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.
+
+15. Contributors
+
+ The following people contributed significantly to the initial version
+ of this document:
+
+ o Rohan Mahy
+
+ o Sharon Chisholm (Ciena)
+
+
+
+
+
+
+
+
+
+Lhotka Standards Track [Page 75]
+
+RFC 6110 Mapping YANG to DSDL February 2011
+
+
+16. Acknowledgments
+
+ 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.
+
+17. References
+
+17.1. Normative References
+
+ [DSDL] ISO/IEC, "Document Schema Definition Languages (DSDL)
+ - Part 1: Overview", ISO/IEC 19757-1, November 2004.
+
+ [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.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81,
+ RFC 3688, January 2004.
+
+ [RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741,
+ December 2006.
+
+ [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language
+ for Network Configuration Protocol (NETCONF)",
+ RFC 6020, October 2010.
+
+ [RFC6021] Schoenwaelder, J., Ed., "Common YANG Data Types",
+ RFC 6021, October 2010.
+
+ [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-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.
+
+
+
+
+
+
+Lhotka Standards Track [Page 76]
+
+RFC 6110 Mapping YANG to DSDL February 2011
+
+
+ [RNG-DTD] Clark, J., Ed. and M. Murata, Ed., "RELAX NG DTD
+ Compatibility", OASIS Committee Specification, 3
+ December 2001.
+
+ [Schematron] ISO/IEC, "Information Technology - Document Schema
+ Definition Languages (DSDL) - Part 3: Rule-Based
+ Validation - Schematron", ISO/IEC 19757-3:2006(E),
+ June 2006.
+
+ [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-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>.
+
+ [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>.
+
+ [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>.
+
+ [XSLT] Clark, J., "XSL Transformations (XSLT) Version 1.0",
+ World Wide Web Consortium Recommendation REC-xslt-
+ 19991116, November 1999.
+
+17.2. Informative References
+
+ [DHCPtut] Bjorklund, M., "DHCP Tutorial", November 2007, <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.
+
+
+
+
+
+
+
+Lhotka Standards Track [Page 77]
+
+RFC 6110 Mapping YANG to DSDL February 2011
+
+
+ [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.
+ Schoenwaelder, Ed., "Structure of Management
+ Information Version 2 (SMIv2)", STD 58, RFC 2578,
+ April 1999.
+
+ [RFC5013] Kunze, J., "The Dublin Core Metadata Element Set",
+ RFC 5013, August 2007.
+
+ [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event
+ Notifications", RFC 5277, July 2008.
+
+ [Trang] Clark, J., "Trang: Multiformat schema converter based
+ on RELAX NG", 2008,
+ <http://www.thaiopensource.com/relaxng/trang.html>.
+
+ [Vli04] van der Vlist, E., "RELAX NG", O'Reilly, 2004.
+
+ [XSD] Thompson, H., Beech, D., Maloney, M., and N.
+ Mendelsohn, "XML Schema Part 1: Structures Second
+ Edition", World Wide Web Consortium
+ Recommendation REC-xmlschema-1-20041028, October 2004,
+ <http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>.
+
+ [pyang] Bjorklund, M. and L. Lhotka, "pyang: An extensible
+ YANG validator and converter in Python", 2010,
+ <http://code.google.com/p/pyang/>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lhotka Standards Track [Page 78]
+
+RFC 6110 Mapping YANG to DSDL February 2011
+
+
+Appendix A. RELAX NG Schema for NETMOD-Specific Annotations
+
+ This appendix defines the content model for all NETMOD-specific
+ annotations in the form of RELAX NG named pattern definitions.
+
+ <CODE BEGINS> file "nmannot.rng"
+
+ <?xml version="1.0" encoding="UTF-8"?>
+ <grammar xmlns="http://relaxng.org/ns/structure/1.0"
+ xmlns:nma="urn:ietf:params:xml:ns:netmod:dsdl-annotations:1"
+ datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes">
+
+ <define name="config-attribute">
+ <attribute name="nma:config">
+ <data type="boolean"/>
+ </attribute>
+ </define>
+
+ <define name="data-element">
+ <element name="nma:data">
+ <ref name="__anyxml__"/>
+ </element>
+ </define>
+
+ <define name="default-attribute">
+ <attribute name="nma:default">
+ <data type="string"/>
+ </attribute>
+ </define>
+
+ <define name="error-app-tag-element">
+ <element name="nma:error-app-tag">
+ <text/>
+ </element>
+ </define>
+
+ <define name="error-message-element">
+ <element name="nma:error-message">
+ <text/>
+ </element>
+ </define>
+
+
+
+
+
+
+
+
+
+
+Lhotka Standards Track [Page 79]
+
+RFC 6110 Mapping YANG to DSDL February 2011
+
+
+ <define name="if-feature-attribute">
+ <attribute name="nma:if-feature">
+ <list>
+ <data type="QName"/>
+ </list>
+ </attribute>
+ </define>
+
+ <define name="implicit-attribute">
+ <attribute name="nma:implicit">
+ <data type="boolean"/>
+ </attribute>
+ </define>
+
+ <define name="instance-identifier-element">
+ <element name="nma:instance-identifier">
+ <optional>
+ <attribute name="nma:require-instance">
+ <data type="boolean"/>
+ </attribute>
+ </optional>
+ </element>
+ </define>
+
+ <define name="key-attribute">
+ <attribute name="nma:key">
+ <list>
+ <data type="QName"/>
+ </list>
+ </attribute>
+ </define>
+
+ <define name="leaf-list-attribute">
+ <attribute name="nma:leaf-list">
+ <data type="boolean"/>
+ </attribute>
+ </define>
+
+ <define name="leafref-attribute">
+ <attribute name="nma:leafref">
+ <data type="string"/>
+ </attribute>
+ </define>
+
+
+
+
+
+
+
+
+Lhotka Standards Track [Page 80]
+
+RFC 6110 Mapping YANG to DSDL February 2011
+
+
+ <define name="mandatory-attribute">
+ <attribute name="nma:mandatory">
+ <data type="Name"/>
+ </attribute>
+ </define>
+
+ <define name="max-elements-attribute">
+ <attribute name="nma:max-elements">
+ <data type="nonNegativeInteger"/>
+ </attribute>
+ </define>
+
+ <define name="min-elements-attribute">
+ <attribute name="nma:min-elements">
+ <data type="nonNegativeInteger"/>
+ </attribute>
+ </define>
+
+ <define name="module-attribute">
+ <attribute name="nma:module">
+ <data type="Name"/>
+ </attribute>
+ </define>
+
+ <define name="must-element">
+ <element name="nma:must">
+ <attribute name="assert">
+ <data type="string"/>
+ </attribute>
+ <interleave>
+ <optional>
+ <ref name="error-app-tag-element"/>
+ </optional>
+ <optional>
+ <ref name="error-message-element"/>
+ </optional>
+ </interleave>
+ </element>
+ </define>
+
+
+
+
+
+
+
+
+
+
+
+
+Lhotka Standards Track [Page 81]
+
+RFC 6110 Mapping YANG to DSDL February 2011
+
+
+ <define name="notifications-element">
+ <element name="nma:notifications">
+ <zeroOrMore>
+ <element name="nma:notification">
+ <ref name="__anyxml__"/>
+ </element>
+ </zeroOrMore>
+ </element>
+ </define>
+
+ <define name="rpcs-element">
+ <element name="nma:rpcs">
+ <zeroOrMore>
+ <element name="nma:rpc">
+ <interleave>
+ <element name="nma:input">
+ <ref name="__anyxml__"/>
+ </element>
+ <optional>
+ <element name="nma:output">
+ <ref name="__anyxml__"/>
+ </element>
+ </optional>
+ </interleave>
+ </element>
+ </zeroOrMore>
+ </element>
+ </define>
+
+ <define name="ordered-by-attribute">
+ <attribute name="nma:ordered-by">
+ <choice>
+ <value>user</value>
+ <value>system</value>
+ </choice>
+ </attribute>
+ </define>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lhotka Standards Track [Page 82]
+
+RFC 6110 Mapping YANG to DSDL February 2011
+
+
+ <define name="status-attribute">
+ <optional>
+ <attribute name="nma:status">
+ <choice>
+ <value>current</value>
+ <value>deprecated</value>
+ <value>obsolete</value>
+ </choice>
+ </attribute>
+ </optional>
+ </define>
+
+ <define name="unique-attribute">
+ <optional>
+ <attribute name="nma:unique">
+ <list>
+ <data type="token"/>
+ </list>
+ </attribute>
+ </optional>
+ </define>
+
+ <define name="units-attribute">
+ <optional>
+ <attribute name="nma:units">
+ <data type="string"/>
+ </attribute>
+ </optional>
+ </define>
+
+ <define name="when-attribute">
+ <optional>
+ <attribute name="nma:when">
+ <data type="string"/>
+ </attribute>
+ </optional>
+ </define>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lhotka Standards Track [Page 83]
+
+RFC 6110 Mapping YANG to DSDL February 2011
+
+
+ <define name="__anyxml__">
+ <zeroOrMore>
+ <choice>
+ <attribute>
+ <anyName/>
+ </attribute>
+ <element>
+ <anyName/>
+ <ref name="__anyxml__"/>
+ </element>
+ <text/>
+ </choice>
+ </zeroOrMore>
+ </define>
+
+ </grammar>
+
+ <CODE ENDS>
+
+Appendix B. Schema-Independent Library
+
+ 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].
+
+ <CODE BEGINS> file "relaxng-lib.rng"
+
+ <?xml version="1.0" encoding="UTF-8"?>
+
+ <grammar xmlns="http://relaxng.org/ns/structure/1.0"
+ xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"
+ xmlns:en="urn:ietf:params:xml:ns:netconf:notification:1.0"
+ datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes">
+
+ <define name="message-id-attribute">
+ <attribute name="message-id">
+ <data type="string">
+ <param name="maxLength">4095</param>
+ </data>
+ </attribute>
+ </define>
+
+
+
+
+
+
+Lhotka Standards Track [Page 84]
+
+RFC 6110 Mapping YANG to DSDL February 2011
+
+
+ <define name="ok-element">
+ <element name="nc:ok">
+ <empty/>
+ </element>
+ </define>
+
+ <define name="eventTime-element">
+ <element name="en:eventTime">
+ <data type="dateTime"/>
+ </element>
+ </define>
+ </grammar>
+
+ <CODE ENDS>
+
+Appendix C. Mapping DHCP Data Model - A Complete Example
+
+ 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.
+
+ 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.
+
+ 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.
+
+ Other than that, the results of the automatic translations were not
+ changed.
+
+C.1. Input YANG Module
+
+ module dhcp {
+ namespace "http://example.com/ns/dhcp";
+ prefix dhcp;
+
+ import ietf-yang-types { prefix yang; }
+ import ietf-inet-types { prefix inet; }
+
+
+
+
+
+
+
+
+Lhotka Standards Track [Page 85]
+
+RFC 6110 Mapping YANG to DSDL February 2011
+
+
+ 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.";
+
+ 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;
+
+
+
+
+
+
+
+
+Lhotka Standards Track [Page 86]
+
+RFC 6110 Mapping YANG to DSDL February 2011
+
+
+ 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";
+ }
+
+
+
+
+
+
+
+
+
+
+
+
+Lhotka Standards Track [Page 87]
+
+RFC 6110 Mapping YANG to DSDL February 2011
+
+
+ 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
+
+ <?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>
+
+
+
+Lhotka Standards Track [Page 88]
+
+RFC 6110 Mapping YANG to DSDL February 2011
+
+
+ <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=". &lt;= ../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>
+
+
+
+Lhotka Standards Track [Page 89]
+
+RFC 6110 Mapping YANG to DSDL February 2011
+
+
+ <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>
+
+
+
+Lhotka Standards Track [Page 90]
+
+RFC 6110 Mapping YANG to DSDL February 2011
+
+
+ </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">
+
+
+
+Lhotka Standards Track [Page 91]
+
+RFC 6110 Mapping YANG to DSDL February 2011
+
+
+ <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>
+
+
+
+Lhotka Standards Track [Page 92]
+
+RFC 6110 Mapping YANG to DSDL February 2011
+
+
+ <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>
+
+C.3. Final DSDL Schemas
+
+ 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.
+
+ The RELAX NG schema (in two parts, as explained in Section 8.2) also
+ includes the schema-independent library from Appendix B.
+
+C.3.1. Main RELAX NG Schema for <nc:get> Reply
+
+ <?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">
+
+
+
+Lhotka Standards Track [Page 93]
+
+RFC 6110 Mapping YANG to DSDL February 2011
+
+
+ <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>
+
+
+
+Lhotka Standards Track [Page 94]
+
+RFC 6110 Mapping YANG to DSDL February 2011
+
+
+ <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>
+
+C.3.2. RELAX NG Schema - Global Named Pattern Definitions
+
+ <?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})*)?
+
+
+
+Lhotka Standards Track [Page 95]
+
+RFC 6110 Mapping YANG to DSDL February 2011
+
+
+ </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>
+
+
+
+Lhotka Standards Track [Page 96]
+
+RFC 6110 Mapping YANG to DSDL February 2011
+
+
+ </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>
+
+
+
+Lhotka Standards Track [Page 97]
+
+RFC 6110 Mapping YANG to DSDL February 2011
+
+
+ </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>
+
+C.3.3. Schematron Schema for <nc:get> Reply
+
+ <?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=". &lt;= ../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"
+
+
+
+Lhotka Standards Track [Page 98]
+
+RFC 6110 Mapping YANG to DSDL February 2011
+
+
+ </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>
+
+C.3.4. DSRL Schema for <nc:get> Reply
+
+ <?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>
+
+
+
+Lhotka Standards Track [Page 99]
+
+RFC 6110 Mapping YANG to DSDL February 2011
+
+
+ <dsrl:parent>
+ /nc:rpc-reply/nc:data/dhcp:dhcp/dhcp:shared-networks/
+ dhcp:shared-network/dhcp:subnet
+ </dsrl:parent>
+ <dsrl:name>dhcp:max-lease-time</dsrl:name>
+ <dsrl:default-content>7200</dsrl:default-content>
+ </dsrl:element-map>
+ </dsrl:maps>
+
+Author's Address
+
+ Ladislav Lhotka (editor)
+ CESNET
+
+ EMail: lhotka@cesnet.cz
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lhotka Standards Track [Page 100]
+