draft-ietf-netmod-dsdl-map-10.txt   rfc6110.txt 
NETMOD L. Lhotka, Ed. Internet Engineering Task Force (IETF) L. Lhotka, Ed.
Internet-Draft CESNET Request for Comments: 6110 CESNET
Intended status: Standards Track October 21, 2010 Category: Standards Track February 2011
Expires: April 24, 2011 ISSN: 2070-1721
Mapping YANG to Document Schema Definition Languages and Validating Mapping YANG to Document Schema Definition Languages
NETCONF Content and Validating NETCONF Content
draft-ietf-netmod-dsdl-map-10
Abstract Abstract
This document specifies the mapping rules for translating YANG data This document specifies the mapping rules for translating YANG data
models into Document Schema Definition Languages (DSDL), a models into Document Schema Definition Languages (DSDL), a
coordinated set of XML schema languages standardized as ISO/IEC coordinated set of XML schema languages standardized as ISO/IEC
19757. The following DSDL schema languages are addressed by the 19757. The following DSDL schema languages are addressed by the
mapping: RELAX NG, Schematron and DSRL. The mapping takes one or mapping: Regular Language for XML Next Generation (RELAX NG),
more YANG modules and produces a set of DSDL schemas for a selected Schematron, and Schematron and Document Schema Renaming Language
target document type - datastore content, NETCONF message etc. (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 Procedures for schema-based validation of such documents are also
discussed. discussed.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This is an Internet Standards Track document.
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on April 24, 2011. 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.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction ....................................................5
2. Terminology and Notation . . . . . . . . . . . . . . . . . . 8 2. Terminology and Notation ........................................6
2.1. Glossary of New Terms . . . . . . . . . . . . . . . . . 11 2.1. Glossary of New Terms ......................................9
3. Objectives and Motivation . . . . . . . . . . . . . . . . . . 12 3. Objectives and Motivation ......................................10
4. DSDL Schema Languages . . . . . . . . . . . . . . . . . . . . 14 4. DSDL Schema Languages ..........................................11
4.1. RELAX NG . . . . . . . . . . . . . . . . . . . . . . . . 14 4.1. RELAX NG ..................................................11
4.2. Schematron . . . . . . . . . . . . . . . . . . . . . . . 15 4.2. Schematron ................................................12
4.3. Document Semantics Renaming Language (DSRL) . . . . . . 16 4.3. Document Semantics Renaming Language (DSRL) ...............13
5. Additional Annotations . . . . . . . . . . . . . . . . . . . 17 5. Additional Annotations .........................................14
5.1. Dublin Core Metadata Elements . . . . . . . . . . . . . 17 5.1. Dublin Core Metadata Elements .............................14
5.2. RELAX NG DTD Compatibility Annotations . . . . . . . . . 17 5.2. RELAX NG DTD Compatibility Annotations ....................14
5.3. NETMOD-Specific Annotations . . . . . . . . . . . . . . 18 5.3. NETMOD-Specific Annotations ...............................15
6. Overview of the Mapping . . . . . . . . . . . . . . . . . . . 20 6. Overview of the Mapping ........................................16
7. NETCONF Content Validation . . . . . . . . . . . . . . . . . 22 7. NETCONF Content Validation .....................................18
8. Design Considerations . . . . . . . . . . . . . . . . . . . . 23 8. Design Considerations ..........................................19
8.1. Hybrid Schema . . . . . . . . . . . . . . . . . . . . . 23 8.1. Hybrid Schema .............................................19
8.2. Modularity . . . . . . . . . . . . . . . . . . . . . . . 25 8.2. Modularity ................................................22
8.3. Granularity . . . . . . . . . . . . . . . . . . . . . . 27 8.3. Granularity ...............................................23
8.4. Handling of XML Namespaces . . . . . . . . . . . . . . . 27 8.4. Handling of XML Namespaces ................................24
9. Mapping YANG Data Models to the Hybrid Schema . . . . . . . . 29 9. Mapping YANG Data Models to the Hybrid Schema ..................25
9.1. Occurrence Rules for Data Nodes . . . . . . . . . . . . 29 9.1. Occurrence Rules for Data Nodes ...........................25
9.1.1. Optional and Mandatory Nodes . . . . . . . . . . . 30 9.1.1. Optional and Mandatory Nodes .......................26
9.1.2. Implicit Nodes . . . . . . . . . . . . . . . . . . 31 9.1.2. Implicit Nodes .....................................27
9.2. Mapping YANG Groupings and Typedefs . . . . . . . . . . 32 9.2. Mapping YANG Groupings and Typedefs .......................28
9.2.1. YANG Refinements and Augments . . . . . . . . . . . 33 9.2.1. YANG Refinements and Augments ......................29
9.2.2. Type Derivation Chains . . . . . . . . . . . . . . 36 9.2.2. Type Derivation Chains .............................32
9.3. Translation of XPath Expressions . . . . . . . . . . . . 38 9.3. Translation of XPath Expressions ..........................35
9.4. YANG Language Extensions . . . . . . . . . . . . . . . . 39 9.4. YANG Language Extensions ..................................36
10. Mapping YANG Statements to the Hybrid Schema . . . . . . . . 41 10. Mapping YANG Statements to the Hybrid Schema ..................37
10.1. The 'anyxml' Statement . . . . . . . . . . . . . . . . . 41 10.1. The 'anyxml' Statement ...................................37
10.2. The 'argument' Statement . . . . . . . . . . . . . . . . 42 10.2. The 'argument' Statement .................................38
10.3. The 'augment' Statement . . . . . . . . . . . . . . . . 43 10.3. The 'augment' Statement ..................................39
10.4. The 'base' Statement . . . . . . . . . . . . . . . . . . 43 10.4. The 'base' Statement .....................................39
10.5. The 'belongs-to' Statement . . . . . . . . . . . . . . . 43 10.5. The 'belongs-to' Statement ...............................39
10.6. The 'bit' Statement . . . . . . . . . . . . . . . . . . 43 10.6. The 'bit' Statement ......................................39
10.7. The 'case' Statement . . . . . . . . . . . . . . . . . . 43 10.7. The 'case' Statement .....................................39
10.8. The 'choice' Statement . . . . . . . . . . . . . . . . . 43 10.8. The 'choice' Statement ...................................39
10.9. The 'config' Statement . . . . . . . . . . . . . . . . . 44 10.9. The 'config' Statement ...................................40
10.10. The 'contact' Statement . . . . . . . . . . . . . . . . 44 10.10. The 'contact' Statement .................................40
10.11. The 'container' Statement . . . . . . . . . . . . . . . 44 10.11. The 'container' Statement ...............................40
10.12. The 'default' Statement . . . . . . . . . . . . . . . . 44 10.12. The 'default' Statement .................................40
10.13. The 'description' Statement . . . . . . . . . . . . . . 46 10.13. The 'description' Statement .............................42
10.14. The 'deviation' Statement . . . . . . . . . . . . . . . 46 10.14. The 'deviation' Statement ...............................42
10.15. The 'enum' Statement . . . . . . . . . . . . . . . . . . 46 10.15. The 'enum' Statement ....................................42
10.16. The 'error-app-tag' Statement . . . . . . . . . . . . . 46 10.16. The 'error-app-tag' Statement ...........................42
10.17. The 'error-message' Statement . . . . . . . . . . . . . 46 10.17. The 'error-message' Statement ...........................42
10.18. The 'extension' Statement . . . . . . . . . . . . . . . 46 10.18. The 'extension' Statement ...............................43
10.19. The 'feature' Statement . . . . . . . . . . . . . . . . 46 10.19. The 'feature' Statement .................................43
10.20. The 'grouping' Statement . . . . . . . . . . . . . . . . 46 10.20. The 'grouping' Statement ................................43
10.21. The 'identity' Statement . . . . . . . . . . . . . . . . 47 10.21. The 'identity' Statement ................................43
10.22. The 'if-feature' Statement . . . . . . . . . . . . . . . 48 10.22. The 'if-feature' Statement ..............................45
10.23. The 'import' Statement . . . . . . . . . . . . . . . . . 49 10.23. The 'import' Statement ..................................45
10.24. The 'include' Statement . . . . . . . . . . . . . . . . 49 10.24. The 'include' Statement .................................45
10.25. The 'input' Statement . . . . . . . . . . . . . . . . . 49 10.25. The 'input' Statement ...................................46
10.26. The 'key' Statement . . . . . . . . . . . . . . . . . . 49 10.26. The 'key' Statement .....................................46
10.27. The 'leaf' Statement . . . . . . . . . . . . . . . . . . 49 10.27. The 'leaf' Statement ....................................46
10.28. The 'leaf-list' Statement . . . . . . . . . . . . . . . 50 10.28. The 'leaf-list' Statement ...............................46
10.29. The 'length' Statement . . . . . . . . . . . . . . . . . 50 10.29. The 'length' Statement ..................................47
10.30. The 'list' Statement . . . . . . . . . . . . . . . . . . 51 10.30. The 'list' Statement ....................................47
10.31. The 'mandatory' Statement . . . . . . . . . . . . . . . 52 10.31. The 'mandatory' Statement ...............................48
10.32. The 'max-elements' Statement . . . . . . . . . . . . . . 52 10.32. The 'max-elements' Statement ............................49
10.33. The 'min-elements' Statement . . . . . . . . . . . . . . 52 10.33. The 'min-elements' Statement ............................49
10.34. The 'module' Statement . . . . . . . . . . . . . . . . . 52 10.34. The 'module' Statement ..................................49
10.35. The 'must' Statement . . . . . . . . . . . . . . . . . . 53 10.35. The 'must' Statement ....................................49
10.36. The 'namespace' Statement . . . . . . . . . . . . . . . 53 10.36. The 'namespace' Statement ...............................50
10.37. The 'notification' Statement . . . . . . . . . . . . . . 54 10.37. The 'notification' Statement ............................50
10.38. The 'ordered-by' Statement . . . . . . . . . . . . . . . 54 10.38. The 'ordered-by' Statement ..............................50
10.39. The 'organization' Statement . . . . . . . . . . . . . . 54 10.39. The 'organization' Statement ............................50
10.40. The 'output' Statement . . . . . . . . . . . . . . . . . 54 10.40. The 'output' Statement ..................................51
10.41. The 'path' Statement . . . . . . . . . . . . . . . . . . 54 10.41. The 'path' Statement ....................................51
10.42. The 'pattern' Statement . . . . . . . . . . . . . . . . 54 10.42. The 'pattern' Statement .................................51
10.43. The 'position' Statement . . . . . . . . . . . . . . . . 55 10.43. The 'position' Statement ................................51
10.44. The 'prefix' Statement . . . . . . . . . . . . . . . . . 55 10.44. The 'prefix' Statement ..................................51
10.45. The 'presence' Statement . . . . . . . . . . . . . . . . 55 10.45. The 'presence' Statement ................................51
10.46. The 'range' Statement . . . . . . . . . . . . . . . . . 55 10.46. The 'range' Statement ...................................51
10.47. The 'reference' Statement . . . . . . . . . . . . . . . 55 10.47. The 'reference' Statement ...............................51
10.48. The 'require-instance' Statement . . . . . . . . . . . . 55 10.48. The 'require-instance' Statement ........................51
10.49. The 'revision' Statement . . . . . . . . . . . . . . . . 55 10.49. The 'revision' Statement ................................52
10.50. The 'rpc' Statement . . . . . . . . . . . . . . . . . . 55 10.50. The 'rpc' Statement .....................................52
10.51. The 'status' Statement . . . . . . . . . . . . . . . . . 56 10.51. The 'status' Statement ..................................52
10.52. The 'submodule' Statement . . . . . . . . . . . . . . . 56 10.52. The 'submodule' Statement ...............................52
10.53. The 'type' Statement . . . . . . . . . . . . . . . . . . 56 10.53. The 'type' Statement ....................................53
10.53.1. The "empty" Type . . . . . . . . . . . . . . . . . 57 10.53.1. The "empty" Type .................................54
10.53.2. The "boolean" Type . . . . . . . . . . . . . . . . 57 10.53.2. The "boolean" Type ...............................54
10.53.3. The "binary" Type . . . . . . . . . . . . . . . . . 58 10.53.3. The "binary" Type ................................54
10.53.4. The "bits" Type . . . . . . . . . . . . . . . . . . 58 10.53.4. The "bits" Type ..................................54
10.53.5. The "enumeration" and "union" Types . . . . . . . . 58 10.53.5. The "enumeration" and "union" Types ..............54
10.53.6. The "identityref" Type . . . . . . . . . . . . . . 58 10.53.6. The "identityref" Type ...........................54
10.53.7. The "instance-identifier" Type . . . . . . . . . . 59 10.53.7. The "instance-identifier" Type ...................55
10.53.8. The "leafref" Type . . . . . . . . . . . . . . . . 59 10.53.8. The "leafref" Type ...............................55
10.53.9. The Numeric Types . . . . . . . . . . . . . . . . . 59 10.53.9. The Numeric Types ................................55
10.53.10. The "string" Type . . . . . . . . . . . . . . . . . 61 10.53.10. The "string" Type ...............................57
10.53.11. Derived Types . . . . . . . . . . . . . . . . . . . 62 10.53.11. Derived Types ...................................58
10.54. The 'typedef' Statement . . . . . . . . . . . . . . . . 63 10.54. The 'typedef' Statement .................................59
10.55. The 'unique' Statement . . . . . . . . . . . . . . . . . 63 10.55. The 'unique' Statement ..................................59
10.56. The 'units' Statement . . . . . . . . . . . . . . . . . 64 10.56. The 'units' Statement ...................................60
10.57. The 'uses' Statement . . . . . . . . . . . . . . . . . . 64 10.57. The 'uses' Statement ....................................60
10.58. The 'value' Statement . . . . . . . . . . . . . . . . . 64 10.58. The 'value' Statement ...................................60
10.59. The 'when' Statement . . . . . . . . . . . . . . . . . . 64 10.59. The 'when' Statement ....................................60
10.60. The 'yang-version' Statement . . . . . . . . . . . . . . 64 10.60. The 'yang-version' Statement ............................60
10.61. The 'yin-element' Statement . . . . . . . . . . . . . . 64 10.61. The 'yin-element' Statement .............................61
11. Mapping the Hybrid Schema to DSDL . . . . . . . . . . . . . . 65 11. Mapping the Hybrid Schema to DSDL .............................61
11.1. Generating RELAX NG Schemas for Various Document Types . 65 11.1. Generating RELAX NG Schemas for Various Document Types ...61
11.2. Mapping Semantic Constraints to Schematron . . . . . . . 66 11.2. Mapping Semantic Constraints to Schematron ...............62
11.2.1. Constraints on Mandatory Choice . . . . . . . . . . 69 11.2.1. Constraints on Mandatory Choice ...................65
11.3. Mapping Default Values to DSRL . . . . . . . . . . . . . 70 11.3. Mapping Default Values to DSRL ...........................67
12. Mapping NETMOD-specific Annotations to DSDL Schema 12. Mapping NETMOD-Specific Annotations to DSDL Schema Languages ..71
Languages . . . . . . . . . . . . . . . . . . . . . . . . . . 75 12.1. The @nma:config Annotation ...............................71
12.1. The @nma:config Annotation . . . . . . . . . . . . . . . 75 12.2. The @nma:default Annotation ..............................71
12.2. The @nma:default Annotation . . . . . . . . . . . . . . 75 12.3. The <nma:error-app-tag> Annotation .......................71
12.3. The <nma:error-app-tag> Annotation . . . . . . . . . . . 75 12.4. The <nma:error-message> Annotation .......................71
12.4. The <nma:error-message> Annotation . . . . . . . . . . . 75 12.5. The @if-feature Annotation ...............................71
12.5. The @if-feature Annotation . . . . . . . . . . . . . . . 75 12.6. The @nma:implicit Annotation .............................72
12.6. The @nma:implicit Annotation . . . . . . . . . . . . . . 76 12.7. The <nma:instance-identifier> Annotation .................72
12.7. The <nma:instance-identifier> Annotation . . . . . . . . 76 12.8. The @nma:key Annotation ..................................72
12.8. The @nma:key Annotation . . . . . . . . . . . . . . . . 76 12.9. The @nma:leaf-list Annotation ............................72
12.9. The @nma:leaf-list Annotation . . . . . . . . . . . . . 76 12.10. The @nma:leafref Annotation .............................73
12.10. The @nma:leafref Annotation . . . . . . . . . . . . . . 77 12.11. The @nma:min-elements Annotation ........................73
12.11. The @nma:min-elements Annotation . . . . . . . . . . . . 77 12.12. The @nma:max-elements Annotation ........................73
12.12. The @nma:max-elements Annotation . . . . . . . . . . . . 77 12.13. The <nma:must> Annotation ...............................73
12.13. The <nma:must> Annotation . . . . . . . . . . . . . . . 77 12.14. The <nma:ordered-by> Annotation .........................74
12.14. The <nma:ordered-by> Annotation . . . . . . . . . . . . 78 12.15. The <nma:status> Annotation .............................74
12.15. The <nma:status> Annotation . . . . . . . . . . . . . . 78 12.16. The @nma:unique Annotation ..............................74
12.16. The @nma:unique Annotation . . . . . . . . . . . . . . . 78 12.17. The @nma:when Annotation ................................74
12.17. The @nma:when Annotation . . . . . . . . . . . . . . . . 78 13. IANA Considerations ...........................................75
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 79 14. Security Considerations .......................................75
14. Security Considerations . . . . . . . . . . . . . . . . . . . 80 15. Contributors ..................................................75
15. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 81 16. Acknowledgments ...............................................76
16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 82 17. References ....................................................76
17. References . . . . . . . . . . . . . . . . . . . . . . . . . 83 17.1. Normative References .....................................76
17.1. Normative References . . . . . . . . . . . . . . . . . . 83 17.2. Informative References ...................................77
17.2. Informative References . . . . . . . . . . . . . . . . . 84 Appendix A. RELAX NG Schema for NETMOD-Specific Annotations .......79
Appendix A. RELAX NG Schema for NETMOD-Specific Annotations . . 86 Appendix B. Schema-Independent Library ............................84
Appendix B. Schema-Independent Library . . . . . . . . . . . . . 91 Appendix C. Mapping DHCP Data Model - A Complete Example ..........85
Appendix C. Mapping DHCP Data Model - A Complete Example . . . . 92 C.1. Input YANG Module .........................................85
C.1. Input YANG Module . . . . . . . . . . . . . . . . . . . 92 C.2. Hybrid Schema .............................................88
C.2. Hybrid Schema . . . . . . . . . . . . . . . . . . . . . 94 C.3. Final DSDL Schemas .......................................93
C.3. Final DSDL Schemas . . . . . . . . . . . . . . . . . . . 99 C.3.1. Main RELAX NG Schema for <nc:get> Reply ............93
C.3.1. Main RELAX NG Schema for <nc:get> Reply . . . . . . 100 C.3.2. RELAX NG Schema - Global Named Pattern
C.3.2. RELAX NG Schema - Global Named Pattern Definitions ........................................95
Definitions . . . . . . . . . . . . . . . . . . . . 102 C.3.3. Schematron Schema for <nc:get> Reply ...............98
C.3.3. Schematron Schema for <nc:get> Reply . . . . . . . 104 C.3.4. DSRL Schema for <nc:get> Reply .....................99
C.3.4. DSRL Schema for <nc:get> Reply . . . . . . . . . . 106
Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 107
D.1. Changes Between Versions -07 and -08 . . . . . . . . . . 107
D.2. Changes Between Versions -06 and -07 . . . . . . . . . . 107
D.3. Changes Between Versions -05 and -06 . . . . . . . . . . 107
D.4. Changes Between Versions -04 and -05 . . . . . . . . . . 108
D.5. Changes Between Versions -03 and -04 . . . . . . . . . . 108
D.6. Changes Between Versions -02 and -03 . . . . . . . . . . 109
D.7. Changes Between Versions -01 and -02 . . . . . . . . . . 110
D.8. Changes Between Versions -00 and -01 . . . . . . . . . . 110
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 112
1. Introduction 1. Introduction
The NETCONF Working Group has completed a base protocol used for The NETCONF Working Group has completed a base protocol used for
configuration management [RFC4741]. This base specification defines configuration management [RFC4741]. This base specification defines
protocol bindings and an XML container syntax for configuration and protocol bindings and an XML container syntax for configuration and
management operations, but does not include a data modeling language management operations, but does not include a data modeling language
or accompanying rules for how to model configuration and state or accompanying rules for how to model configuration and state
information carried by NETCONF. The IETF Operations Area has a long information carried by NETCONF. The IETF Operations Area has a long
tradition of defining data for SNMP Management Information Bases tradition of defining data for Simple Network Management Protocol
(MIB) modules [RFC1157] using the Structure of Management Information (SNMP) Management Information Bases (MIB) modules [RFC1157] using the
(SMI) language [RFC2578] to model its data. While this specific Structure of Management Information (SMI) language [RFC2578] to model
modeling approach has a number of well-understood problems, most of its data. While this specific modeling approach has a number of
the data modeling features provided by SMI are still considered well-understood problems, most of the data modeling features provided
extremely important. Simply modeling the valid syntax without the by SMI are still considered extremely important. Simply modeling the
additional semantic relationships has caused significant valid syntax without the additional semantic relationships has caused
interoperability problems in the past. significant interoperability problems in the past.
The NETCONF community concluded that a data modeling framework is The NETCONF community concluded that a data modeling framework is
needed to support ongoing development of IETF and vendor-defined needed to support ongoing development of IETF and vendor-defined
management information modules. The NETMOD Working Group was management information modules. The NETMOD Working Group was
chartered to design a modeling language defining the semantics of chartered to design a modeling language defining the semantics of
operational data, configuration data, event notifications and operational data, configuration data, event notifications, and
operations, with focus on "human-friendliness", i.e., readability and operations, with focus on "human-friendliness", i.e., readability and
ease of use. The result is the YANG data modeling language ease of use. The result is the YANG data modeling language
[RFC6020], which now serves for the normative description of NETCONF [RFC6020], which now serves for the normative description of NETCONF
data models. data models.
Since NETCONF uses XML for encoding its messages, it is natural to Since NETCONF uses XML for encoding its messages, it is natural to
express the constraints on NETCONF content using standard XML schema express the constraints on NETCONF content using standard XML schema
languages. For this purpose, the NETMOD WG selected the Document languages. For this purpose, the NETMOD WG selected the Document
Schema Definition Languages (DSDL) that is being standardized as ISO/ Schema Definition Languages (DSDL) that is being standardized as
IEC 19757 [DSDL]. The DSDL framework comprises a set of XML schema ISO/IEC 19757 [DSDL]. The DSDL framework comprises a set of XML
languages that address grammar rules, semantic constraints and other schema languages that address grammar rules, semantic constraints,
data modeling aspects, but also, and more importantly, do it in a and other data modeling aspects, but also, and more importantly, do
coordinated and consistent way. While it is true that some DSDL it in a coordinated and consistent way. While it is true that some
parts have not been standardized yet and are still work in progress, DSDL parts have not been standardized yet and are still work in
the three parts that the YANG-to-DSDL mapping relies upon - Regular progress, the three parts that the YANG-to-DSDL mapping relies upon
Language for XML Next Generation (RELAX NG), Schematron and Document -- Regular Language for XML Next Generation (RELAX NG), Schematron
Schema Renaming Language (DSRL) - already have the status of an ISO/ and Document Schema Renaming Language (DSRL) -- already have the
IEC International Standard and are supported in a number of software status of an ISO/ IEC International Standard and are supported in a
tools. number of software tools.
This document contains a specification of a mapping that translates This document contains a specification of a mapping that translates
YANG data models to XML schemas utilizing a subset of the DSDL schema YANG data models to XML schemas utilizing a subset of the DSDL schema
languages. The mapping procedure is divided into two steps: In the languages. The mapping procedure is divided into two steps: In the
first step, the structure of the data tree, signatures of remote first step, the structure of the data tree, signatures of remote
procedure call (RPC) operations and notifications is expressed as the procedure call (RPC) operations, and notifications are expressed as
so-called "hybrid schema" - a single RELAX NG schema with annotations the so-called "hybrid schema" -- a single RELAX NG schema with
representing additional data model information (metadata, annotations representing additional data model information (metadata,
documentation, semantic constraints, default values etc.). The documentation, semantic constraints, default values, etc.). The
second step then generates a coordinated set of DSDL schemas that can second step then generates a coordinated set of DSDL schemas that can
be used for validating specific XML documents such as client be used for validating specific XML documents such as client
requests, server responses or notifications, perhaps also taking into requests, server responses or notifications, perhaps also taking into
account additional context such as active capabilities or features. account additional context such as active capabilities or features.
2. Terminology and Notation 2. Terminology and Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
skipping to change at page 10, line 7 skipping to change at page 8, line 30
In the text, the following typographic conventions are used: In the text, the following typographic conventions are used:
o YANG statement keywords are delimited by single quotes. o YANG statement keywords are delimited by single quotes.
o XML element names are delimited by "<" and ">" characters. o XML element names are delimited by "<" and ">" characters.
o Names of XML attributes are prefixed by the "@" character. o Names of XML attributes are prefixed by the "@" character.
o Other literal values are delimited by double quotes. o Other literal values are delimited by double quotes.
XML elements names are always written with explicit namespace XML element names are always written with explicit namespace prefixes
prefixes corresponding to the following XML vocabularies: corresponding to the following XML vocabularies:
"a" DTD compatibility annotations [RNG-DTD]; "a" DTD compatibility annotations [RNG-DTD];
"dc" Dublin Core metadata elements [RFC5013]; "dc" Dublin Core metadata elements [RFC5013];
"dsrl" Document Semantics Renaming Language [DSRL]; "dsrl" Document Semantics Renaming Language [DSRL];
"en" NETCONF event notifications [RFC5277]; "en" NETCONF event notifications [RFC5277];
"nc" NETCONF protocol [RFC4741]; "nc" NETCONF protocol [RFC4741];
"nma" NETMOD-specific schema annotations (see Section 5.3); "nma" NETMOD-specific schema annotations (see Section 5.3);
"nmf" NETMOD-specific XPath extension functions (see Section 12.7); "nmf" NETMOD-specific XML Path Language (XPath) extension functions
(see Section 12.7);
"rng" RELAX NG [RNG]; "rng" RELAX NG [RNG];
"sch" ISO Schematron [Schematron]; "sch" ISO Schematron [Schematron];
"xsd" W3C XML Schema [XSD]. "xsd" W3C XML Schema [XSD].
The following table shows the mapping of these prefixes to namespace The following table shows the mapping of these prefixes to namespace
URIs. URIs.
+--------+-----------------------------------------------------+ +--------+-----------------------------------------------------+
| Prefix | Namespace URI | | Prefix | Namespace URI |
+--------+-----------------------------------------------------+ +--------+-----------------------------------------------------+
| a | http://relaxng.org/ns/compatibility/annotations/1.0 | | a | http://relaxng.org/ns/compatibility/annotations/1.0 |
| | | | | |
skipping to change at page 11, line 33 skipping to change at page 9, line 37
| | | | | |
| sch | http://purl.oclc.org/dsdl/schematron | | sch | http://purl.oclc.org/dsdl/schematron |
| | | | | |
| xsd | http://www.w3.org/2001/XMLSchema | | xsd | http://www.w3.org/2001/XMLSchema |
+--------+-----------------------------------------------------+ +--------+-----------------------------------------------------+
Table 1: Used namespace prefixes and corresponding URIs Table 1: Used namespace prefixes and corresponding URIs
2.1. Glossary of New Terms 2.1. Glossary of New Terms
o ancestor datatype: Any datatype a given datatype is (transitively) o ancestor data type: Any data type from which a given data type is
derived from. (transitively) derived.
o ancestor built-in datatype: The built-in datatype that is at the o ancestor built-in data type: The built-in data type that is at the
start of the type derivation chain for a given datatype. start of the type derivation chain for a given data type.
o hybrid schema: A RELAX NG schema with annotations, which embodies o hybrid schema: A RELAX NG schema with annotations, which embodies
the same information as the source YANG module(s). See the same information as the source YANG module(s). See
Section 8.1 for details. Section 8.1 for details.
o implicit node: A data node that, if it is not instantiated in a 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 data tree, may be added to the information set of that data tree
(configuration, RPC input or output, notification) without (configuration, RPC input or output, notification) without
changing the semantics of the data tree. changing the semantics of the data tree.
3. Objectives and Motivation 3. Objectives and Motivation
The main objective of this work is to complement YANG as a data The main objective of this work is to complement YANG as a data
modeling language with validation capabilities of DSDL schema modeling language with validation capabilities of DSDL schema
languages, namely RELAX NG, Schematron and DSRL. This document languages, namely RELAX NG, Schematron, and DSRL. This document
describes the correspondence between grammatical, semantic and data describes the correspondence between grammatical, semantic, and data
type constraints expressed in YANG and equivalent DSDL patterns and type constraints expressed in YANG and equivalent DSDL patterns and
rules. The ultimate goal is to be able to capture all substantial rules. The ultimate goal is to be able to capture all substantial
information contained in YANG modules and express it in DSDL schemas. information contained in YANG modules and express it in DSDL schemas.
While the mapping from YANG to DSDL described in this document may in While the mapping from YANG to DSDL described in this document may in
principle be invertible, the inverse mapping from DSDL to YANG is principle be invertible, the inverse mapping from DSDL to YANG is
beyond the scope of this document. beyond the scope of this document.
XML-based information models and XML-encoded data appear in several XML-based information models and XML-encoded data appear in several
different forms in various phases of YANG data modeling and NETCONF different forms in various phases of YANG data modeling and NETCONF
workflow - configuration datastore contents, RPC requests and workflow -- configuration datastore contents, RPC requests and
replies, and notifications. Moreover, RPC operations are replies, and notifications. Moreover, RPC operations are
characterized by an inherent diversity resulting from selective characterized by an inherent diversity resulting from selective
availability of capabilities and features. YANG modules can also availability of capabilities and features. YANG modules can also
define new RPC operations. The mapping should be able to accommodate define new RPC operations. The mapping should be able to accommodate
this variability and generate schemas that are specifically tailored this variability and generate schemas that are specifically tailored
to a particular situation and thus considerably more effective for to a particular situation and thus considerably more effective for
validation than generic all-encompassing schemas. validation than generic all-encompassing schemas.
In order to cope with this variability, we assume that the DSDL In order to cope with this variability, we assume that the DSDL
schemas will be generated on demand for a particular purpose from the schemas will be generated on demand for a particular purpose from the
skipping to change at page 12, line 51 skipping to change at page 10, line 51
readable as possible. To this end, the complexity of the mapping is readable as possible. To this end, the complexity of the mapping is
distributed into two steps: distributed into two steps:
1. The first step maps one or more YANG modules to the so-called 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 hybrid schema, which is a single RELAX NG schema that describes
grammatical constraints for the main data tree as well as for RPC grammatical constraints for the main data tree as well as for RPC
operations and notifications. Semantic constraints and other operations and notifications. Semantic constraints and other
information appearing in the input YANG modules is recorded in information appearing in the input YANG modules is recorded in
the hybrid schema in the form of foreign namespace annotations. the hybrid schema in the form of foreign namespace annotations.
The output of the first step can thus be considered a virtually The output of the first step can thus be considered a virtually
complete equivalent of the input YANG modules. complete equivalent of the input YANG modules. It cannot,
however, be directly used for any validation.
2. In the second step, the hybrid schema from step 1 is transformed 2. In the second step, the hybrid schema from step 1 is transformed
further to a coordinated set of fully conformant DSDL schemas further to a coordinated set of fully conformant DSDL schemas
containing constraints for a particular data object and a containing constraints for a particular data object and a
specific situation. The DSDL schemas are intended mainly for specific situation. The DSDL schemas are intended mainly for
machine validation using off-the-shelf tools. machine validation using off-the-shelf tools.
4. DSDL Schema Languages 4. DSDL Schema Languages
Document Schema Definition Languages (DSDL) is a framework of schema Document Schema Definition Languages (DSDL) is a framework of schema
languages that is being developed as the International Standard ISO/ languages that is being developed as the International Standard ISO/
IEC 19757 [DSDL]. Unlike other approaches to XML document IEC 19757 [DSDL]. Unlike other approaches to XML document
validation, most notably W3C XML Schema Definition (XSD) [XSD], the validation, most notably W3C XML Schema Definition (XSD) [XSD], the
DSDL framework adheres to the principle of "small languages": Each of DSDL framework adheres to the principle of "small languages": each of
the DSDL constituents is a stand-alone schema language with a the DSDL constituents is a stand-alone schema language with a
relatively narrow purpose and focus. Together, these schema relatively narrow purpose and focus. Together, these schema
languages may be used in a coordinated way to accomplish various languages may be used in a coordinated way to accomplish various
validation tasks. validation tasks.
The mapping described in this document uses three of the DSDL schema The mapping described in this document uses three of the DSDL schema
languages, namely RELAX NG [RNG], Schematron [Schematron] and DSRL languages, namely RELAX NG [RNG], Schematron [Schematron], and DSRL
[DSRL]. [DSRL].
4.1. RELAX NG 4.1. RELAX NG
RELAX NG (pronounced "relaxing") is an XML schema language for RELAX NG (pronounced "relaxing") is an XML schema language for
grammar-based validation and Part 2 of the ISO/IEC DSDL family of grammar-based validation and Part 2 of the ISO/IEC DSDL family of
standards [RNG]. Like the W3C XML Schema language [XSD], it is able standards [RNG]. Like XSD, it is able to describe constraints on the
to describe constraints on the structure and contents of XML structure and contents of XML documents. However, unlike the DTD
documents. However, unlike the DTD [XML] and XSD schema languages, [XML] and XSD schema languages, RELAX NG intentionally avoids any
RELAX NG intentionally avoids any infoset augmentation such as infoset augmentation such as defining default values. In the DSDL
defining default values. In the DSDL architecture, the particular architecture, the particular task of defining and applying default
task of defining and applying default values is delegated to another values is delegated to another schema language, DSRL (see
schema language, DSRL (see Section 4.3). Section 4.3).
As its base datatype library, RELAX NG uses the W3C XML Schema As its base data type library, RELAX NG uses the W3C XML Schema
Datatype Library [XSD-D], but unlike XSD, other datatype libraries Datatypes [XSD-D]; but unlike XSD, other data type libraries may be
may be used along with it or even replace it if necessary. used along with it or even replace it if necessary.
RELAX NG is very liberal in accepting annotations from other RELAX NG is very liberal in accepting annotations from other
namespaces. With a few exceptions, such annotations may be placed namespaces. With a few exceptions, such annotations may be placed
anywhere in the schema and need no encapsulating elements such as anywhere in the schema and need no encapsulating elements such as
<xsd:annotation> in XSD. <xsd:annotation> in XSD.
RELAX NG schemas can be represented in two equivalent syntaxes: XML RELAX NG schemas can be represented in two equivalent syntaxes: XML
and compact. The compact syntax is described in Annex C of the RELAX 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 NG specification [RNG-CS], which was added to the standard in 2006
(Amendment 1). Automatic bidirectional conversions between the two (Amendment 1). Automatic bidirectional conversions between the two
syntaxes can be accomplished using several tools, for example Trang syntaxes can be accomplished using several tools, for example, Trang
[Trang]. [Trang].
For its terseness and readability, the compact syntax is often the For its terseness and readability, the compact syntax is often the
preferred form for publishing RELAX NG schemas whereas validators and preferred form for publishing RELAX NG schemas, whereas validators
other software tools usually work with the XML syntax. However, the and other software tools usually work with the XML syntax. However,
compact syntax has two drawbacks: the compact syntax has two drawbacks:
o External annotations make the compact syntax schema considerably o External annotations make the compact syntax schema considerably
less readable. While in the XML syntax the annotating elements less readable. While in the XML syntax the annotating elements
and attributes are represented in a simple and uniform way (XML and attributes are represented in a simple and uniform way (XML
elements and attributes from foreign namespaces), the compact elements and attributes from foreign namespaces), the compact
syntax uses as many as four different syntactic constructs: syntax uses as many as four different syntactic constructs:
documentation, grammar, initial and following annotations. documentation, grammar, initial, and following annotations.
Therefore, the impact of annotations on readability is often much Therefore, the impact of annotations on readability is often much
stronger for the compact syntax than it is for the XML syntax. stronger for the compact syntax than it is for the XML syntax.
o In a computer program, it is more difficult to generate the o In a computer program, it is more difficult to generate the
compact syntax than the XML syntax. While a number of software compact syntax than the XML syntax. While a number of software
libraries exist that make it easy to create an XML tree in the 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 memory and then serialize it, no such aid is available for the
compact syntax. compact syntax.
For these reasons, the mapping specification in this document uses For these reasons, the mapping specification in this document uses
exclusively the XML syntax. Where appropriate, though, the schemas exclusively the XML syntax. Where appropriate, though, the schemas
resulting from the translation MAY be presented in the equivalent resulting from the translation MAY be presented in the equivalent
compact syntax. compact syntax.
RELAX NG elements are qualified with the namespace URI RELAX NG elements are qualified with the namespace URI
"http://relaxng.org/ns/structure/1.0". The namespace of the W3C "http://relaxng.org/ns/structure/1.0". The namespace of the XSD data
Schema Datatype Library is type library is "http://www.w3.org/2001/XMLSchema-datatypes".
"http://www.w3.org/2001/XMLSchema-datatypes".
4.2. Schematron 4.2. Schematron
Schematron is Part 3 of DSDL that reached the status of a full ISO/ Schematron is Part 3 of DSDL that reached the status of a full ISO/
IEC standard in 2006 [Schematron]. In contrast to the traditional IEC standard in 2006 [Schematron]. In contrast to the traditional
schema languages such as DTD, XSD or RELAX NG, which are based on the schema languages such as DTD, XSD, or RELAX NG, which are based on
concept of a formal grammar, Schematron utilizes a rule-based the concept of a formal grammar, Schematron utilizes a rule-based
approach. Its rules may specify arbitrary conditions involving data approach. Its rules may specify arbitrary conditions involving data
from different parts of an XML document. Each rule consists of three from different parts of an XML document. Each rule consists of three
essential components: essential components:
o context - an XPath expression that defines the set of locations o context - an XPath expression that defines the set of locations
where the rule is to be applied; where the rule is to be applied;
o assert or report condition - another XPath expression that is o assert or report condition - another XPath expression that is
evaluated relative to the location matched by the context evaluated relative to the location matched by the context
expression; expression;
skipping to change at page 16, line 10 skipping to change at page 13, line 21
The difference between the assert and report condition is that the The difference between the assert and report condition is that the
former is positive in that it states a condition that a valid former is positive in that it states a condition that a valid
document has to satisfy, whereas the latter specifies an error document has to satisfy, whereas the latter specifies an error
condition. condition.
Schematron draws most of its expressive power from XPath [XPath] and Schematron draws most of its expressive power from XPath [XPath] and
Extensible Stylesheet Language Transformations (XSLT) [XSLT]. ISO Extensible Stylesheet Language Transformations (XSLT) [XSLT]. ISO
Schematron allows for dynamic query language binding so that the Schematron allows for dynamic query language binding so that the
following XML query languages can be used: STX, XSLT 1.0, XSLT 1.1, 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 EXSLT, XSLT 2.0, XPath 1.0, XPath 2.0, and XQuery 1.0 (this list may
be extended in the future). be extended in the future).
Human-readable error messages are another feature that sets Human-readable error messages are another feature that sets
Schematron apart from other common schema languages. The messages Schematron apart from other common schema languages. The messages
may even contain XPath expressions that are evaluated in the actual may even contain XPath expressions that are evaluated in the actual
context and thus refer to information items in the XML document being context and thus refer to information items in the XML document being
validated. validated.
Another feature of Schematron that is used by the mapping are Another feature of Schematron that is used by the mapping are
abstract patterns. These work essentially as macros and may also abstract patterns. These work essentially as macros and may also
skipping to change at page 17, line 11 skipping to change at page 14, line 11
DSRL elements are qualified with namespace URI DSRL elements are qualified with namespace URI
"http://purl.oclc.org/dsdl/dsrl". "http://purl.oclc.org/dsdl/dsrl".
5. Additional Annotations 5. Additional Annotations
Besides the DSDL schema languages, the mapping also uses three sets Besides the DSDL schema languages, the mapping also uses three sets
of annotations that are added as foreign-namespace attributes and of annotations that are added as foreign-namespace attributes and
elements to RELAX NG schemas. elements to RELAX NG schemas.
Two of the annotation sets - Dublin Core elements and DTD Two of the annotation sets -- Dublin Core elements and DTD
compatibility annotations - are standard vocabularies for compatibility annotations -- are standard vocabularies for
representing metadata and documentation, respectively. Although representing metadata and documentation, respectively. Although
these data model items are not used for formal validation, they quite these data model items are not used for formal validation, they quite
often carry important information for data model implementers. often carry important information for data model implementers.
Therefore, they SHOULD be included in the hybrid schema and MAY also Therefore, they SHOULD be included in the hybrid schema and MAY also
appear in the final validation schemas. appear in the final validation schemas.
The third set are NETMOD-specific annotations. They are specifically The third set are NETMOD-specific annotations. They are specifically
designed for the hybrid schema and convey semantic constraints and designed for the hybrid schema and convey semantic constraints and
other information that cannot be expressed directly in RELAX NG. In other information that cannot be expressed directly in RELAX NG. In
the second mapping step, these annotations are converted to the second mapping step, these annotations are converted to
skipping to change at page 18, line 7 skipping to change at page 15, line 7
Note that there is no intention to make the resulting schemas DTD- Note that there is no intention to make the resulting schemas DTD-
compatible, the main reason for using these annotations is technical: compatible, the main reason for using these annotations is technical:
they are well supported and adequately formatted by several RELAX NG they are well supported and adequately formatted by several RELAX NG
tools. tools.
DTD compatibility annotations are qualified with namespace URI DTD compatibility annotations are qualified with namespace URI
"http://relaxng.org/ns/compatibility/annotations/1.0". "http://relaxng.org/ns/compatibility/annotations/1.0".
5.3. NETMOD-Specific Annotations 5.3. NETMOD-Specific Annotations
NETMOD-specific annotations are XML elements and attributes qualified NETMOD-specific annotations are XML elements and attributes that are
with the namespace URI qualified with the namespace URI
"urn:ietf:params:xml:ns:netmod:dsdl-annotations:1" which appear in "urn:ietf:params:xml:ns:netmod:dsdl-annotations:1" and that appear in
various locations of the hybrid schema. YANG statements are mapped various locations of the hybrid schema. YANG statements are mapped
to these annotations in a straightforward way. In most cases, the to these annotations in a straightforward way. In most cases, the
annotation attributes and elements have the same name as the annotation attributes and elements have the same name as the
corresponding YANG statement. corresponding YANG statement.
Table 2 lists alphabetically the names of NETMOD-specific annotation Table 2 lists, alphabetically, the names of NETMOD-specific
attributes (prefixed with "@") and elements (in angle brackets) along annotation attributes (prefixed with "@") and elements (in angle
with a reference to the section where their use is described. brackets) along with a reference to the section where their use is
Appendix A contains a RELAX NG schema for this annotation vocabulary. described. Appendix A contains a RELAX NG schema for this annotation
vocabulary.
+---------------------------+--------------------+------+ +---------------------------+--------------------+------+
| annotation | section | note | | annotation | section | note |
+---------------------------+--------------------+------+ +---------------------------+--------------------+------+
| @nma:config | 10.9 | | | @nma:config | 10.9 | |
| | | | | | | |
| <nma:data> | 8.1 | 4 | | <nma:data> | 8.1 | 4 |
| | | | | | | |
| @nma:default | 10.12 | | | @nma:default | 10.12 | |
| | | | | | | |
skipping to change at page 19, line 13 skipping to change at page 16, line 14
| | | | | | | |
| @nma:module | 10.34 | | | @nma:module | 10.34 | |
| | | | | | | |
| <nma:must> | 10.35 | 3 | | <nma:must> | 10.35 | 3 |
| | | | | | | |
| <nma:notification> | 8.1 | 4 | | <nma:notification> | 8.1 | 4 |
| | | | | | | |
| <nma:notifications> | 8.1 | 4 | | <nma:notifications> | 8.1 | 4 |
| | | | | | | |
| @nma:ordered-by | 10.38 | | | @nma:ordered-by | 10.38 | |
| | | |
| <nma:output> | 8.1 | 4 | | <nma:output> | 8.1 | 4 |
| | | | | | | |
| <nma:rpc> | 8.1 | 4 | | <nma:rpc> | 8.1 | 4 |
| | | | | | | |
| <nma:rpcs> | 8.1 | 4 | | <nma:rpcs> | 8.1 | 4 |
| | | | | | | |
| @nma:status | 10.51 | | | @nma:status | 10.51 | |
| | | | | | | |
| @nma:unique | 10.55 | | | @nma:unique | 10.55 | |
| | | | | | | |
skipping to change at page 20, line 35 skipping to change at page 17, line 29
|get reply| | rpc | | notif | | .... | |get reply| | rpc | | notif | | .... |
+---------+ +-----+ +-------+ +------+ +---------+ +-----+ +-------+ +------+
Figure 1: Structure of the mapping Figure 1: Structure of the mapping
The mapping procedure is divided into two steps: The mapping procedure is divided into two steps:
1. Transformation T in the first step maps one or more YANG modules 1. Transformation T in the first step maps one or more YANG modules
to the hybrid schema (see Section 8.1). Constraints that cannot to the hybrid schema (see Section 8.1). Constraints that cannot
be expressed directly in RELAX NG (list key definitions, 'must' be expressed directly in RELAX NG (list key definitions, 'must'
statements etc.) and various documentation texts are recorded in statements, etc.) and various documentation texts are recorded in
the schema as foreign-namespace annotations. the schema as foreign-namespace annotations.
2. In the second step, the hybrid schema may be transformed in 2. In the second step, the hybrid schema may be transformed in
multiple ways to a coordinated set of DSDL schemas that can be multiple ways to a coordinated set of DSDL schemas that can be
used for validating a particular data object in a specific used for validating a particular data object in a specific
context. Figure 1 shows three simple possibilities as examples. context. Figure 1 shows three simple possibilities as examples.
In the process, appropriate parts of the hybrid schema are In the process, appropriate parts of the hybrid schema are
extracted and specific annotations transformed to equivalent, but extracted and specific annotations transformed to equivalent, but
usually more complex, Schematron patterns, DSRL element maps etc. usually more complex, Schematron patterns, DSRL element maps,
etc.
An implementation of the mapping algorithm MUST accept one or more An implementation of the mapping algorithm MUST accept one or more
valid YANG modules as its input. It is important to be able to valid YANG modules as its input. It is important to be able to
process multiple YANG modules together since multiple modules may be process multiple YANG modules together since multiple modules may be
negotiated for a NETCONF session and the contents of the negotiated for a NETCONF session and the contents of the
configuration datastore is then obtained as the union of data trees configuration datastore is then obtained as the union of data trees
specified by the individual modules, which may also lead to multiple specified by the individual modules, which may also lead to multiple
root nodes of the datastore hierarchy. In addition, the input root nodes of the datastore hierarchy. In addition, the input
modules may be further coupled by the 'augment' statement in which modules may be further coupled by the 'augment' statement in which
one module augments the data tree of another module. one module augments the data tree of another module.
It is also assumed that the algorithm has access, perhaps on demand, It is also assumed that the algorithm has access, perhaps on demand,
to all YANG modules that the input modules import (directly or to all YANG modules that the input modules import (directly or
transitively). transitively).
Other information contained in input YANG modules, such as semantic Other information contained in input YANG modules, such as semantic
constraints and default values, are recorded in the hybrid schema as constraints and default values, is recorded in the hybrid schema as
annotations - XML attributes or elements qualified with namespace URI annotations -- XML attributes or elements qualified with the
"urn:ietf:params:xml:ns:netmod:dsdl-annotations:1". Metadata namespace URI "urn:ietf:params:xml:ns:netmod:dsdl-annotations:1".
describing the YANG modules are mapped to Dublin Core annotations Metadata describing the YANG modules are mapped to Dublin Core
elements (Section 5.1). Finally, documentation strings are mapped to annotations elements (Section 5.1). Finally, documentation strings
<a:documentation> elements belonging to the DTD compatibility are mapped to <a:documentation> elements belonging to the DTD
vocabulary (Section 5.2). compatibility vocabulary (Section 5.2).
The output of the second step is a coordinated set of three DSDL The output of the second step is a coordinated set of three DSDL
schemas corresponding to a specific data object and context: schemas corresponding to a specific data object and context:
o RELAX NG schema describing the grammatical and datatype o RELAX NG schema describing the grammatical and data type
constraints; constraints;
o Schematron schema expressing other constraints such as uniqueness o Schematron schema expressing other constraints such as uniqueness
of list keys or user-specified semantic rules; of list keys or user-specified semantic rules;
o DSRL schema containing the specification of default contents. o DSRL schema containing the specification of default contents.
7. NETCONF Content Validation 7. NETCONF Content Validation
This section describes how the schemas generated by the YANG-to-DSDL This section describes how the schemas generated by the YANG-to-DSDL
skipping to change at page 22, line 37 skipping to change at page 19, line 14
+----------+ +----------+ +----------+ +----------+
| | | XML | | | | XML |
| XML | | document | | XML | | document |
| document |-----------o----------->| with | | document |-----------o----------->| with |
| | ^ | defaults | | | ^ | defaults |
| | | | | | | | | |
+----------+ | +----------+ +----------+ | +----------+
^ | filling in ^ ^ | filling in ^
| grammar, | defaults | semantic | grammar, | defaults | semantic
| datatypes | | constraints | data types | | constraints
| | | | | |
+----------+ +--------+ +------------+ +----------+ +--------+ +------------+
| RELAX NG | | DSRL | | Schematron | | RELAX NG | | DSRL | | Schematron |
| schema | | schema | | schema | | schema | | schema | | schema |
+----------+ +--------+ +------------+ +----------+ +--------+ +------------+
Figure 2: Outline of the validation procedure Figure 2: Outline of the validation procedure
8. Design Considerations 8. Design Considerations
YANG data models could in principle be mapped to the DSDL schemas in YANG data models could, in principle, be mapped to the DSDL schemas
a number of ways. The mapping procedure described in this document in a number of ways. The mapping procedure described in this
uses several specific design decisions that are discussed in the document uses several specific design decisions that are discussed in
following subsections. the following subsections.
8.1. Hybrid Schema 8.1. Hybrid Schema
As was explained in Section 6, the first step of the mapping produces As was explained in Section 6, the first step of the mapping produces
an intermediate document - the hybrid schema, which specifies all an intermediate document -- the hybrid schema, which specifies all
constraints for the entire data model in a single RELAX NG schema. 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 Every input YANG module corresponds to exactly one embedded grammar
in the hybrid schema. This separation of input YANG modules allows in the hybrid schema. This separation of input YANG modules allows
each embedded grammar to include named pattern definitions into its each embedded grammar to include named pattern definitions into its
own namespace, which is important for mapping YANG groupings (see own namespace, which is important for mapping YANG groupings (see
Section 9.2 for additional details). Section 9.2 for additional details).
In addition to grammatical and datatype constraints, YANG modules In addition to grammatical and data type constraints, YANG modules
provide other important information that cannot be expressed in a provide other important information that cannot be expressed in a
RELAX NG schema: semantic constraints, default values, metadata, RELAX NG schema: semantic constraints, default values, metadata,
documentation and so on. Such information items are represented in documentation, and so on. Such information items are represented in
the hybrid schema as XML attributes and elements belonging to the the hybrid schema as XML attributes and elements belonging to the
namespace with the following URI: namespace with the following URI:
"urn:ietf:params:xml:ns:netmod:dsdl-annotations:1". A complete list "urn:ietf:params:xml:ns:netmod:dsdl-annotations:1". A complete list
of these annotations is given in Section 5.3, detailed rules about of these annotations is given in Section 5.3, detailed rules about
their use are then contained in the following sections. their use are then contained in the following sections.
YANG modules define data models not only for configuration and state YANG modules define data models not only for configuration and state
data but also for (multiple) RPC operations [RFC4741] and/or event data but also for (multiple) RPC operations [RFC4741] and/or event
notifications [RFC5277]. In order to be able to capture all three notifications [RFC5277]. In order to be able to capture all three
types of data models in one schema document, the hybrid schema uses types of data models in one schema document, the hybrid schema uses
skipping to change at page 25, line 50 skipping to change at page 22, line 22
Both YANG and RELAX NG offer means for modularity, i.e., for Both YANG and RELAX NG offer means for modularity, i.e., for
splitting the contents of a full schema into separate modules and splitting the contents of a full schema into separate modules and
combining or reusing them in various ways. However, the approaches combining or reusing them in various ways. However, the approaches
taken by YANG and RELAX NG differ. Modularity in RELAX NG is taken by YANG and RELAX NG differ. Modularity in RELAX NG is
suitable for ad hoc combinations of a small number of schemas whereas 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 YANG assumes a large set of modules similar to SNMP MIB modules. The
following differences are important: following differences are important:
o In YANG, whenever module A imports module B, it gets access to the o In YANG, whenever module A imports module B, it gets access to the
definitions (groupings and typedefs) appearing at the top level of definitions (groupings and typedefs) appearing at the top level of
module B. However, no part of data tree from module B is imported 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 along with it. In contrast, the <rng:include> pattern in RELAX NG
imports both definitions of named patterns and the entire schema imports both definitions of named patterns and the entire schema
tree from the included schema. tree from the included schema.
o The names of imported YANG groupings and typedefs are qualified o The names of imported YANG groupings and typedefs are qualified
with the namespace of the imported module. On the other hand, the with the namespace of the imported module. On the other hand, the
names of data nodes contained inside the imported groupings, when names of data nodes contained inside the imported groupings, when
used within the importing module, become part of the importing used within the importing module, become part of the importing
module's namespace. In RELAX NG, the names of patterns are module's namespace. In RELAX NG, the names of patterns are
unqualified and so named patterns defined in both the importing unqualified and so named patterns defined in both the importing
and imported module share the same flat namespace. The contents and imported module share the same flat namespace. The contents
of RELAX NG named patterns may either keep the namespace of the of RELAX NG named patterns may either keep the namespace of the
schema where they are defined or inherit the namespace of the schema where they are defined or inherit the namespace of the
importing module, analogically to YANG. However, in order to importing module, analogically to YANG. However, in order to
achieve the latter behavior, the definitions of named patterns achieve the latter behavior, the definitions of named patterns
must be included from an external schema which has to be prepared must be included from an external schema, which has to be prepared
in a special way (see [Vli04], Chapter 11). in a special way (see [Vli04], Chapter 11).
In order to map, as much as possible, the modularity of YANG to RELAX 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 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 step) has to be split into two files, one of them containing all
global definitions that are mapped from top-level YANG groupings global definitions that are mapped from top-level YANG groupings
appearing in all input YANG module. This RELAX NG schema MUST NOT appearing in all input YANG module. This RELAX NG schema MUST NOT
define any namespace via the @ns attribute. define any namespace via the @ns attribute.
The other RELAX NG schema file then defines actual data trees mapped The other RELAX NG schema file then defines actual data trees mapped
from input YANG modules, each of them enclosed in an own embedded from input YANG modules, each of them enclosed in an own embedded
grammar. Those embedded grammars in which at least one of the global grammar. Those embedded grammars, in which at least one of the
definitions is used MUST include the first schema with definitions global definitions is used, MUST include the first schema with
and also MUST define the local namespace using the @ns attribute. definitions and also MUST define the local namespace using the @ns
This way, the global definitions can be used inside different attribute. This way, the global definitions can be used inside
embedded grammar, each time accepting a different local namespace. different embedded grammar, each time accepting a different local
namespace.
Named pattern definition that are mapped from non-top-level YANG Named pattern definitions that are mapped from non-top-level YANG
groupings MUST be placed inside the embedded grammar corresponding to groupings MUST be placed inside the embedded grammar corresponding to
the YANG module where the grouping is defined. the YANG module where the grouping is defined.
In the hybrid schema, we need to distinguish the global and non- In the hybrid schema, we need to distinguish the global and non-
global named pattern definitions while still keeping the hybrid global named pattern definitions while still keeping the hybrid
schema in one file. This is accomplished in the following way: schema in one file. This is accomplished in the following way:
o Every global definition MUST be placed as a child of the the outer o Every global definition MUST be placed as a child of the outer
<rng:grammar> element (the document root of the hybrid schema). <rng:grammar> element (the document root of the hybrid schema).
o Every non-global definitions MUST be placed as a child of the o Every non-global definitions MUST be placed as a child of the
corresponding embedded <rng:grammar> element. corresponding embedded <rng:grammar> element.
YANG also allows for splitting a module into a number of submodules. YANG also allows for splitting a module into a number of submodules.
However, as submodules have no impact on the scope of identifiers and However, as submodules have no impact on the scope of identifiers and
namespaces, the modularity based on submodules is not mapped in any namespaces, the modularity based on submodules is not mapped in any
way. The contents of submodules is therefore handled as if the way. The contents of submodules is therefore handled as if the
submodule text appeared directly in the main module. submodule text appeared directly in the main module.
8.3. Granularity 8.3. Granularity
RELAX NG supports different styles of schema structuring: One RELAX NG supports different styles of schema structuring: one
extreme, often called "Russian Doll", specifies the structure of an extreme, often called "Russian Doll", specifies the structure of an
XML instance document in a single hierarchy. The other extreme, the XML instance document in a single hierarchy. The other extreme, the
flat style, uses a similar approach as the Data Type Definition (DTD) flat style, uses a similar approach as the Data Type Definition (DTD)
schema language - every XML element corresponds to a named pattern schema language -- every XML element corresponds to a named pattern
definition. In practice, some compromise between the two extremes is definition. In practice, some compromise between the two extremes is
usually chosen. usually chosen.
YANG supports both styles in principle, too, but in most cases the YANG supports both styles in principle, too, but in most cases the
modules are organized in a way closer to the "Russian Doll" style, modules are organized in a way closer to the "Russian Doll" style,
which provides a better insight into the structure of the which provides a better insight into the structure of the
configuration data. Groupings are usually defined only for contents configuration data. Groupings are usually defined only for contents
that are prepared for reuse in multiple places via the 'uses' that are prepared for reuse in multiple places via the 'uses'
statement. In contrast, RELAX NG schemas tend to be much flatter, statement. In contrast, RELAX NG schemas tend to be much flatter,
because finer granularity is also needed in RELAX NG for because finer granularity is also needed in RELAX NG for
extensibility of the schemas - it is only possible to replace or extensibility of the schemas -- it is only possible to replace or
modify schema fragments that are factored out as named patterns. For modify schema fragments that are factored out as named patterns. For
YANG this is not an issue since its 'augment' and 'refine' statements YANG, this is not an issue since its 'augment' and 'refine'
can delve, by using path expressions, into arbitrary depths of statements can delve, by using path expressions, into arbitrary
existing structures. depths of existing structures.
In general, it not feasible to map YANG's powerful extension In general, it is not feasible to map YANG's powerful extension
mechanisms to those available in RELAX NG. For this reason, the mechanisms to those available in RELAX NG. For this reason, the
mapping essentially keeps the granularity of the original YANG data mapping essentially keeps the granularity of the original YANG data
model: YANG groupings and definitions of derived types usually have model: YANG groupings and definitions of derived types usually have
direct counterparts in definitions of named patterns in the resulting direct counterparts in definitions of named patterns in the resulting
RELAX NG schema. RELAX NG schema.
8.4. Handling of XML Namespaces 8.4. Handling of XML Namespaces
Most modern XML schema languages, including RELAX NG, Schematron and Most modern XML schema languages, including RELAX NG, Schematron, and
DSRL, support schemas for so-called compound XML documents which DSRL, support schemas for so-called compound XML documents that
contain elements from multiple namespaces. This is useful for our contain elements from multiple namespaces. This is useful for our
purpose since the YANG-to-DSDL mapping allows for multiple input YANG purpose since the YANG-to-DSDL mapping allows for multiple input YANG
modules, which naturally leads to compound document schemas. modules, which naturally leads to compound document schemas.
RELAX NG offers two alternatives for defining the target namespaces RELAX NG offers two alternatives for defining the target namespaces
in the schema: in the schema:
1. First possibility is the traditional XML way via the @xmlns:xxx 1. First possibility is the traditional XML way via the @xmlns:xxx
attribute. attribute.
skipping to change at page 29, line 8 skipping to change at page 25, line 8
DSRL schemas may declare any number of target namespaces via the DSRL schemas may declare any number of target namespaces via the
standard XML attributes xmlns:xxx. standard XML attributes xmlns:xxx.
In contrast, Schematron requires all used namespaces to be defined in In contrast, Schematron requires all used namespaces to be defined in
the <sch:ns> subelements of the document element <sch:schema>. the <sch:ns> subelements of the document element <sch:schema>.
9. Mapping YANG Data Models to the Hybrid Schema 9. Mapping YANG Data Models to the Hybrid Schema
This section explains the main principles governing the first step of This section explains the main principles governing the first step of
the mapping. Its result is the hybrid schema which is described in the mapping. Its result is the hybrid schema that is described in
Section 8.1. Section 8.1.
A detailed specification of the mapping of individual YANG statements A detailed specification of the mapping of individual YANG statements
is contained in the following Section 10. is contained in Section 10.
9.1. Occurrence Rules for Data Nodes 9.1. Occurrence Rules for Data Nodes
In DSDL schema languages, occurrence constraints for a node are In DSDL schema languages, occurrence constraints for a node are
always localized together with that node. In a RELAX NG schema, for always localized together with that node. In a RELAX NG schema, for
example, <rng:optional> pattern appears as the parent element of the example, the <rng:optional> pattern appears as the parent element of
pattern defining a leaf or non-leaf element. Similarly, DSRL the pattern defining a leaf or non-leaf element. Similarly, DSRL
specifies default contents separately for every single node, be it a specifies default contents separately for every single node, be it a
leaf or non-leaf element. leaf or non-leaf element.
For leaf nodes in YANG modules, the occurrence constraints are also For leaf nodes in YANG modules, the occurrence constraints are also
easily inferred from the substatements of 'leaf'. On the other hand, easily inferred from the substatements of 'leaf'. On the other hand,
for a YANG container it is often necessary to examine its entire for a YANG container, it is often necessary to examine its entire
subtree in order to determine the container's occurrence constraints. subtree in order to determine the container's occurrence constraints.
Therefore, one of the goals of the first mapping step is to infer the Therefore, one of the goals of the first mapping step is to infer the
occurrence constraints for all data nodes and mark accordingly the occurrence constraints for all data nodes and mark, accordingly, the
corresponding <rng:element> patterns in the hybrid schema so that any corresponding <rng:element> patterns in the hybrid schema so that any
transformation procedure in the second mapping step can simply use transformation procedure in the second mapping step can simply use
this information and need not examine the subtree again. this information and need not examine the subtree again.
First, it has to be decided whether a given data node must always be 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 present in a valid configuration. If so, such a node is called
mandatory, otherwise it is called optional. This constraint is mandatory, otherwise it is called optional. This constraint is
closely related to the notion of mandatory nodes in Section 3.1 in closely related to the notion of mandatory nodes in Section 3.1 in
[RFC6020]. The only difference is that this document also considers [RFC6020]. The only difference is that this document also considers
list keys to be mandatory. list keys to be mandatory.
The other occurrence constraint has to do with the semantics of the The other occurrence constraint has to do with the semantics of the
'default' statement and the possibility of removing empty non- 'default' statement and the possibility of removing empty non-
presence containers. As a result, the information set of a valid presence containers. As a result, the information set of a valid
configuration may be modified by adding or removing certain leaf or configuration may be modified by adding or removing certain leaf or
container elements without changing the meaning of the configuration. container elements without changing the meaning of the configuration.
In this document, such elements are called implicit. In the hybrid In this document, such elements are called implicit. In the hybrid
schema, they can be identified as RELAX NG patterns having either schema, they can be identified as RELAX NG patterns having either the
@nma:default or @nma:implicit attribute. @nma:default or the @nma:implicit attribute.
Note that both occurrence constraints apply to containers at the top Note that both occurrence constraints apply to containers at the top
level of the data tree, and then also to other containers under the level of the data tree, and then also to other containers under the
additional condition that their parent node exists in the instance additional condition that their parent node exists in the instance
document. For example, consider the following YANG fragment: document. For example, consider the following YANG fragment:
container outer { container outer {
presence 'Presence of "outer" means something.'; presence 'Presence of "outer" means something.';
container c1 { container c1 {
leaf foo { leaf foo {
skipping to change at page 30, line 33 skipping to change at page 26, line 37
mandatory true; mandatory true;
} }
} }
} }
Here, container "outer" has the 'presence' substatement, which means Here, container "outer" has the 'presence' substatement, which means
that it is optional and not implicit. If "outer" is not present in a that it is optional and not implicit. If "outer" is not present in a
configuration, its child containers are not present as well. configuration, its child containers are not present as well.
However, if "outer" does exist, it makes sense to ask which of its However, if "outer" does exist, it makes sense to ask which of its
child containers are optional and which are implicit. In this case, child containers are optional and which are implicit. In this case,
"c1" is optional and implicit, "c2" is optional but not implicit and "c1" is optional and implicit, "c2" is optional but not implicit, and
"c3" is mandatory (and therefore not implicit). "c3" is mandatory (and therefore not implicit).
The following subsections give precise rules for determining whether The following subsections give precise rules for determining whether
a container is optional or mandatory and whether it is implicit. In a container is optional or mandatory and whether it is implicit. In
order to simplify the recursive definition of these occurrence order to simplify the recursive definition of these occurrence
characteristics, it is useful to define them also for other types of characteristics, it is useful to define them also for other types of
YANG schema nodes, i.e., leaf, list, leaf-list and anyxml and choice. YANG schema nodes, i.e., leaf, list, leaf-list, anyxml, and choice.
9.1.1. Optional and Mandatory Nodes 9.1.1. Optional and Mandatory Nodes
The decision whether a given node is mandatory or optional is The decision whether a given node is mandatory or optional is
governed by the following rules: governed by the following rules:
o Leaf, anyxml and choice nodes are mandatory if they contain the o Leaf, anyxml, and choice nodes are mandatory if they contain the
substatement "mandatory true;". For a choice node this means that substatement "mandatory true;". For a choice node, this means
at least one node from exactly one case branch must exist. 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 o In addition, a leaf node is mandatory if it is declared as a list
key. key.
o A list or leaf-list node is mandatory if it contains the 'min- o A list or leaf-list node is mandatory if it contains the 'min-
elements' substatement with an argument value greater than zero. elements' substatement with an argument value greater than zero.
o A container node is mandatory if its definition does not contain o A container node is mandatory if its definition does not contain
the 'presence' substatement and at least one of its child nodes is the 'presence' substatement and at least one of its child nodes is
mandatory. mandatory.
A node which is not mandatory is said to be optional. A node that is not mandatory is said to be optional.
In RELAX NG, definitions of nodes that are optional must be In RELAX NG, definitions of nodes that are optional must be
explicitly wrapped in the <rng:optional> element. The mapping MUST explicitly wrapped in the <rng:optional> element. The mapping MUST
use the above rules to determine whether a YANG node is optional and use the above rules to determine whether a YANG node is optional, and
if so, insert the <rng:optional> element in the hybrid schema. if so, insert the <rng:optional> element in the hybrid schema.
However, alternatives in <rng:choice> MUST NOT be defined as optional However, alternatives in <rng:choice> MUST NOT be defined as optional
in the hybrid schema. If a choice in YANG is not mandatory, <rng: in the hybrid schema. If a choice in YANG is not mandatory, <rng:
optional> MUST be used to wrap the entire <rng:choice> pattern. optional> MUST be used to wrap the entire <rng:choice> pattern.
9.1.2. Implicit Nodes 9.1.2. Implicit Nodes
The following rules are used to determine whether a given data node The following rules are used to determine whether a given data node
is implicit: is implicit:
o List, leaf-list and anyxml nodes are never 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, o A leaf node is implicit if and only if it has a default value,
defined either directly or via its datatype. defined either directly or via its data type.
o A container node is implicit if and only if it does not have the 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 'presence' substatement, none of its children are mandatory, and
least one child is implicit. at least one child is implicit.
In the hybrid schema, all implicit containers, as well as leafs that 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: obtain their default value from a typedef and don't have the @nma:
default attribute, MUST be marked with @nma:implicit attribute having default attribute, MUST be marked with @nma:implicit attribute having
the value of "true". the value of "true".
Note that Section 7.9.3 in [RFC6020] specifies other rules that must Note that Section 7.9.3 in [RFC6020] specifies other rules that must
be taken into account when deciding whether a given container or leaf be taken into account when deciding whether or not a given container
appearing inside a case of a choice is ultimately implicit or not. or leaf appearing inside a case of a choice is ultimately implicit.
Specifically, a leaf or container under a case can be implicit only Specifically, a leaf or container under a case can be implicit only
if the case appears in the argument of the choice's 'default' if the case appears in the argument of the choice's 'default'
statement. However, this is not sufficient by itself but also statement. However, this is not sufficient by itself but also
depends on the particular instance XML document, namely on the depends on the particular instance XML document, namely on the
presence or absence of nodes from other (non-default) cases. The presence or absence of nodes from other (non-default) cases. The
details are explained in Section 11.3. details are explained in Section 11.3.
9.2. Mapping YANG Groupings and Typedefs 9.2. Mapping YANG Groupings and Typedefs
YANG groupings and typedefs are generally mapped to RELAX NG named YANG groupings and typedefs are generally mapped to RELAX NG named
patterns. There are, however, several caveats that the mapping has patterns. There are, however, several caveats that the mapping has
to take into account. to take into account.
First of all, YANG typedefs and groupings may appear at all levels of First of all, YANG typedefs and groupings may appear at all levels of
the module hierarchy and are subject to lexical scoping, see Section the module hierarchy and are subject to lexical scoping, see Section
5.5 in [RFC6020]. Second, top-level symbols from external modules 5.5 in [RFC6020]. Second, top-level symbols from external modules
may be imported as qualified names represented using the external may be imported as qualified names represented using the external
module namespace prefix and the name of the symbol. In contrast, module namespace prefix and the name of the symbol. In contrast,
named patterns in RELAX NG (both local and imported via the <rng: named patterns in RELAX NG (both local and imported via the <rng:
include> pattern) share the same namespace and within a grammar they include> pattern) share the same namespace and within a grammar they
are always global - their definitions may only appear at the top are always global -- their definitions may only appear at the top
level as children of the <rng:grammar> element. Consequently, level as children of the <rng:grammar> element. Consequently,
whenever YANG groupings and typedefs are mapped to RELAX NG named whenever YANG groupings and typedefs are mapped to RELAX NG named
pattern definitions, their names MUST be disambiguated in order to pattern definitions, their names MUST be disambiguated in order to
avoid naming conflicts. The mapping uses the following procedure for avoid naming conflicts. The mapping uses the following procedure for
mangling the names of groupings and type definitions: mangling the names of groupings and type definitions:
o Names of groupings and typedefs appearing at the top level of the o Names of groupings and typedefs appearing at the top level of the
YANG module hierarchy are prefixed with the module name and two YANG module hierarchy are prefixed with the module name and two
underscore characters ("__"). underscore characters ("__").
o Names of other groupings and typedefs, i.e., those that do not 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 appear at the top level of a YANG module, are prefixed with the
module name, double underscore, and then the names of all ancestor module name, double underscore, and then the names of all ancestor
data nodes separated by double underscore. data nodes separated by double underscore.
o Finally, since the names of groupings and typedefs in YANG have o Finally, since the names of groupings and typedefs in YANG have
different namespaces, an additional underscore character is added different namespaces, an additional underscore character is added
to the beginning of the mangled names of all groupings. to the beginning of the mangled names of all groupings.
An additional complication is caused by the YANG rules for subelement 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 ordering (see, e.g., Section 7.5.7 in [RFC6020]): in RPC input and
output parameters, subelements must follow the order specified in the output parameters, subelements must follow the order specified in the
data model, otherwise the order is arbitrary. Consequently, if a data model; otherwise, the order is arbitrary. Consequently, if a
grouping is used both in RPC input/output parameters and elsewhere, grouping is used both in RPC input/output parameters and elsewhere,
it MUST be mapped to two different named pattern definitions - one it MUST be mapped to two different named pattern definitions -- one
with fixed order and the other with arbitrary order. To distinguish with fixed order and the other with arbitrary order. To distinguish
them, the "__rpc" suffix MUST be appended to the version with fixed them, the "__rpc" suffix MUST be appended to the version with fixed
order. order.
EXAMPLE. Consider the following YANG module which imports the EXAMPLE. Consider the following YANG module that imports the
standard module "ietf-inet-types" [RFC6021]: standard module "ietf-inet-types" [RFC6021]:
module example1 { module example1 {
namespace "http://example.com/ns/example1"; namespace "http://example.com/ns/example1";
prefix ex1; prefix ex1;
typedef vowels { typedef vowels {
type string { type string {
pattern "[aeiouy]*"; pattern "[aeiouy]*";
} }
} }
skipping to change at page 33, line 46 skipping to change at page 29, line 49
<rng:optional> <rng:optional>
<rng:element name="void"> <rng:element name="void">
<rng:empty/> <rng:empty/>
</rng:element> </rng:element>
</rng:optional> </rng:optional>
</rng:define> </rng:define>
9.2.1. YANG Refinements and Augments 9.2.1. YANG Refinements and Augments
YANG groupings represent a similar concept as named pattern YANG groupings represent a similar concept as named pattern
definitions in RELAX NG and both languages also offer mechanisms for definitions in RELAX NG, and both languages also offer mechanisms for
their subsequent modification. However, in RELAX NG the definitions their subsequent modification. However, in RELAX NG, the definitions
themselves are modified whereas YANG provides two substatements of themselves are modified, whereas YANG provides two substatements of
'uses' which modify expansions of groupings: 'uses', which modify expansions of groupings:
o 'refine' statement allows for changing parameters of a schema node o The 'refine' statement allows for changing parameters of a schema
inside the grouping referenced by the parent 'uses' statement; node inside the grouping referenced by the parent 'uses'
statement;
o 'augment' statement can be used for adding new schema nodes to the o The 'augment' statement can be used for adding new schema nodes to
grouping contents. the grouping contents.
Both 'refine' and 'augment' statements are quite powerful in that Both 'refine' and 'augment' statements are quite powerful in that
they can address, using XPath-like expressions as their arguments, they can address, using XPath-like expressions as their arguments,
schema nodes that are arbitrarily deep inside the grouping contents. schema nodes that are arbitrarily deep inside the grouping contents.
In contrast, modifications of named pattern definitions in RELAX NG In contrast, modifications of named pattern definitions in RELAX NG
are applied exclusively at the topmost level of the named pattern are applied exclusively at the topmost level of the named pattern
contents. In order to achieve a modifiability of named patterns contents. In order to achieve a modifiability of named patterns
comparable to YANG, a RELAX NG schema would have to be extremely flat comparable to YANG, a RELAX NG schema would have to be extremely flat
(cf. Section 8.3) and very difficult to read. (cf. Section 8.3) and very difficult to read.
Since the goal of the mapping described in this document is to Since the goal of the mapping described in this document is to
generate ad hoc DSDL schemas, we decided to avoid these complications generate ad hoc DSDL schemas, we decided to avoid these complications
and instead expand the grouping and refine and/or augment it "in and instead expand the grouping and refine and/or augment it "in
place". In other words, every 'uses' statement which has 'refine' place". In other words, every 'uses' statement that has 'refine'
and/or 'augment' substatements is replaced by the contents of the and/or 'augment' substatements is replaced by the contents of the
corresponding grouping, the changes specified in the 'refine' and corresponding grouping, the changes specified in the 'refine' and
'augment' statements are applied and the resulting YANG schema 'augment' statements are applied, and the resulting YANG schema
fragment is mapped as if the 'uses'/'grouping' indirection wasn't fragment is mapped as if the 'uses'/'grouping' indirection wasn't
there. there.
If there are further 'uses' statements inside the grouping contents, If there are further 'uses' statements inside the grouping contents,
they may require expansion, too: it is necessary if the contained they may require expansion, too: it is necessary if the contained
'uses'/'grouping' pair lies on the "modification path" specified in 'uses'/'grouping' pair lies on the "modification path" specified in
the argument of a 'refine' or 'augment' statement. the argument of a 'refine' or 'augment' statement.
EXAMPLE. Consider the following YANG module: EXAMPLE. Consider the following YANG module:
skipping to change at page 35, line 4 skipping to change at page 31, line 26
type string; type string;
} }
} }
grouping es { grouping es {
leaf hoja { leaf hoja {
type string; type string;
} }
} }
uses leaves; uses leaves;
} }
The resulting hybrid schema contains three global named pattern The resulting hybrid schema contains three global named pattern
definitions corresponding to the three groupings, namely definitions corresponding to the three groupings, namely:
<rng:define name="_example2__leaves"> <rng:define name="_example2__leaves">
<rng:interleave> <rng:interleave>
<rng:ref name="_example2__fr"/> <rng:ref name="_example2__fr"/>
<rng:ref name="_example2__es"/> <rng:ref name="_example2__es"/>
</rng:interleave> </rng:interleave>
</rng:define> </rng:define>
<rng:define name="_example2__fr"> <rng:define name="_example2__fr">
<rng:optional> <rng:optional>
skipping to change at page 36, line 19 skipping to change at page 32, line 40
<rng:element name="ex2:hoja" nma:default="alamo"> <rng:element name="ex2:hoja" nma:default="alamo">
<rng:data type="string"/> <rng:data type="string"/>
</rng:element> </rng:element>
</rng:optional> </rng:optional>
</rng:interleave> </rng:interleave>
</nma:data> </nma:data>
9.2.2. Type Derivation Chains 9.2.2. Type Derivation Chains
RELAX NG has no equivalent of the type derivation mechanism in YANG RELAX NG has no equivalent of the type derivation mechanism in YANG
that allows to restrict a built-in type (perhaps in multiple steps) that allows one to restrict a built-in type (perhaps in multiple
by adding new constraints. Whenever a derived YANG type is used steps) by adding new constraints. Whenever a derived YANG type is
without restrictions - as a substatement of either 'leaf' or another used without restrictions -- as a substatement of either 'leaf' or
'typedef' - then the 'type' statement is mapped simply to a named another 'typedef' -- then the 'type' statement is mapped simply to a
pattern reference <rng:ref>, and the type definition is mapped to a named pattern reference <rng:ref>, and the type definition is mapped
RELAX NG named pattern definition <rng:define>. However, if any to a RELAX NG named pattern definition <rng:define>. However, if any
restrictions are specified as substatements of the 'type' statement, restrictions are specified as substatements of the 'type' statement,
the type definition MUST be expanded at that point so that only the the type definition MUST be expanded at that point so that only the
ancestor built-in type appears in the hybrid schema, restricted with ancestor built-in type appears in the hybrid schema, restricted with
facets that correspond to the combination of all restrictions found facets that correspond to the combination of all restrictions found
along the type derivation chain and also in the 'type' statement. along the type derivation chain and also in the 'type' statement.
EXAMPLE. Consider this YANG module: EXAMPLE. Consider this YANG module:
module example3 { module example3 {
namespace "http://example.com/ns/example3"; namespace "http://example.com/ns/example3";
skipping to change at page 37, line 12 skipping to change at page 33, line 32
name="example3__dozen"/> and the corresponding named pattern is name="example3__dozen"/> and the corresponding named pattern is
defined as follows: defined as follows:
<rng:define name="example3__dozen"> <rng:define name="example3__dozen">
<rng:data type="unsignedByte"> <rng:data type="unsignedByte">
<rng:param name="minInclusive">1</rng:param> <rng:param name="minInclusive">1</rng:param>
<rng:param name="maxInclusive">12</rng:param> <rng:param name="maxInclusive">12</rng:param>
</rng:data> </rng:data>
</rng:define> </rng:define>
Assume now that the definition of leaf "month" is changed to Assume now that the definition of leaf "month" is changed to:
leaf month { leaf month {
type dozen { type dozen {
range 7..max; range 7..max;
} }
} }
The output RELAX NG schema then will not contain any named pattern The output RELAX NG schema then will not contain any named pattern
definition and the leaf "month" will be mapped directly to definition and the leaf "month" will be mapped directly to:
<rng:element name="ex3:month"> <rng:element name="ex3:month">
<rng:data type="unsignedByte"> <rng:data type="unsignedByte">
<rng:param name="minInclusive">7</rng:param> <rng:param name="minInclusive">7</rng:param>
<rng:param name="maxInclusive">12</rng:param> <rng:param name="maxInclusive">12</rng:param>
</rng:data> </rng:data>
</rng:element> </rng:element>
The mapping of type derivation chains may be further complicated by The mapping of type derivation chains may be further complicated by
the presence of the 'default' statement in type definitions. In the the presence of the 'default' statement in type definitions. In the
simple case, when a type definition containing the 'default' simple case, when a type definition containing the 'default'
statement is used without restrictions, the 'default' statement is statement is used without restrictions, the 'default' statement is
mapped to the @nma:default attribute attached to the <rng:define> mapped to the @nma:default attribute attached to the <rng:define>
element. element.
However, if that type definition has to be expanded due to However, if that type definition has to be expanded due to
restrictions, the @nma:default annotation arising from the expanded restrictions, the @nma:default attribute arising from the expanded
type or ancestor types in the type derivation chain MUST be attached type or ancestor types in the type derivation chain MUST be attached
to the pattern where the expansion occurs. If there are multiple to the pattern where the expansion occurs. If there are multiple
'default' statements in consecutive steps of the type derivation, 'default' statements in consecutive steps of the type derivation,
only the 'default' statement that is closest to the expanded type is only the 'default' statement that is closest to the expanded type is
used. used.
EXAMPLE. Consider this variation of the last example: EXAMPLE. Consider this variation of the last example:
module example3bis { module example3bis {
namespace "http://example.com/ns/example3bis"; namespace "http://example.com/ns/example3bis";
skipping to change at page 38, line 30 skipping to change at page 34, line 43
named pattern definition: named pattern definition:
<rng:define name="example3bis__dozen" @nma:default="7"> <rng:define name="example3bis__dozen" @nma:default="7">
<rng:data type="unsignedByte"> <rng:data type="unsignedByte">
<rng:param name="minInclusive">1</rng:param> <rng:param name="minInclusive">1</rng:param>
<rng:param name="maxInclusive">12</rng:param> <rng:param name="maxInclusive">12</rng:param>
</rng:data> </rng:data>
</rng:define> </rng:define>
If the "dozen" type is restricted when used in the leaf "month" If the "dozen" type is restricted when used in the leaf "month"
definition as in the previous example, the "dozen" type has to be definition, as in the previous example, the "dozen" type has to be
expanded and @nma:default becomes an attribute of the <ex3bis:month> expanded and @nma:default becomes an attribute of the <ex3bis:month>
element definition: element definition:
<rng:element name="ex3bis:month" @nma:default="7"> <rng:element name="ex3bis:month" @nma:default="7">
<rng:data type="unsignedByte"> <rng:data type="unsignedByte">
<rng:param name="minInclusive">7</rng:param> <rng:param name="minInclusive">7</rng:param>
<rng:param name="maxInclusive">12</rng:param> <rng:param name="maxInclusive">12</rng:param>
</rng:data> </rng:data>
</rng:element> </rng:element>
However, if the definition of the leaf "month" itself contained the However, if the definition of the leaf "month" itself contained the
'default' substatement, the default specified for the "dozen" type 'default' substatement, the default specified for the "dozen" type
would be ignored. would be ignored.
9.3. Translation of XPath Expressions 9.3. Translation of XPath Expressions
YANG uses full XPath 1.0 syntax [XPath] for the arguments of 'must', 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 'when', and 'path' statements. As the names of data nodes defined in
a YANG module always belong to the namespace of that YANG module, a YANG module always belong to the namespace of that YANG module,
YANG adopted a simplification similar to the concept of default YANG adopted a simplification similar to the concept of default
namespace in XPath 2.0: node names in XPath expressions needn't carry 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 a namespace prefix inside the module where they are defined and the
local module's namespace is assumed. local module's namespace is assumed.
Consequently, all XPath expressions MUST be translated into a fully Consequently, all XPath expressions MUST be translated into a fully
conformant XPath 1.0 expression: Every unprefixed node name MUST be conformant XPath 1.0 expression: every unprefixed node name MUST be
prepended with the local module's namespace prefix as declared by the prepended with the local module's namespace prefix as declared by the
'prefix' statement. 'prefix' statement.
XPath expressions appearing inside top-level groupings require XPath expressions appearing inside top-level groupings require
special attention because all unprefixed node names contained in them special attention because all unprefixed node names contained in them
must adopt the namespace of each module where the grouping is used 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 (cf. Section 8.2). In order to achieve this, the local prefix MUST
represented using the variable "$pref" in the hybrid schema. A be represented using the variable "$pref" in the hybrid schema. A
Schematron schema which encounters such an XPath expression then Schematron schema which encounters such an XPath expression then
supplies an appropriate value for this variable via a parameter to an supplies an appropriate value for this variable via a parameter to an
abstract pattern to which the YANG grouping is mapped (see abstract pattern to which the YANG grouping is mapped (see
Section 11.2). Section 11.2).
For example, XPath expression "/dhcp/max-lease-time" appearing in a For example, XPath expression "/dhcp/max-lease-time" appearing in a
YANG module with the "dhcp" prefix will be translated to YANG module with the "dhcp" prefix will be translated to:
o "$pref:dhcp/$pref:max-lease-time", if the expression is inside a o "$pref:dhcp/$pref:max-lease-time", if the expression is inside a
top-level grouping; top-level grouping;
o "dhcp:dhcp/dhcp:max-lease-time", otherwise. o "dhcp:dhcp/dhcp:max-lease-time", otherwise.
YANG also uses other XPath-like expressions, namely key identifiers YANG also uses other XPath-like expressions, namely key identifiers
and "descendant schema node identifiers" (see the ABNF production for and "descendant schema node identifiers" (see the ABNF production for
and "descendant-schema-nodeid" in Section 12 of [RFC6020]). These and "descendant-schema-nodeid" in Section 12 of [RFC6020]). These
expressions MUST be translated by adding local module prefixes as expressions MUST be translated by adding local module prefixes as
well. well.
9.4. YANG Language Extensions 9.4. YANG Language Extensions
YANG allows for extending its own language in-line by adding new YANG allows for extending its own language in-line by adding new
statements with keywords from special namespaces. Such extensions statements with keywords from special namespaces. Such extensions
first have to be declared using the 'extension' statement and then first have to be declared using the 'extension' statement, and then
they can be used as the standard YANG statements, from which they are they can be used as the standard YANG statements, from which they are
distinguished by a namespace prefix qualifying the extension keyword. distinguished by a namespace prefix qualifying the extension keyword.
RELAX NG has a similar extension mechanism - XML elements and RELAX NG has a similar extension mechanism -- XML elements and
attributes with names from foreign namespaces may be inserted at attributes with names from foreign namespaces may be inserted at
almost any place of a RELAX NG schema. almost any place of a RELAX NG schema.
YANG language extensions may or may not have a meaning in the context 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 DSDL schemas. Therefore, an implementation MAY ignore any or all
of the extensions. However, an extension that is not ignored MUST be 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 mapped to XML element(s) and/or attribute(s) that exactly match the
YIN form of the extension, see Section 11.1 in [RFC6020]. YIN form of the extension, see Section 11.1 in [RFC6020].
EXAMPLE. Consider the following extension defined by the "acme" EXAMPLE. Consider the following extension defined by the "acme"
skipping to change at page 40, line 20 skipping to change at page 36, line 43
} }
This extension can then be used in the same or another module, for This extension can then be used in the same or another module, for
instance like this: instance like this:
leaf folio { leaf folio {
acme:documentation-flag 42; acme:documentation-flag 42;
type string; type string;
} }
If this extension is honored by the mapping, it will be mapped to If this extension is honored by the mapping, it will be mapped to:
<rng:element name="acme:folio"> <rng:element name="acme:folio">
<acme:documentation-flag number="42"/> <acme:documentation-flag number="42"/>
<rng:data type="string"/> <rng:data type="string"/>
</rng:element> </rng:element>
Note that the 'extension' statement itself is not mapped in any way. Note that the 'extension' statement itself is not mapped in any way.
10. Mapping YANG Statements to the Hybrid Schema 10. Mapping YANG Statements to the Hybrid Schema
Each subsection in this section is devoted to one YANG statement and Each subsection in this section is devoted to one YANG statement and
provides the specification of how the statement is mapped to the provides the specification of how the statement is mapped to the
hybrid schema. The subsections are sorted alphabetically by the hybrid schema. The subsections are sorted alphabetically by the
statement keyword. statement keyword.
Each YANG statement is mapped to an XML fragment, typically a single Each YANG statement is mapped to an XML fragment, typically a single
element or attribute but it may also be a larger structure. The element or attribute, but it may also be a larger structure. The
mapping procedure is inherently recursive, which means that after mapping procedure is inherently recursive, which means that after
finishing a statement the mapping continues with its substatements, finishing a statement the mapping continues with its substatements,
if there are any, and a certain element of the resulting fragment if there are any, and a certain element of the resulting fragment
becomes the parent of other fragments resulting from the mapping of becomes the parent of other fragments resulting from the mapping of
substatements. Any changes to this default recursive procedure are substatements. Any changes to this default recursive procedure are
explicitly specified. explicitly specified.
YANG XML encoding rules translate to the following rules for ordering YANG XML encoding rules translate to the following rules for ordering
multiple subelements: multiple subelements:
skipping to change at page 41, line 48 skipping to change at page 37, line 48
The following conventions are used in this section: The following conventions are used in this section:
o The argument of the statement being mapped is denoted by ARGUMENT. 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 o The element in the RELAX NG schema that becomes the parent of the
resulting XML fragment is denoted by PARENT. resulting XML fragment is denoted by PARENT.
10.1. The 'anyxml' Statement 10.1. The 'anyxml' Statement
This statement is mapped to <rng:element> element and ARGUMENT with This statement is mapped to the <rng:element> element and ARGUMENT
prepended local namespace prefix becomes the value of its @name with prepended local namespace prefix becomes the value of its @name
attribute. The contents of <rng:element> are attribute. The contents of <rng:element> are:
<rng:ref name="__anyxml__"/> <rng:ref name="__anyxml__"/>
Substatements of the 'anyxml' statement, if any, MAY be mapped to Substatements of the 'anyxml' statement, if any, MAY be mapped to
additional children of the <rng:element> element. additional children of the <rng:element> element.
If at least one 'anyxml' statement occurs in any of the input YANG If at least one 'anyxml' statement occurs in any of the input YANG
modules, the following pattern definition MUST be added exactly once modules, the following pattern definition MUST be added exactly once
to the RELAX NG schema as a child of the root <rng:grammar> element to the RELAX NG schema as a child of the root <rng:grammar> element
(cf. [Vli04], p. 172): (cf. [Vli04], p. 172):
skipping to change at page 43, line 35 skipping to change at page 39, line 35
This statement is not used since the processing of submodules is This statement is not used since the processing of submodules is
always initiated from the main module, see Section 10.24. always initiated from the main module, see Section 10.24.
10.6. The 'bit' Statement 10.6. The 'bit' Statement
This statement is handled within the "bits" type, see This statement is handled within the "bits" type, see
Section 10.53.4. Section 10.53.4.
10.7. The 'case' Statement 10.7. The 'case' Statement
This statement is mapped to <rng:group> or <rng:interleave> element, This statement is mapped to the <rng:group> or <rng:interleave>
depending on whether the statement belongs to an definition of an RPC element, depending on whether or not the statement belongs to an
operation or not. If the argument of a sibling 'default' statement definition of an RPC operation. If the argument of a sibling
equals to ARGUMENT, @nma:implicit attribute with the value of "true" 'default' statement equals to ARGUMENT, the @nma:implicit attribute
MUST be added to that <rng:group> or <rng:interleave> element. The with the value of "true" MUST be added to that <rng:group> or <rng:
@nma:implicit attribute MUST NOT be used for nodes at the top-level interleave> element. The @nma:implicit attribute MUST NOT be used
of a non-default case (see Section 7.9.3 in [RFC6020]). for nodes at the top-level of a non-default case (see Section 7.9.3
in [RFC6020]).
10.8. The 'choice' Statement 10.8. The 'choice' Statement
This statement is mapped to <rng:choice> element. This statement is mapped to the <rng:choice> element.
If 'choice' has the 'mandatory' substatement with the value of If 'choice' has the 'mandatory' substatement with the value of
"true", the attribute @nma:mandatory MUST be added to the <rng: "true", the attribute @nma:mandatory MUST be added to the <rng:
choice> element with the value of ARGUMENT. This case may require choice> element with the value of ARGUMENT. This case may require
additional handling, see Section 11.2.1. Otherwise, if "mandatory additional handling, see Section 11.2.1. Otherwise, if "mandatory
true;" is not present, the <rng:choice> element MUST be wrapped in true;" is not present, the <rng:choice> element MUST be wrapped in
<rng:optional>. <rng:optional>.
The alternatives in <rng:choice> - mapped from either the 'case' The alternatives in <rng:choice> -- mapped from either the 'case'
statement or a shorthand case - MUST NOT be defined as optional. statement or a shorthand case -- MUST NOT be defined as optional.
10.9. The 'config' Statement 10.9. The 'config' Statement
This statement is mapped to @nma:config attribute and ARGUMENT This statement is mapped to the @nma:config attribute, and ARGUMENT
becomes its value. becomes its value.
10.10. The 'contact' Statement 10.10. The 'contact' Statement
This statement SHOULD NOT be used by the mapping since the hybrid This statement SHOULD NOT be used by the mapping since the hybrid
schema may be mapped from multiple YANG modules created by different schema may be mapped from multiple YANG modules created by different
authors. The hybrid schema contains references to all input modules authors. The hybrid schema contains references to all input modules
in the Dublin Core elements <dc:source>, see Section 10.34. The in the Dublin Core elements <dc:source>, see Section 10.34. The
original YANG modules are the authoritative sources of the authorship original YANG modules are the authoritative sources of the authorship
information. information.
skipping to change at page 45, line 30 skipping to change at page 41, line 34
EXAMPLE. The following 'choice' statement in a module with namespace EXAMPLE. The following 'choice' statement in a module with namespace
prefix "yam" prefix "yam"
choice leaves { choice leaves {
default feuille; default feuille;
leaf feuille { type empty; } leaf feuille { type empty; }
leaf hoja { type empty; } leaf hoja { type empty; }
} }
is either mapped directly to is either mapped directly to:
<rng:choice> <rng:choice>
<rng:element name="yam:feuille" nma:implicit="true"> <rng:element name="yam:feuille" nma:implicit="true">
<rng:empty/> <rng:empty/>
</rng:element> </rng:element>
<rng:element name="yam:hoja"> <rng:element name="yam:hoja">
<rng:empty/> <rng:empty/>
</rng:element/> </rng:element/>
</rng:choice> </rng:choice>
or the default case may be wrapped in an extra <rng:group>: or the default case may be wrapped in an extra <rng:group>:
<rng:choice> <rng:choice>
<rng:group nma:implicit="true"> <rng:group nma:implicit="true">
<rng:element name="yam:feuille"> <rng:element name="yam:feuille">
<rng:empty/> <rng:empty/>
</rng:element> </rng:element>
</rng:group> </rng:group>
<rng:element name="yam:hoja"> <rng:element name="yam:hoja">
<rng:empty/> <rng:empty/>
skipping to change at page 46, line 21 skipping to change at page 42, line 33
this element SHOULD be inserted as the first child of PARENT. this element SHOULD be inserted as the first child of PARENT.
10.14. The 'deviation' Statement 10.14. The 'deviation' Statement
This statement is ignored. However, it is assumed that all This statement is ignored. However, it is assumed that all
deviations are known beforehand and the corresponding changes have deviations are known beforehand and the corresponding changes have
already been applied to the input YANG modules. already been applied to the input YANG modules.
10.15. The 'enum' Statement 10.15. The 'enum' Statement
This statement is mapped to <rng:value> element and ARGUMENT becomes This statement is mapped to the <rng:value> element, and ARGUMENT
its text. All substatements except 'status' are ignored because the becomes its text. All substatements except 'status' are ignored
<rng:value> element cannot contain annotation elements, see [RNG], because the <rng:value> element cannot contain annotation elements,
section 6. see [RNG], Section 6.
10.16. The 'error-app-tag' Statement 10.16. The 'error-app-tag' Statement
This statement is ignored unless it is a substatement of 'must'. In 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 the latter case, it is mapped to the <nma:error-app-tag> element.
also Section 10.35. See also Section 10.35.
10.17. The 'error-message' Statement 10.17. The 'error-message' Statement
This statement is ignored unless it is a substatement of 'must'. In 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 the latter case, it is mapped to the <nma:error-message> element.
also Section 10.35. See also Section 10.35.
10.18. The 'extension' Statement 10.18. The 'extension' Statement
This statement is ignored. However, extensions to the YANG language This statement is ignored. However, extensions to the YANG language
MAY be mapped as described in Section 9.4. MAY be mapped as described in Section 9.4.
10.19. The 'feature' Statement 10.19. The 'feature' Statement
This statement is ignored. This statement is ignored.
10.20. The 'grouping' Statement 10.20. The 'grouping' Statement
This statement is mapped to a RELAX NG named pattern definition <rng: This statement is mapped to a RELAX NG named pattern definition <rng:
define>, but only if the grouping defined by this statement is used define>, but only if the grouping defined by this statement is used
without refinements and augments in at least one of the input without refinements and augments in at least one of the input
modules. In this case, the named pattern definition becomes a child modules. In this case, the named pattern definition becomes a child
of the <rng:grammar> element and its name is ARGUMENT mangled of the <rng:grammar> element and its name is ARGUMENT mangled
according to the rules specified in Section 9.2. according to the rules specified in Section 9.2.
As explained in Section 8.2, a named pattern definition MUST be As explained in Section 8.2, a named pattern definition MUST be
placed placed:
o as a child of the root <rng:grammar> element if the corresponding 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; grouping is defined at the top level of an input YANG module;
o otherwise as a child of the embedded <rng:grammar> element o otherwise as a child of the embedded <rng:grammar> element
corresponding to the module in which the grouping is defined. corresponding to the module in which the grouping is defined.
Whenever a grouping is used with refinements and/or augments, it is Whenever a grouping is used with refinements and/or augments, it is
expanded so that the refinements and augments may be applied in place expanded so that the refinements and augments may be applied in place
to the prescribed schema nodes. See Section 9.2.1 for further to the prescribed schema nodes. See Section 9.2.1 for further
skipping to change at page 47, line 40 skipping to change at page 44, line 13
which is placed as a child of the root <rng:grammar> element: which is placed as a child of the root <rng:grammar> element:
<rng:define name="__PREFIX_ARGUMENT"> <rng:define name="__PREFIX_ARGUMENT">
<rng:choice> <rng:choice>
<rng:value type="QName">PREFIX:ARGUMENT</rng:value> <rng:value type="QName">PREFIX:ARGUMENT</rng:value>
<rng:ref name="IDENTITY1"/> <rng:ref name="IDENTITY1"/>
... ...
</rng:choice> </rng:choice>
</rng:define> </rng:define>
where where:
PREFIX is the prefix used in the hybrid schema for the namespace PREFIX is the prefix used in the hybrid schema for the namespace
of the module where the current identity is defined. of the module where the current identity is defined.
IDENTITY1 is the name of of the named pattern corresponding to an IDENTITY1 is the name of the named pattern corresponding to an
identity which is derived from the current identity. Exactly one identity that is derived from the current identity. Exactly one
<rng:ref> element MUST be present for every such identity. <rng:ref> element MUST be present for every such identity.
EXAMPLE ([RFC6020], Section 7.16.3). The identities in the input EXAMPLE ([RFC6020], Section 7.16.3). Consider the following
YANG modules identities defined in two input YANG modules:
module crypto-base { module crypto-base {
namespace "http://example.com/crypto-base"; namespace "http://example.com/crypto-base";
prefix "crypto"; prefix "crypto";
identity crypto-alg { identity crypto-alg {
description description
"Base identity from which all crypto algorithms "Base identity from which all crypto algorithms
are derived."; are derived.";
} }
} }
skipping to change at page 48, line 29 skipping to change at page 45, line 4
} }
identity des { identity des {
base "crypto:crypto-alg"; base "crypto:crypto-alg";
description "DES crypto algorithm"; description "DES crypto algorithm";
} }
identity des3 { identity des3 {
base "crypto:crypto-alg"; base "crypto:crypto-alg";
description "Triple DES crypto algorithm"; description "Triple DES crypto algorithm";
} }
} }
The identities will be mapped to the following named pattern
will be mapped to the following named pattern definitions: definitions:
<define name="__crypto_crypto-alg"> <define name="__crypto_crypto-alg">
<choice> <choice>
<value type="QName">crypto:crypto-alg</value> <value type="QName">crypto:crypto-alg</value>
<ref name="__des_des"/> <ref name="__des_des"/>
<ref name="__des_des3"/> <ref name="__des_des3"/>
</choice> </choice>
</define> </define>
<define name="__des_des"> <define name="__des_des">
<value type="QName">des:des</value> <value type="QName">des:des</value>
</define> </define>
<define name="__des_des3"> <define name="__des_des3">
<value type="QName">des:des3</value> <value type="QName">des:des3</value>
</define> </define>
10.22. The 'if-feature' Statement 10.22. The 'if-feature' Statement
ARGUMENT together with arguments of all sibling 'if-feature' ARGUMENT together with arguments of all sibling 'if-feature'
statements (with added prefixes, if missing) MUST be collected in a statements (with added prefixes, if missing) MUST be collected in a
space-separated list which becomes the value of the @nma:if-feature space-separated list that becomes the value of the @nma:if-feature
attribute. This attribute is attached to PARENT. attribute. This attribute is attached to PARENT.
10.23. The 'import' Statement 10.23. The 'import' Statement
This statement is not specifically mapped. The module whose name is 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 in ARGUMENT has to be parsed so that the importing module is able to
use its top-level groupings, typedefs and identities, and also use its top-level groupings, typedefs and identities, and also
augment the data tree of the imported module. augment the data tree of the imported module.
If the 'import' statement has the 'revision' substatement, the If the 'import' statement has the 'revision' substatement, the
skipping to change at page 50, line 7 skipping to change at page 46, line 31
If the leaf is optional, i.e., if there is no "mandatory true;" 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 substatement and the leaf is not declared among the keys of an
enclosing list, then the <rng:element> element MUST be enclosed in enclosing list, then the <rng:element> element MUST be enclosed in
<rng:optional>, except when the 'leaf' statement is a child of the <rng:optional>, except when the 'leaf' statement is a child of the
'choice' statement and thus represents a shorthand case for that 'choice' statement and thus represents a shorthand case for that
choice (see Section 9.1.1 for details). choice (see Section 9.1.1 for details).
10.28. The 'leaf-list' Statement 10.28. The 'leaf-list' Statement
This statement is mapped to a block enclosed by either <rng: This statement is mapped to a block enclosed by either the <rng:
zeroOrMore> or <rng:oneOrMore> element depending on whether the zeroOrMore> or the <rng:oneOrMore> element depending on whether the
argument of 'min-elements' substatement is "0" or positive, argument of 'min-elements' substatement is "0" or positive,
respectively (it is zero by default). This <rng:zeroOrMore> or <rng: respectively (it is zero by default). This <rng:zeroOrMore> or <rng:
oneOrMore> element becomes the PARENT. oneOrMore> element becomes the PARENT.
<rng:element> is then added as a child element of PARENT and ARGUMENT <rng:element> is then added as a child element of PARENT and ARGUMENT
with prepended local namespace prefix becomes the value of its @name with prepended local namespace prefix becomes the value of its @name
attribute. Another attribute, @nma:leaf-list, MUST also be added to attribute. Another attribute, @nma:leaf-list, MUST also be added to
this <rng:element> element with the value of "true". If the 'leaf- this <rng:element> element with the value of "true". If the 'leaf-
list' statement has the 'min-elements' substatement and its argument list' statement has the 'min-elements' substatement and its argument
is greater than one, additional attribute @nma:min-elements is is greater than one, additional attribute @nma:min-elements is
attached to <rng:element> and the argument of 'min-elements' becomes attached to <rng:element> and the argument of 'min-elements' becomes
the value of this attribute. Similarly, if there is the 'max- the value of this attribute. Similarly, if there is the 'max-
elements' substatement and its argument value is not "unbounded", elements' substatement and its argument value is not "unbounded",
attribute @nma:max-elements is attached to this element and the attribute @nma:max-elements is attached to this element and the
argument of 'max-elements' becomes the value of this attribute. argument of 'max-elements' becomes the value of this attribute.
EXAMPLE. A leaf-list appearing in a module with the namespace prefix EXAMPLE. Consider the following 'leaf-list' appearing in a module
"yam" with the namespace prefix "yam":
leaf-list foliage { leaf-list foliage {
min-elements 3; min-elements 3;
max-elements 6378; max-elements 6378;
ordered-by user; ordered-by user;
type string; type string;
} }
is mapped to the following RELAX NG fragment: It is mapped to the following RELAX NG fragment:
<rng:oneOrMore> <rng:oneOrMore>
<rng:element name="yam:foliage" nma:leaf-list="true" <rng:element name="yam:foliage" nma:leaf-list="true"
nma:ordered-by="user" nma:ordered-by="user"
nma:min-elements="3" nma:max-elements="6378"> nma:min-elements="3" nma:max-elements="6378">
<rng:data type="string"/> <rng:data type="string"/>
</rng:element> </rng:element>
</rng:oneOrMore> </rng:oneOrMore>
10.29. The 'length' Statement 10.29. The 'length' Statement
skipping to change at page 51, line 41 skipping to change at page 48, line 21
key clef; key clef;
leaf bar { leaf bar {
type string; type string;
} }
leaf baz { leaf baz {
type string; type string;
} }
uses keygrp; uses keygrp;
} }
is mapped to the following RELAX NG fragment: It is mapped to the following RELAX NG fragment:
<rng:zeroOrMore> <rng:zeroOrMore>
<rng:element name="yam:foo" nma:key="yam:clef"> <rng:element name="yam:foo" nma:key="yam:clef">
<rng:element name="yam:clef"> <rng:element name="yam:clef">
<rng:data type="unsignedByte"/> <rng:data type="unsignedByte"/>
</rng:element> </rng:element>
<rng:interleave> <rng:interleave>
<rng:element name="yam:bar"> <rng:element name="yam:bar">
<rng:data type="string"/> <rng:data type="string"/>
</rng:element> </rng:element>
skipping to change at page 52, line 26 skipping to change at page 48, line 44
</rng:element> </rng:element>
</rng:interleave> </rng:interleave>
</rng:element> </rng:element>
</rng:zeroOrMore> </rng:zeroOrMore>
Note that the "keygrp" grouping is expanded and the definition of Note that the "keygrp" grouping is expanded and the definition of
"yam:clef" is moved before the <rng:interleave> pattern. "yam:clef" is moved before the <rng:interleave> pattern.
10.31. The 'mandatory' Statement 10.31. The 'mandatory' Statement
This statement may appear as a substatement of 'leaf', 'choice' or This statement may appear as a substatement of 'leaf', 'choice', or
'anyxml' statement. If ARGUMENT is "true", the parent data node is 'anyxml' statement. If ARGUMENT is "true", the parent data node is
mapped as mandatory, see Section 9.1.1. mapped as mandatory, see Section 9.1.1.
As a substatement of 'choice', this statement is also mapped to the As a substatement of 'choice', this statement is also mapped to the
@nma:mandatory attribute which is added to PARENT. The value of this @nma:mandatory attribute, which is added to PARENT. The value of
attribute is the argument of the parent 'choice' statement. this attribute is the argument of the parent 'choice' statement.
10.32. The 'max-elements' Statement 10.32. The 'max-elements' Statement
This statement is handled within 'leaf-list' or 'list' statements, This statement is handled within 'leaf-list' or 'list' statements,
see Section 10.28. see Section 10.28.
10.33. The 'min-elements' Statement 10.33. The 'min-elements' Statement
This statement is handled within 'leaf-list' or 'list' statements, This statement is handled within 'leaf-list' or 'list' statements,
see Section 10.28. see Section 10.28.
10.34. The 'module' Statement 10.34. The 'module' Statement
This statement is mapped to an embedded <rng:grammar> pattern having This statement is mapped to an embedded <rng:grammar> pattern having
the @nma:module attribute with the value of ARGUMENT. In addition, a the @nma:module attribute with the value of ARGUMENT. In addition, a
<dc:source> element SHOULD be created as a child of this <rng: <dc:source> element SHOULD be created as a child of this <rng:
grammar> element and contain ARGUMENT as a metadata reference to the grammar> element and contain ARGUMENT as a metadata reference to the
input YANG module. See also Section 10.49. input YANG module. See also Section 10.49.
Substatements of the 'module' statement MUST be mapped so that Substatements of the 'module' statement MUST be mapped so that:
o statements representing configuration/state data are mapped to o statements representing configuration/state data are mapped to
descendants of the <nma:data> element; descendants of the <nma:data> element;
o statements representing the contents of RPC requests or replies o statements representing the contents of RPC requests or replies
are mapped to descendants of the <nma:rpcs> element; are mapped to descendants of the <nma:rpcs> element;
o statements representing the contents of event notifications are o statements representing the contents of event notifications are
mapped to descendants of the <nma:notifications> element. mapped to descendants of the <nma:notifications> element.
10.35. The 'must' Statement 10.35. The 'must' Statement
This statement is mapped to the <nma:must> element. It has one This statement is mapped to the <nma:must> element. It has one
mandatory attribute @assert (with no namespace) which contains mandatory attribute @assert (with no namespace) that contains
ARGUMENT transformed into a valid XPath expression (see Section 9.3). ARGUMENT transformed into a valid XPath expression (see Section 9.3).
The <nma:must> element may have other subelements resulting from The <nma:must> element may have other subelements resulting from
mapping the 'error-app-tag' and 'error-message' substatements. Other mapping the 'error-app-tag' and 'error-message' substatements. Other
substatements of 'must', i.e., 'description' and 'reference', are substatements of 'must', i.e., 'description' and 'reference', are
ignored. ignored.
EXAMPLE. YANG statement in the "dhcp" module EXAMPLE. YANG statement in the "dhcp" module
must 'current() <= ../max-lease-time' { must 'current() <= ../max-lease-time' {
error-message error-message
"The default-lease-time must be less than max-lease-time"; "The default-lease-time must be less than max-lease-time";
} }
is mapped to:
is mapped to
<nma:must assert="current()&lt;=../dhcp:max-lease-time"> <nma:must assert="current()&lt;=../dhcp:max-lease-time">
<nma:error-message> <nma:error-message>
The default-lease-time must be less than max-lease-time The default-lease-time must be less than max-lease-time
</nma:error-message> </nma:error-message>
</nma:must> </nma:must>
10.36. The 'namespace' Statement 10.36. The 'namespace' Statement
This statement is mapped simultaneously in two ways: This statement is mapped simultaneously in two ways:
1. To the @xmlns:PREFIX attribute of the root <rng:grammar> element 1. to the @xmlns:PREFIX attribute of the root <rng:grammar> element
where PREFIX is the namespace prefix specified by the sibling where PREFIX is the namespace prefix specified by the sibling
'prefix' statement. ARGUMENT becomes the value of this 'prefix' statement. ARGUMENT becomes the value of this
attribute. attribute;
2. To the @ns attribute of PARENT, which is an embedded <rng: 2. to the @ns attribute of PARENT, which is an embedded <rng:
grammar> pattern. ARGUMENT becomes the value of this attribute. grammar> pattern. ARGUMENT becomes the value of this attribute.
10.37. The 'notification' Statement 10.37. The 'notification' Statement
This statement is mapped to the following subtree of the <nma: This statement is mapped to the following subtree of the <nma:
notifications> element in the hybrid schema (where PREFIX is the notifications> element in the hybrid schema (where PREFIX is the
prefix of the local YANG module): prefix of the local YANG module):
<nma:notification> <nma:notification>
<rng:element name="PREFIX:ARGUMENT"> <rng:element name="PREFIX:ARGUMENT">
skipping to change at page 56, line 32 skipping to change at page 52, line 50
The <nma:rpc> element is a child of <nma:rpcs>. The <nma:rpc> element is a child of <nma:rpcs>.
10.51. The 'status' Statement 10.51. The 'status' Statement
This statement MAY be ignored. Otherwise, it is mapped to @nma: This statement MAY be ignored. Otherwise, it is mapped to @nma:
status attribute and ARGUMENT becomes its value. status attribute and ARGUMENT becomes its value.
10.52. The 'submodule' Statement 10.52. The 'submodule' Statement
This statement is not specifically mapped. Its substatements are This statement is not specifically mapped. Its substatements are
mapped as if they appeared directly in the module the submodule mapped as if they appeared directly in the module to which the
belongs to. submodule belongs.
10.53. The 'type' Statement 10.53. The 'type' Statement
Most YANG built-in datatypes have an equivalent in the XSD datatype Most YANG built-in data types have an equivalent in the XSD data type
library [XSD-D] as shown in Table 4. library [XSD-D] as shown in Table 4.
+-----------+---------------+--------------------------------+ +-----------+---------------+--------------------------------+
| YANG type | XSD type | Meaning | | YANG type | XSD type | Meaning |
+-----------+---------------+--------------------------------+ +-----------+---------------+--------------------------------+
| int8 | byte | 8-bit integer value | | int8 | byte | 8-bit integer value |
| | | | | | | |
| int16 | short | 16-bit integer value | | int16 | short | 16-bit integer value |
| | | | | | | |
| int32 | int | 32-bit integer value | | int32 | int | 32-bit integer value |
skipping to change at page 57, line 29 skipping to change at page 53, line 34
| | | | | | | |
| uint32 | unsignedInt | 32-bit unsigned integer value | | uint32 | unsignedInt | 32-bit unsigned integer value |
| | | | | | | |
| uint64 | unsignedLong | 64-bit unsigned integer value | | uint64 | unsignedLong | 64-bit unsigned integer value |
| | | | | | | |
| string | string | character string | | string | string | character string |
| | | | | | | |
| binary | base64Binary | binary data in base64 encoding | | binary | base64Binary | binary data in base64 encoding |
+-----------+---------------+--------------------------------+ +-----------+---------------+--------------------------------+
Table 4: YANG built-in datatypes with equivalents in the W3C XML Table 4: YANG built-in data types with equivalents in the W3C XML
Schema Type Library Schema Type Library
Two important datatypes of the XSD datatype library - "dateTime" and Two important data types of the XSD data type library -- "dateTime"
"anyURI" - are not built-in types in YANG but instead are defined as and "anyURI" -- are not built-in types in YANG but instead are
derived types in the standard modules [RFC6021]: "date-and-time" in defined as derived types in the standard modules [RFC6021]: "date-
the "ietf-yang-types" module and "uri" in the "ietf-inet-types" and-time" in the "ietf-yang-types" module and "uri" in the "ietf-
module. However, the formal restrictions in the YANG type inet-types" module. However, the formal restrictions in the YANG
definitions are rather weak. Therefore, implementations of the YANG- type definitions are rather weak. Therefore, implementations of the
to-DSDL mapping SHOULD detect these derived types in source YANG YANG-to-DSDL mapping SHOULD detect these derived types in source YANG
modules and map them to "dateType" and "anyURI", respectively. modules and map them to "dateType" and "anyURI", respectively.
Details about the mapping of individual YANG built-in types are given Details about the mapping of individual YANG built-in types are given
in the following subsections. in the following subsections.
10.53.1. The "empty" Type 10.53.1. The "empty" Type
This type is mapped to <rng:empty/>. This type is mapped to <rng:empty/>.
10.53.2. The "boolean" Type 10.53.2. The "boolean" Type
skipping to change at page 58, line 17 skipping to change at page 54, line 26
<rng:value>false</rng:value> <rng:value>false</rng:value>
</rng:choice> </rng:choice>
Note that the XSD "boolean" type cannot be used here because it Note that the XSD "boolean" type cannot be used here because it
allows, unlike YANG, an alternative numeric representation of boolean allows, unlike YANG, an alternative numeric representation of boolean
values: 0 for "false" and 1 for "true". values: 0 for "false" and 1 for "true".
10.53.3. The "binary" Type 10.53.3. The "binary" Type
This built-in type does not allow any restrictions and is mapped This built-in type does not allow any restrictions and is mapped
simply by inserting <rng:data> element whose @type attribute value is simply by inserting an <rng:data> element whose @type attribute value
set to "base64Binary" (see also Table 4). is set to "base64Binary" (see also Table 4).
10.53.4. The "bits" Type 10.53.4. The "bits" Type
This type is mapped to <rng:list> and for each 'bit' substatement the This type is mapped to the <rng:list> and for each 'bit' substatement
following XML fragment is inserted as a child of <rng:list>: the following XML fragment is inserted as a child of <rng:list>:
<rng:optional> <rng:optional>
<rng:value>bit_name</rng:value> <rng:value>bit_name</rng:value>
</rng:optional> </rng:optional>
where bit_name is the name of the bit as found in the argument of a where bit_name is the name of the bit as found in the argument of a
'bit' substatement. 'bit' substatement.
10.53.5. The "enumeration" and "union" Types 10.53.5. The "enumeration" and "union" Types
skipping to change at page 59, line 34 skipping to change at page 55, line 44
referred leaf defines a default value, this default value MUST be referred leaf defines a default value, this default value MUST be
ignored by the mapping. ignored by the mapping.
In addition, @nma:leafref attribute MUST be added to PARENT. The In addition, @nma:leafref attribute MUST be added to PARENT. The
argument of the 'path' substatement, translated according to argument of the 'path' substatement, translated according to
Section 9.3, is set as the value of this attribute. Section 9.3, is set as the value of this attribute.
10.53.9. The Numeric Types 10.53.9. The Numeric Types
YANG built-in numeric types are "int8", "int16", "int32", "int64", YANG built-in numeric types are "int8", "int16", "int32", "int64",
"uint8", "uint16", "uint32", "uint64" and "decimal64". They are "uint8", "uint16", "uint32", "uint64", and "decimal64". They are
mapped to <rng:data> element with @type attribute set to ARGUMENT mapped to the <rng:data> element with the @type attribute set to
translated according to Table 4 above. ARGUMENT translated according to Table 4 above.
An exception is the "decimal64" type, which is mapped to the An exception is the "decimal64" type, which is mapped to the
"decimal" type of the XSD datatype library. Its precision and number "decimal" type of the XSD data type library. Its precision and
of fractional digits are controlled with the following facets, which number of fractional digits are controlled with the following facets,
MUST always be present: which MUST always be present:
o "totalDigits" facet set to the value of 19. o "totalDigits" facet set to the value of 19.
o "fractionDigits" facet set to the argument of the 'fraction- o "fractionDigits" facet set to the argument of the 'fraction-
digits' substatement. digits' substatement.
The fixed value of "totalDigits" corresponds to the maximum of 19 The fixed value of "totalDigits" corresponds to the maximum of 19
decimal digits for 64-bit integers. decimal digits for 64-bit integers.
For example, the statement For example, the statement:
type decimal64 { type decimal64 {
fraction-digits 2; fraction-digits 2;
} }
is mapped to the following RELAX NG datatype: is mapped to the following RELAX NG data type:
<rng:data type="decimal"> <rng:data type="decimal">
<rng:param name="totalDigits">19</rng:param> <rng:param name="totalDigits">19</rng:param>
<rng:param name="fractionDigits">2</rng:param> <rng:param name="fractionDigits">2</rng:param>
</rng:data> </rng:data>
All numeric types support the 'range' restriction, which is mapped as All numeric types support the 'range' restriction, which is mapped as
follows: follows:
If the range expression consists of just a single range LO..HI, then If the range expression consists of just a single range LO..HI, then
it is mapped to a pair of datatype facets it is mapped to a pair of data type facets:
<rng:param name="minInclusive">LO</rng:param> <rng:param name="minInclusive">LO</rng:param>
and and
<rng:param name="maxInclusive">HI</rng:param> <rng:param name="maxInclusive">HI</rng:param>
If the range consists of a single number, the values of both facets 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 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", "minInclusive" facet is omitted. If HI is equal to the string "max",
skipping to change at page 61, line 23 skipping to change at page 57, line 31
</rng:data> </rng:data>
<rng:data type="int"> <rng:data type="int">
<rng:param name="minInclusive">100</rng:param> <rng:param name="minInclusive">100</rng:param>
</rng:data> </rng:data>
</rng:choice> </rng:choice>
See Section 9.2.2 for further details on mapping the restrictions. See Section 9.2.2 for further details on mapping the restrictions.
10.53.10. The "string" Type 10.53.10. The "string" Type
This type is mapped to <rng:data> element with the @type attribute This type is mapped to the <rng:data> element with the @type
set to "string". attribute set to "string".
The 'length' restriction is handled analogically to the 'range' The 'length' restriction is handled analogically to the 'range'
restriction for the numeric types (Section 10.53.9): restriction for the numeric types (Section 10.53.9):
If the length expression has just a single range, then If the length expression has just a single range:
o if the length range consists of a single number LENGTH, the o and if the length range consists of a single number LENGTH, the
following datatype facet is inserted: following data type facet is inserted:
<rng:param name="length">LENGTH</rng:param>. <rng:param name="length">LENGTH</rng:param>.
o Otherwise the length range is of the form LO..HI, i.e., it o if the length range is of the form LO..HI, i.e., it consists of
consists of both the lower and upper bound. The following two both the lower and upper bound. The following two data type
datatype facets are then inserted: facets are then inserted:
<rng:param name="minLength">LO</rng:param> <rng:param name="minLength">LO</rng:param>
and and
<rng:param name="maxLength">HI</rng:param> <rng:param name="maxLength">HI</rng:param>
If LO is equal to the string "min", the "minLength" facet is If LO is equal to the string "min", the "minLength" facet is omitted.
omitted. If HI is equal to the string "max", the "maxLength" If HI is equal to the string "max", the "maxLength" facet is omitted.
facet is omitted.
If the length expression has of multiple parts separated by "|", then If the length expression has of multiple parts separated by "|", then
the parent <rng:data> element must be repeated once for every range the parent <rng:data> element must be repeated once for every range
part and all such <rng:data> elements are wrapped in <rng:choice> part and all such <rng:data> elements are wrapped in <rng:choice>
element. Each <rng:data> element contains the "length" or element. Each <rng:data> element contains the "length" or
"minLength" and "maxLength" facets for one part of the length "minLength" and "maxLength" facets for one part of the length
expression as described in the previous paragraph. expression as described in the previous paragraph.
Every 'pattern' restriction of the "string" datatype is mapped to the Every 'pattern' restriction of the "string" data type is mapped to
"pattern" facet the "pattern" facet:
<rng:param name="pattern">...</rng:param> <rng:param name="pattern">...</rng:param>
with text equal to the argument of the 'pattern' statement. All such with text equal to the argument of the 'pattern' statement. All such
"pattern" facets must be repeated inside each copy of the <rng:data> "pattern" facets must be repeated inside each copy of the <rng:data>
element, i.e., once for each length range. element, i.e., once for each length range.
For example, For example,
type string { type string {
skipping to change at page 63, line 10 skipping to change at page 59, line 19
be found and its mapping installed as a subelement of either the be found and its mapping installed as a subelement of either the
root or an embedded <rng:grammar> element, see Section 10.54. 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 Even if a given derived type is used more than once in the input
YANG modules, the mapping of the corresponding 'typedef' MUST be YANG modules, the mapping of the corresponding 'typedef' MUST be
installed only once. installed only once.
2. If any restrictions are present, the ancestor built-in type for 2. If any restrictions are present, the ancestor built-in type for
the given derived type must be determined and the mapping of this the given derived type must be determined and the mapping of this
base type MUST be used. Restrictions appearing at all stages of base type MUST be used. Restrictions appearing at all stages of
the type derivation chain MUST be taken into account and their the type derivation chain MUST be taken into account and their
conjunction added to the <rng:data> element which defines the conjunction added to the <rng:data> element that defines the
basic type. basic type.
See Section 9.2.2 for more details and an example. See Section 9.2.2 for more details and an example.
10.54. The 'typedef' Statement 10.54. The 'typedef' Statement
This statement is mapped to a RELAX NG named pattern definition <rng: This statement is mapped to a RELAX NG named pattern definition <rng:
define>, but only if the type defined by this statement is used define>, but only if the type defined by this statement is used
without restrictions in at least one of the input modules. In this without restrictions in at least one of the input modules. In this
case, the named pattern definition becomes a child of either the root case, the named pattern definition becomes a child of either the root
or an embedded <rng:grammar> element, depending on whether the or an embedded <rng:grammar> element, depending on whether or not the
'typedef' statement appears at the top level of a YANG module or not. 'typedef' statement appears at the top level of a YANG module. The
The name of this named pattern definition is set to ARGUMENT mangled name of this named pattern definition is set to ARGUMENT mangled
according to the rules specified in Section 9.2. according to the rules specified in Section 9.2.
Whenever a derived type is used with additional restrictions, the Whenever a derived type is used with additional restrictions, the
ancestor built-in type for the derived type is used instead with ancestor built-in type for the derived type is used instead with
restrictions (facets) that are a combination of all restrictions restrictions (facets) that are a combination of all restrictions
specified along the type derivation chain. See Section 10.53.11 for specified along the type derivation chain. See Section 10.53.11 for
further details and an example. further details and an example.
An implementation MAY offer the option of recording all 'typedef' An implementation MAY offer the option of recording all 'typedef'
statements as named patterns in the output RELAX NG schema even if statements as named patterns in the output RELAX NG schema even if
they are not referenced. This is useful for mapping YANG "library" they are not referenced. This is useful for mapping YANG "library"
modules containing only 'typedef' and/or 'grouping' statements. modules containing only 'typedef' and/or 'grouping' statements.
10.55. The 'unique' Statement 10.55. The 'unique' Statement
This statement is mapped to @nma:unique attribute. ARGUMENT MUST be This statement is mapped to the @nma:unique attribute. ARGUMENT MUST
translated so that every node identifier in each of its components is be translated so that every node identifier in each of its components
prefixed with the namespace prefix of the local module, unless the is prefixed with the namespace prefix of the local module, unless the
prefix is already present. The result of this translation then prefix is already present. The result of this translation then
becomes the value of the @nma:unique attribute. becomes the value of the @nma:unique attribute.
For example, assuming that the local module prefix is "ex", For example, assuming that the local module prefix is "ex",
unique "foo ex:bar/baz" unique "foo ex:bar/baz"
is mapped to the following attribute/value pair: is mapped to the following attribute/value pair:
nma:unique="ex:foo ex:bar/ex:baz" nma:unique="ex:foo ex:bar/ex:baz"
10.56. The 'units' Statement 10.56. The 'units' Statement
This statement is mapped to @nma:units attribute and ARGUMENT becomes This statement is mapped to the @nma:units attribute and ARGUMENT
its value. becomes its value.
10.57. The 'uses' Statement 10.57. The 'uses' Statement
If this statement has neither 'refine' nor 'augment' substatements, If this statement has neither 'refine' nor 'augment' substatements,
it is mapped to <rng:ref> element, i.e., a reference to a named 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 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 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, referenced named pattern has not been added to the hybrid schema yet,
the corresponding grouping MUST be found and its mapping installed as the corresponding grouping MUST be found and its mapping installed as
a subelement of <rng:grammar>, see Section 10.20. a subelement of <rng:grammar>, see Section 10.20.
Otherwise, if the 'uses' statement has any 'refine' or 'augment' Otherwise, if the 'uses' statement has any 'refine' or 'augment'
substatements, the corresponding grouping must be looked up and its substatements, the corresponding grouping must be looked up and its
contents inserted under PARENT. See Section 9.2.1 for further contents inserted under PARENT. See Section 9.2.1 for further
details and an example. details and an example.
10.58. The 'value' Statement 10.58. The 'value' Statement
This statement is ignored. This statement is ignored.
10.59. The 'when' Statement 10.59. The 'when' Statement
This statement is mapped to @nma:when attribute and ARGUMENT, This statement is mapped to the @nma:when attribute and ARGUMENT,
translated according to Section 9.3, becomes it value. translated according to Section 9.3, becomes it value.
10.60. The 'yang-version' Statement 10.60. The 'yang-version' Statement
This statement is not mapped to the output schema. However, an This statement is not mapped to the output schema. However, an
implementation SHOULD check that it is compatible with the YANG implementation SHOULD check that it is compatible with the YANG
version declared by the statement (currently version 1). In the case version declared by the statement (currently version 1). In the case
of a mismatch, the implementation SHOULD report an error and of a mismatch, the implementation SHOULD report an error and
terminate. terminate.
skipping to change at page 65, line 49 skipping to change at page 62, line 6
specific annotations. specific annotations.
11.1. Generating RELAX NG Schemas for Various Document Types 11.1. Generating RELAX NG Schemas for Various Document Types
With one minor exception, obtaining a validating RELAX NG schema from With one minor exception, obtaining a validating RELAX NG schema from
the hybrid schema only means taking appropriate parts of the hybrid the hybrid schema only means taking appropriate parts of the hybrid
schema and assembling them in a new RELAX NG grammar, perhaps after schema and assembling them in a new RELAX NG grammar, perhaps after
removing all unwanted annotations. removing all unwanted annotations.
The structure of the resulting RELAX NG schema is similar to that of The structure of the resulting RELAX NG schema is similar to that of
the hybrid schema: The root grammar contains embedded grammars, one the hybrid schema: the root grammar contains embedded grammars, one
for each input YANG module. However, as explained in Section 8.2, for each input YANG module. However, as explained in Section 8.2,
global named pattern definitions (children of the root <rng:grammar> global named pattern definitions (children of the root <rng:grammar>
element) MUST be moved to a separate schema file. element) MUST be moved to a separate schema file.
Depending on the XML document type that is the target for validation, Depending on the XML document type that is the target for validation,
such as <nc:get>/<nc:get-config> reply, RPC operations or such as <nc:get> or <nc:get-config> reply, RPC operations or
notifications, patterns defining corresponding top-level information notifications, patterns defining corresponding top-level information
items MUST be added, such as <nc:rpc-reply> with the @message-id items MUST be added, such as <nc:rpc-reply> with the @message-id
attribute and so on. attribute and so on.
In order to avoid copying common named pattern definitions for common In order to avoid copying common named pattern definitions for common
NETCONF elements and attributes to every single output RELAX NG file, NETCONF elements and attributes to every single output RELAX NG file,
such schema-independent definitions SHOULD be collected in a library such schema-independent definitions SHOULD be collected in a library
file which is then included by the validating RELAX NG schemas. file that is then included by the validating RELAX NG schemas.
Appendix B has the listing of such a library file. Appendix B has the listing of such a library file.
The minor exception mentioned above is the annotation @nma:config, The minor exception mentioned above is the annotation @nma:config,
which must be observed if the target document type is a reply to <nc: 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 get-config>. In this case, each element definition that has this
attribute with the value of "false" MUST be removed from the schema attribute with the value of "false" MUST be removed from the schema
together with its descendants. See Section 12.1 for more details. together with its descendants. See Section 12.1 for more details.
11.2. Mapping Semantic Constraints to Schematron 11.2. Mapping Semantic Constraints to Schematron
Schematron schemas tend to be much flatter and more uniform compared Schematron schemas tend to be much flatter and more uniform compared
to RELAX NG. They have exactly four levels of XML hierarchy: <sch: to RELAX NG. They have exactly four levels of XML hierarchy: <sch:
schema>, <sch:pattern>, <sch:rule> and <sch:assert> or <sch:report>. schema>, <sch:pattern>, <sch:rule>, and <sch:assert> or <sch:report>.
In a Schematron schema generated by the second mapping step, the In a Schematron schema generated by the second mapping step, the
basic unit of organization is a rule represented by the <sch:rule> basic unit of organization is a rule represented by the <sch:rule>
element. The following NETMOD-specific annotations from the hybrid element. The following NETMOD-specific annotations from the hybrid
schema (henceforth called "semantic annotations") are mapped to schema (henceforth called "semantic annotations") are mapped to
corresponding Schematron rules: <nma:must>, @nma:key, @nma:unique, corresponding Schematron rules: <nma:must>, @nma:key, @nma:unique,
@nma:max-elements, @nma:min-elements, @nma:when, @nma:leafref, @nma: @nma:max-elements, @nma:min-elements, @nma:when, @nma:leafref, @nma:
leaf-list, and also @nma:mandatory appearing as an attribute of <rng: leaf-list, and also @nma:mandatory appearing as an attribute of <rng:
choice> (see Section 11.2.1). choice> (see Section 11.2.1).
skipping to change at page 67, line 11 skipping to change at page 63, line 16
the data tree. The <sch:rule> element contains the mappings of all the data tree. The <sch:rule> element contains the mappings of all
contained semantic annotations in the form of Schematron asserts or contained semantic annotations in the form of Schematron asserts or
reports. reports.
Semantic annotations appearing inside a named pattern definition Semantic annotations appearing inside a named pattern definition
(i.e., having <rng:define> among its ancestors) require special (i.e., having <rng:define> among its ancestors) require special
treatment because they may be potentially used in different contexts. treatment because they may be potentially used in different contexts.
This is accomplished by using Schematron abstract patterns that use This is accomplished by using Schematron abstract patterns that use
the "$pref" variable in place of the local namespace prefix. The 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 value of the @id attribute of such an abstract pattern MUST be set to
the name of the named pattern definition which is being mapped (i.e., the name of the named pattern definition that is being mapped (i.e.,
the mangled name of the original YANG grouping). the mangled name of the original YANG grouping).
When the abstract pattern is instantiated, the values of the When the abstract pattern is instantiated, the values of the
following two parameters MUST be provided: following two parameters MUST be provided:
o pref: the actual namespace prefix, o pref: the actual namespace prefix,
o start: XPath expression defining the context in which the grouping o start: XPath expression defining the context in which the grouping
is used. is used.
skipping to change at page 68, line 34 skipping to change at page 64, line 36
<sch:pattern id="id2573371" is-a="_example4__sorted-leaf-list"> <sch:pattern id="id2573371" is-a="_example4__sorted-leaf-list">
<sch:param name="start" value="/nc:rpc-reply/nc:data"/> <sch:param name="start" value="/nc:rpc-reply/nc:data"/>
<sch:param name="pref" value="ex4"/> <sch:param name="pref" value="ex4"/>
</sch:pattern> </sch:pattern>
</sch:schema> </sch:schema>
The "sorted-leaf-list" grouping from the input module is mapped to an The "sorted-leaf-list" grouping from the input module is mapped to an
abstract pattern with an @id value of "_example4__sorted-leaf-list" abstract pattern with an @id value of "_example4__sorted-leaf-list"
in which the 'must' statement corresponds to the <sch:assert> in which the 'must' statement corresponds to the <sch:assert>
element. The abstract pattern is the instantiated by the pattern element. The abstract pattern is the instantiated by the pattern
with an @id value of "id2802112" which sets the "start" and "pref" with an @id value of "id2573371", which sets the "start" and "pref"
parameters to appropriate values. parameters to appropriate values.
Note that another Schematron element, <sch:report>, was automatically Note that another Schematron element, <sch:report>, was automatically
added, checking for duplicate leaf-list entries. added, checking for duplicate leaf-list entries.
The mapping from the hybrid schema to Schematron proceeds in the The mapping from the hybrid schema to Schematron proceeds in the
following steps: following steps:
1. First, the active subtree(s) of the hybrid schema must be 1. First, the active subtree(s) of the hybrid schema must be
selected depending on the requested target document type. This selected depending on the requested target document type. This
procedure is identical to the RELAX NG case, including the procedure is identical to the RELAX NG case, including the
handling of @nma:config if the target document type is <nc:get- handling of @nma:config if the target document type is <nc:get-
config> reply. config> reply.
2. Namespaces of all input YANG modules, together with the 2. Namespaces of all input YANG modules, together with the
namespaces of base NETCONF ("nc" prefix) or notifications ("en" namespaces of base NETCONF ("nc" prefix) or notifications ("en"
prefix) MUST be declared using the <sch:ns> element, for example prefix) MUST be declared using the <sch:ns> element, for example:
<sch:ns uri="http://example.com/ns/example4" prefix="ex4"/> <sch:ns uri="http://example.com/ns/example4" prefix="ex4"/>
3. One pattern is created for every input module. In addition, an 3. One pattern is created for every input module. In addition, an
abstract pattern is created for every named pattern definition abstract pattern is created for every named pattern definition
containing one or more semantic annotations. containing one or more semantic annotations.
4. A <sch:rule> element is created for each element pattern 4. A <sch:rule> element is created for each element pattern
containing semantic annotations. containing semantic annotations.
5. Every such annotation is then mapped to an <sch:assert> or <sch: 5. Every such annotation is then mapped to an <sch:assert> or <sch:
report> element which is installed as a child of the <sch:rule> report> element, which is installed as a child of the <sch:rule>
element. element.
11.2.1. Constraints on Mandatory Choice 11.2.1. Constraints on Mandatory Choice
In order to fully represent the semantics of YANG's 'choice' In order to fully represent the semantics of YANG's 'choice'
statement with the "mandatory true;" substatement, the RELAX NG statement with the "mandatory true;" substatement, the RELAX NG
grammar has to be combined with a special Schematron rule. grammar has to be combined with a special Schematron rule.
EXAMPLE. Consider the following module: EXAMPLE. Consider the following module:
skipping to change at page 70, line 33 skipping to change at page 66, line 38
In the second case branch, the "ex5:bar" element is defined as In the second case branch, the "ex5:bar" element is defined as
mandatory so that this element must be present in a valid mandatory so that this element must be present in a valid
configuration if this branch is selected. However, the two elements configuration if this branch is selected. However, the two elements
in the first branch "foo" cannot be both declared as mandatory since in the first branch "foo" cannot be both declared as mandatory since
each of them alone suffices for a valid configuration. As a result, each of them alone suffices for a valid configuration. As a result,
the above RELAX NG fragment would successfully validate the above RELAX NG fragment would successfully validate
configurations where none of the three leaf elements are present. configurations where none of the three leaf elements are present.
Therefore, mandatory choices, which can be recognized in the hybrid Therefore, mandatory choices, which can be recognized in the hybrid
schema as <rng:choice> elements with the @nma:mandatory annotation, schema as <rng:choice> elements with the @nma:mandatory annotation,
have to be handled in a special way: For each mandatory choice where 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 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 rule MUST be added enforcing the presence of at least one element
from any of the cases. (RELAX NG schema guarantees that elements from any of the cases. (RELAX NG schema guarantees that elements
from different cases cannot be mixed together, that all mandatory from different cases cannot be mixed together, that all mandatory
nodes are present etc.). nodes are present, etc.).
For the example module above, the Schematron rule will be as follows: For the example module above, the Schematron rule will be as follows:
<sch:rule context="/nc:rpc-reply/nc:data"> <sch:rule context="/nc:rpc-reply/nc:data">
<sch:assert test="ex5:foo1 or ex5:foo2 or ex5:bar"> <sch:assert test="ex5:foo1 or ex5:foo2 or ex5:bar">
Node(s) from at least one case of choice "foobar" must exist. Node(s) from at least one case of choice "foobar" must exist.
</sch:assert> </sch:assert>
</sch:rule> </sch:rule>
11.3. Mapping Default Values to DSRL 11.3. Mapping Default Values to DSRL
DSRL is the only component of DSDL which is allowed to change the DSRL is the only component of DSDL that is allowed to change the
information set of the validated XML document. While DSRL also has information set of the validated XML document. While DSRL also has
other functions, YANG-to-DSDL mapping uses it only for specifying and other functions, YANG-to-DSDL mapping uses it only for specifying and
applying default contents. For XML instance documents based on YANG applying default contents. For XML instance documents based on YANG
data models, insertion of default contents may potentially take place data models, insertion of default contents may potentially take place
for all implicit nodes identified by the rules in Section 9.1.2. 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 In DSRL, the default contents of an element are specified using the
<dsrl:default-content> element, which is a child of <dsrl:element- <dsrl:default-content> element, which is a child of <dsrl:element-
map>. Two sibling elements of <dsrl:default-content> determine the map>. Two sibling elements of <dsrl:default-content> determine the
context for the application of the default contents, see [DSRL]: context for the application of the default contents, see [DSRL]:
o <dsrl:parent> element contains an XSLT pattern specifying the o the <dsrl:parent> element contains an XSLT pattern specifying the
parent element; the default contents are applied only if the parent element; the default contents are applied only if the
parent element exists in the instance document. parent element exists in the instance document;
o <dsrl:name> contains the XML name of the element which, if missing o the <dsrl:name> contains the XML name of the element that, if
or empty, is inserted together with the contents of <dsrl:default- missing or empty, is inserted together with the contents of <dsrl:
content>. default-content>.
The <dsrl:parent> element is optional in a general DSRL schema but, 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 for the purpose of the YANG-to-DSDL mapping, this element MUST be
always present, in order to guarantee a proper application of default always present, in order to guarantee a proper application of default
contents. contents.
DSRL mapping only deals with <rng:element> patterns in the hybrid DSRL mapping only deals with <rng:element> patterns in the hybrid
schema that define implicit nodes (see Section 9.1.2). Such element schema that define implicit nodes (see Section 9.1.2). Such element
patterns are distinguished by having NETMOD-specific annotation patterns are distinguished by having NETMOD-specific annotation
attributes @nma:default or @nma:implicit, i.e., either attributes @nma:default or @nma:implicit, i.e., either:
<rng:element name="ELEM" nma:default="DEFVALUE"> <rng:element name="ELEM" nma:default="DEFVALUE">
... ...
</rng:element> </rng:element>
or or
<rng:element name="ELEM" nma:implicit="true"> <rng:element name="ELEM" nma:implicit="true">
... ...
</rng:element> </rng:element>
skipping to change at page 72, line 27 skipping to change at page 68, line 33
above as DEFVALUE). above as DEFVALUE).
o If the implicit node ELEM is a leaf and has the @nma:implicit 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 attribute with the value of "true", the default value has to be
determined from the @nma:default attribute of the definition of determined from the @nma:default attribute of the definition of
ELEM's type (perhaps recursively) and used in place of DEFCONT in ELEM's type (perhaps recursively) and used in place of DEFCONT in
the above DSRL element map. See also Section 9.2.2. the above DSRL element map. See also Section 9.2.2.
o Otherwise, the implicit node ELEM is a container and DEFCONT is o Otherwise, the implicit node ELEM is a container and DEFCONT is
constructed as an XML fragment containing all descendant elements constructed as an XML fragment containing all descendant elements
of ELEM that have either @nma:implicit or @nma:default attribute. 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 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 guaranteed that the default contents are not applied if any node from
any non-default case is present. This is accomplished by setting any non-default case is present. This is accomplished by setting
<dsrl:parent> in a special way: <dsrl:parent> in a special way:
<dsrl:parent>XPARENT[not (ELEM1|ELEM2|...|ELEMn)]</dsrl:parent> <dsrl:parent>XPARENT[not (ELEM1|ELEM2|...|ELEMn)]</dsrl:parent>
where ELEM1, ELEM2, ... ELEMn are the names of all top-level nodes 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 from all non-default cases. The rest of the element map is exactly
skipping to change at page 75, line 5 skipping to change at page 71, line 5
</dsrl:parent> </dsrl:parent>
<dsrl:name>ex6:leaf2</dsrl:name> <dsrl:name>ex6:leaf2</dsrl:name>
<dsrl:default-content>2</dsrl:default-content> <dsrl:default-content>2</dsrl:default-content>
</dsrl:element-map> </dsrl:element-map>
</dsrl:maps> </dsrl:maps>
Note that the default value for "leaf3" defined in the YANG module is Note that the default value for "leaf3" defined in the YANG module is
ignored because "leaf3" represents a non-default alternative of a ignored because "leaf3" represents a non-default alternative of a
choice and as such never becomes an implicit element. choice and as such never becomes an implicit element.
12. Mapping NETMOD-specific Annotations to DSDL Schema Languages 12. Mapping NETMOD-Specific Annotations to DSDL Schema Languages
This section contains the mapping specification for the individual This section contains the mapping specification for the individual
NETMOD-specific annotations. In each case, the result of the mapping NETMOD-specific annotations. In each case, the result of the mapping
must be inserted into an appropriate context of the target DSDL must be inserted into an appropriate context of the target DSDL
schema as described in Section 11. The context is determined by the schema as described in Section 11. The context is determined by the
element pattern in the hybrid schema to which the annotation is element pattern in the hybrid schema to which the annotation is
attached. In the rest of this section, CONTELEM will denote the name attached. In the rest of this section, CONTELEM will denote the name
of this context element properly qualified with its namespace prefix. of this context element properly qualified with its namespace prefix.
12.1. The @nma:config Annotation 12.1. The @nma:config Annotation
skipping to change at page 76, line 13 skipping to change at page 72, line 13
all its descendants in the hybrid schema MUST be ignored. all its descendants in the hybrid schema MUST be ignored.
12.6. The @nma:implicit Annotation 12.6. The @nma:implicit Annotation
This annotation is used for generating the DSRL schema as described This annotation is used for generating the DSRL schema as described
in Section 11.3. in Section 11.3.
12.7. The <nma:instance-identifier> Annotation 12.7. The <nma:instance-identifier> Annotation
If this annotation element has the @require-instance attribute with If this annotation element has the @require-instance attribute with
the value of "false", it is ignored. Otherwise it is mapped to the the value of "false", it is ignored. Otherwise, it is mapped to the
following Schematron assert: following Schematron assert:
<sch:assert test="nmf:evaluate(.)"> <sch:assert test="nmf:evaluate(.)">
The element pointed to by "CONTELEM" must exist. The element pointed to by "CONTELEM" must exist.
</sch:assert> </sch:assert>
The nmf:evaluate() function is an XSLT extension function (see The nmf:evaluate() function is an XSLT extension function (see
Extension Functions in [XSLT]) that evaluates an XPath expression at Extension Functions in [XSLT]) that evaluates an XPath expression at
run time. Such an extension function is available in Extended XSLT run time. Such an extension function is available in Extended XSLT
(EXSLT) or provided as a proprietary extension by some XSLT (EXSLT) or provided as a proprietary extension by some XSLT
skipping to change at page 76, line 46 skipping to change at page 72, line 46
where CONDITION has this form: where CONDITION has this form:
preceding-sibling::CONTELEM[C_1 and C_2 and ... and C_n] 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 Each sub-expression C_i, for i=1,2,...,n, specifies the condition for
violated uniqueness of the key k_i, namely violated uniqueness of the key k_i, namely
k_i=current()/k_i k_i=current()/k_i
12.9. The @nma:leaf-list Annotation 12.9. The @nma:leaf-list Annotation
This annotation is mapped to the following Schematron rule which This annotation is mapped to the following Schematron rule, which
detects duplicate entries of a leaf-list: detects duplicate entries of a leaf-list:
<sch:report <sch:report
test=". = preceding-sibling::PREFIX:sorted-entry"> test=". = preceding-sibling::PREFIX:sorted-entry">
Duplicate leaf-list entry "<sch:value-of select="."/>". Duplicate leaf-list entry "<sch:value-of select="."/>".
</sch:report> </sch:report>
See Section 11.2 for a complete example. See Section 11.2 for a complete example.
12.10. The @nma:leafref Annotation 12.10. The @nma:leafref Annotation
skipping to change at page 77, line 49 skipping to change at page 73, line 49
12.13. The <nma:must> Annotation 12.13. The <nma:must> Annotation
This annotation is mapped to the following Schematron assert: This annotation is mapped to the following Schematron assert:
<sch:assert test="EXPRESSION"> <sch:assert test="EXPRESSION">
MESSAGE MESSAGE
</sch:assert> </sch:assert>
where EXPRESSION is the value of the mandatory @assert attribute of where EXPRESSION is the value of the mandatory @assert attribute of
<nma:must>. If the <nma:error-message> subelement exists, MESSAGE is <nma:must>. If the <nma:error-message> subelement exists, MESSAGE is
set to its contents, otherwise it is set to the default message set to its contents; otherwise, it is set to the default message
"Condition EXPRESSION must be true". "Condition EXPRESSION must be true".
12.14. The <nma:ordered-by> Annotation 12.14. The <nma:ordered-by> Annotation
This annotation currently has no mapping defined. This annotation currently has no mapping defined.
12.15. The <nma:status> Annotation 12.15. The <nma:status> Annotation
This annotation currently has no mapping defined. This annotation currently has no mapping defined.
skipping to change at page 80, line 12 skipping to change at page 75, line 33
XML: N/A, the requested URI is an XML namespace. XML: N/A, the requested URI is an XML namespace.
----------------------------------------------------- -----------------------------------------------------
14. Security Considerations 14. Security Considerations
This document defines a procedure that maps data models expressed in This document defines a procedure that maps data models expressed in
the YANG language to a coordinated set of DSDL schemas. The the YANG language to a coordinated set of DSDL schemas. The
procedure itself has no security impact on the Internet. procedure itself has no security impact on the Internet.
DSDL schemas obtained by the mapping procedure may be used for DSDL schemas obtained by the mapping procedure may be used for
validating the contents of NETCONF messages or entire datastores and validating the contents of NETCONF messages or entire datastores, and
thus provide additional validity checks above those performed by thus they provide additional validity checks above those performed by
NETCONF server and client implementations supporting YANG data NETCONF server and client implementations supporting YANG data
models. The strictness of this validation is directly derived from models. The strictness of this validation is directly derived from
the source YANG modules that the validated XML data adhere to. the source YANG modules that the validated XML data adhere to.
15. Contributors 15. Contributors
The following people contributed significantly to the initial version The following people contributed significantly to the initial version
of this document: of this document:
o Rohan Mahy o Rohan Mahy
o Sharon Chisholm (Ciena) o Sharon Chisholm (Ciena)
16. Acknowledgments 16. Acknowledgments
The editor wishes to thank the following individuals who provided The editor wishes to thank the following individuals who provided
helpful suggestions and/or comments on various versions of this helpful suggestions and/or comments on various versions of this
document: Andy Bierman, Martin Bjorklund, Jirka Kosek, Juergen document: Andy Bierman, Martin Bjorklund, Jirka Kosek, Juergen
Schoenwaelder and Phil Shafer. Schoenwaelder, and Phil Shafer.
17. References 17. References
17.1. Normative References 17.1. Normative References
[DSDL] ISO/IEC, "Document Schema Definition Languages (DSDL) - [DSDL] ISO/IEC, "Document Schema Definition Languages (DSDL)
Part 1: Overview", ISO/IEC 19757-1, November 2004. - Part 1: Overview", ISO/IEC 19757-1, November 2004.
[DSRL] ISO/IEC, "Information Technology - Document Schema [DSRL] ISO/IEC, "Information Technology - Document Schema
Definition Languages (DSDL) - Part 8: Document Semantics Definition Languages (DSDL) - Part 8: Document
Renaming Language - DSRL", ISO/IEC 19757-8:2008(E), Semantics Renaming Language - DSRL", ISO/
December 2008. IEC 19757-8:2008(E), December 2008.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81,
January 2004. RFC 3688, January 2004.
[RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741, [RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741,
December 2006. December 2006.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language
Network Configuration Protocol (NETCONF)", RFC 6020, for Network Configuration Protocol (NETCONF)",
September 2010. RFC 6020, October 2010.
[RFC6021] Schoenwaelder, J., Ed., "Common YANG Data Types", [RFC6021] Schoenwaelder, J., Ed., "Common YANG Data Types",
RFC 6021, September 2010. RFC 6021, October 2010.
[RNG] ISO/IEC, "Information Technology - Document Schema [RNG] ISO/IEC, "Information Technology - Document Schema
Definition Languages (DSDL) - Part 2: Regular-Grammar- Definition Languages (DSDL) - Part 2: Regular-Grammar-
Based Validation - RELAX NG. Second Edition.", ISO/ Based Validation - RELAX NG. Second Edition.", ISO/
IEC 19757-2:2008(E), December 2008. IEC 19757-2:2008(E), December 2008.
[RNG-CS] ISO/IEC, "Information Technology - Document Schema [RNG-CS] ISO/IEC, "Information Technology - Document Schema
Definition Languages (DSDL) - Part 2: Regular-Grammar- Definition Languages (DSDL) - Part 2: Regular-Grammar-
Based Validation - RELAX NG. AMENDMENT 1: Compact Syntax", Based Validation - RELAX NG. AMENDMENT 1: Compact
ISO/IEC 19757-2:2003/Amd. 1:2006(E), January 2006. Syntax", ISO/IEC 19757-2:2003/Amd. 1:2006(E),
January 2006.
[RNG-DTD] Clark, J., Ed. and M. Murata, Ed., "RELAX NG DTD [RNG-DTD] Clark, J., Ed. and M. Murata, Ed., "RELAX NG DTD
Compatibility", OASIS Committee Specification 3 December Compatibility", OASIS Committee Specification, 3
2001, December 2001. December 2001.
[Schematron] [Schematron] ISO/IEC, "Information Technology - Document Schema
ISO/IEC, "Information Technology - Document Schema Definition Languages (DSDL) - Part 3: Rule-Based
Definition Languages (DSDL) - Part 3: Rule-Based Validation - Schematron", ISO/IEC 19757-3:2006(E),
Validation - Schematron", ISO/IEC 19757-3:2006(E), June 2006.
June 2006.
[XML] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and [XML] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E.,
F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth and F. Yergeau, "Extensible Markup Language (XML) 1.0
Edition)", World Wide Web Consortium Recommendation REC- (Fifth Edition)", World Wide Web Consortium
xml-20081126, November 2008, Recommendation REC-xml-20081126, November 2008,
<http://www.w3.org/TR/2006/REC-xml-20060816>. <http://www.w3.org/TR/2006/REC-xml-20060816>.
[XML-INFOSET] [XML-INFOSET] Tobin, R. and J. Cowan, "XML Information Set (Second
Tobin, R. and J. Cowan, "XML Information Set (Second Edition)", World Wide Web Consortium
Edition)", World Wide Web Consortium Recommendation REC- Recommendation REC-xml-infoset-20040204,
xml-infoset-20040204, February 2004, February 2004,
<http://www.w3.org/TR/2004/REC-xml-infoset-20040204>. <http://www.w3.org/TR/2004/REC-xml-infoset-20040204>.
[XPath] Clark, J. and S. DeRose, "XML Path Language (XPath) [XPath] Clark, J. and S. DeRose, "XML Path Language (XPath)
Version 1.0", World Wide Web Consortium Version 1.0", World Wide Web Consortium
Recommendation REC-xpath-19991116, November 1999, Recommendation REC-xpath-19991116, November 1999,
<http://www.w3.org/TR/1999/REC-xpath-19991116>. <http://www.w3.org/TR/1999/REC-xpath-19991116>.
[XSD-D] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes [XSD-D] Biron, P. and A. Malhotra, "XML Schema Part 2:
Second Edition", World Wide Web Consortium Datatypes Second Edition", World Wide Web Consortium
Recommendation REC-xmlschema-2-20041028, October 2004, Recommendation REC-xmlschema-2-20041028, October 2004,
<http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>. <http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.
[XSLT] Clark, J., "XSL Transformations (XSLT) Version 1.0", World [XSLT] Clark, J., "XSL Transformations (XSLT) Version 1.0",
Wide Web Consortium Recommendation REC-xslt-19991116, World Wide Web Consortium Recommendation REC-xslt-
November 1999. 19991116, November 1999.
17.2. Informative References 17.2. Informative References
[DHCPtut] Bjorklund, M., "DHCP Tutorial", November 2007, <http:// [DHCPtut] Bjorklund, M., "DHCP Tutorial", November 2007, <http:/
www.yang-central.org/twiki/bin/view/Main/DhcpTutorial>. /www.yang-central.org/twiki/bin/view/Main/
DhcpTutorial>.
[RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin,
"Simple Network Management Protocol (SNMP)", STD 15, "Simple Network Management Protocol (SNMP)", RFC 1157,
RFC 1157, May 1990. May 1990.
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Structure of Management Information Schoenwaelder, Ed., "Structure of Management
Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. Information Version 2 (SMIv2)", STD 58, RFC 2578,
April 1999.
[RFC5013] Kunze, J., "The Dublin Core Metadata Element Set", [RFC5013] Kunze, J., "The Dublin Core Metadata Element Set",
RFC 5013, August 2007. RFC 5013, August 2007.
[RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event
Notifications", RFC 5277, July 2008. Notifications", RFC 5277, July 2008.
[Trang] Clark, J., "Trang: Multiformat schema converter based on [Trang] Clark, J., "Trang: Multiformat schema converter based
RELAX NG", 2008, on RELAX NG", 2008,
<http://www.thaiopensource.com/relaxng/trang.html>. <http://www.thaiopensource.com/relaxng/trang.html>.
[Vli04] van der Vlist, E., "RELAX NG", O'Reilly , 2004. [Vli04] van der Vlist, E., "RELAX NG", O'Reilly, 2004.
[XSD] Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, [XSD] Thompson, H., Beech, D., Maloney, M., and N.
"XML Schema Part 1: Structures Second Edition", World Wide Mendelsohn, "XML Schema Part 1: Structures Second
Web Consortium Recommendation REC-xmlschema-1-20041028, Edition", World Wide Web Consortium
October 2004, Recommendation REC-xmlschema-1-20041028, October 2004,
<http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>. <http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>.
[pyang] Bjorklund, M. and L. Lhotka, "pyang: An extensible YANG [pyang] Bjorklund, M. and L. Lhotka, "pyang: An extensible
validator and converter in Python", 2010, YANG validator and converter in Python", 2010,
<http://code.google.com/p/pyang/>. <http://code.google.com/p/pyang/>.
Appendix A. RELAX NG Schema for NETMOD-Specific Annotations Appendix A. RELAX NG Schema for NETMOD-Specific Annotations
This appendix defines the content model for all NETMOD-specific This appendix defines the content model for all NETMOD-specific
annotations in the form of RELAX NG named pattern definitions. annotations in the form of RELAX NG named pattern definitions.
<CODE BEGINS> file "nmannot.rng" <CODE BEGINS> file "nmannot.rng"
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<grammar xmlns="http://relaxng.org/ns/structure/1.0" <grammar xmlns="http://relaxng.org/ns/structure/1.0"
skipping to change at page 91, line 9 skipping to change at page 84, line 27
</define> </define>
</grammar> </grammar>
<CODE ENDS> <CODE ENDS>
Appendix B. Schema-Independent Library Appendix B. Schema-Independent Library
In order to avoid copying the common named pattern definitions to In order to avoid copying the common named pattern definitions to
every RELAX NG schema generated in the second mapping step, the every RELAX NG schema generated in the second mapping step, the
definitions are collected in a library file - schema-independent definitions are collected in a library file -- schema-independent
library - which is included by the validating schemas under the file library -- which is included by the validating schemas under the file
name "relaxng-lib.rng" (XML syntax) and "relaxng-lib.rnc" (compact name "relaxng-lib.rng" (XML syntax) and "relaxng-lib.rnc" (compact
syntax). The included definitions cover patterns for common elements syntax). The included definitions cover patterns for common elements
from base NETCONF [RFC4741] and event notifications [RFC5277]. from base NETCONF [RFC4741] and event notifications [RFC5277].
<CODE BEGINS> file "relaxng-lib.rng" <CODE BEGINS> file "relaxng-lib.rng"
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<grammar xmlns="http://relaxng.org/ns/structure/1.0" <grammar xmlns="http://relaxng.org/ns/structure/1.0"
xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"
skipping to change at page 92, line 18 skipping to change at page 85, line 32
applied to the "canonical" DHCP tutorial [DHCPtut] data model. The applied to the "canonical" DHCP tutorial [DHCPtut] data model. The
input YANG module is shown in Appendix C.1 and the output schemas in input YANG module is shown in Appendix C.1 and the output schemas in
the following two subsections. the following two subsections.
The hybrid schema was obtained by the "dsdl" plugin of the pyang tool The hybrid schema was obtained by the "dsdl" plugin of the pyang tool
[pyang] and the validating DSDL schemas were obtained by XSLT [pyang] and the validating DSDL schemas were obtained by XSLT
stylesheets that are also part of pyang distribution. stylesheets that are also part of pyang distribution.
Due to the limit of 72 characters per line, a few long strings Due to the limit of 72 characters per line, a few long strings
required manual editing, in particular the regular expression required manual editing, in particular the regular expression
patterns for IP addresses etc. These were replaced by the patterns for IP addresses, etc. These were replaced by the
placeholder string "... regex pattern ...". Also, line breaks were placeholder string "... regex pattern ...". Also, line breaks were
added to several documentation strings and Schematron messages. added to several documentation strings and Schematron messages.
Other than that, the results of the automatic translations were not Other than that, the results of the automatic translations were not
changed. changed.
C.1. Input YANG Module C.1. Input YANG Module
module dhcp { module dhcp {
namespace "http://example.com/ns/dhcp"; namespace "http://example.com/ns/dhcp";
prefix dhcp; prefix dhcp;
import ietf-yang-types { prefix yang; } import ietf-yang-types { prefix yang; }
skipping to change at page 107, line 5 skipping to change at page 100, line 13
<dsrl:element-map> <dsrl:element-map>
<dsrl:parent> <dsrl:parent>
/nc:rpc-reply/nc:data/dhcp:dhcp/dhcp:shared-networks/ /nc:rpc-reply/nc:data/dhcp:dhcp/dhcp:shared-networks/
dhcp:shared-network/dhcp:subnet dhcp:shared-network/dhcp:subnet
</dsrl:parent> </dsrl:parent>
<dsrl:name>dhcp:max-lease-time</dsrl:name> <dsrl:name>dhcp:max-lease-time</dsrl:name>
<dsrl:default-content>7200</dsrl:default-content> <dsrl:default-content>7200</dsrl:default-content>
</dsrl:element-map> </dsrl:element-map>
</dsrl:maps> </dsrl:maps>
Appendix D. Change Log
RFC Editor: remove this section upon publication as an RFC.
D.1. Changes Between Versions -07 and -08
o Edits based on Gen-ART review.
o Added formal templates in Section 13.
o Created the "Contributors" section and moved the former co-authors
there.
o Indicated the location of both global and local named pattern
definitions in the example hybrid schema in Section 8.1.
o Added reference to EXSLT "evaluate" function.
D.2. Changes Between Versions -06 and -07
o Mapping of 'description', 'reference' and 'units' to the hybrid
schema is now mandatory.
o Improvements and fixes of the text based on the AD review
D.3. Changes Between Versions -05 and -06
o Terminology change: "conceptual tree schema" -> "hybrid schema".
o Changed sectioning markers in the hybrid schema into plain NETMOD-
specific annotations. Hence the former "nmt" namespace is not
used at all.
o Added the following NETMOD-specific annotations: @nma:if-feature,
@nma:leaf-list, @nma:mandatory, @nma:module, removed @nma:
presence.
o Changed the structure of RELAX NG schemas by using embedded
grammars and declaration of namespaces via @ns. This was
necessary for enabling the "chameleon" behavior of global
definitions.
o Schematron validation phases are not used.
o If an XPath expression appears inside a top-level grouping, the
local prefix must be represented using the variable $pref. (This
is related to the previous item.)
o DHCP example: All RNG schemas are only in the XML syntax. Added
RNG with global definitions.
o Added [XML-INFOSET] to normative references.
o Listed the terms that are defined in other documents.
o The schema for NETMOD-specific annotation is now given only as RNG
named pattern definitions, no more in NVDL.
D.4. Changes Between Versions -04 and -05
o Leafs that take their default value from a typedef and are not
annotated with @nma:default must have @nma:implicit="true".
o Changed code markers CODE BEGINS/ENDS to the form agreed by the
WG.
o Derived types "date-and-time" and "uri" SHOULD be mapped to XSD
"dateTime" and "anyURI" types, respectively.
o Clarified the notion of implicit nodes under under 'case' in
Section 9.1.2.
o Moved draft-ietf-netmod-yang-types-06 to normative references.
o An extra <rng:group> is no more required for the default case of a
choice in the shorthand notation.
D.5. Changes Between Versions -03 and -04
o Implemented ordering rules for list children - keys must go first
and appear in the same order as in the input YANG module.
o The 'case' statement is now mapped to either <rng:group> (inside
RPC operations) or <rng:interleave> (otherwise).
o A nma:default annotation coming from a datatype which the mapping
expands is attached to the <rng:element> pattern where the
expansion occurs. Added an example.
o Documentation statements ('description', 'reference', 'status')
MAY be ignored.
o Single-valued numeric or length range parts are mapped to <rng:
value> pattern or "length" facet.
o Example for "string" datatype was added.
o Appendix A now uses NVDL for defining NETMOD-specific annotations.
o Added CODE BEGINS/ENDS markers.
o Separated normative and informative references.
o Added URL for XPath extensions namespace.
o Added Section 2 (Terminology and Notation).
o Added Section 14 (Security Considerations).
o Added Section 16 (Acknowledgments).
o Removed compact syntax schema from Appendix B.
o Editorial changes: symbolic citation labels.
D.6. Changes Between Versions -02 and -03
o Changed @nma:default-case to @nma:implicit.
o Changed nma:leafref annotation from element to attribute.
o Added skeleton rule to Section 11.2.
o Reworked Section 11.3, added skeleton element maps,corrected the
example.
o Added section on 'feature' and 'deviation'.
o New Section 9.1 integrating discussion of both optional/mandatory
(was in -02) and implicit nodes (new).
o Reflected that key argument and schema node identifiers are no
more XPath (should be in yang-07).
o Element patterns for implicit containers now must have @nma:
implicit attribute.
o Removed "float32" and "float64" types and added mapping of
"decimal64" with example.
o Removed mapping of 'require-instance' for "leafref" type.
o Updated RELAX NG schema for NETMOD-specific annotations.
o Updated the DHCP example.
D.7. Changes Between Versions -01 and -02
o Moved Section 7 "NETCONF Content Validation" after Section 6.
o New text about mapping defaults to DSRL, especially in Section 7
and Section 11.3.
o Finished the DHCP example by adding the DSRL schema to Appendix C.
o New @nma:presence annotation was added - it is needed for proper
handling of default contents.
o Section 11.2.1 "Constraints on Mandatory Choice" was added because
these constraints require a combination of RELAX NG and
Schematron.
o Fixed the schema for NETMOD-specific annotations by adding
explicit prefix to all defined elements and attributes.
Previously, the attributes had no namespace.
o Handling of 'feature', 'if-feature' and 'deviation' added.
o Handling of nma:instance-identifier via XSLT extension function.
D.8. Changes Between Versions -00 and -01
o Attributes @nma:min-elements and @nma:max-elements are attached to
<rng:element> (list entry) and not to <rng:zeroOrMore> or <rng:
oneOrMore>.
o Keys and all node identifiers in 'key' and 'unique' statements are
prefixed.
o Fixed the mapping of 'rpc' and 'notification'.
o Removed previous sec. 7.5 "RPC Signatures and Notifications" - the
same information is now contained in Section 10.50 and
Section 10.37.
o Added initial "_" to mangled names of groupings.
o Mandated the use of @xmlns:xxx as the only method for declaring
the target namespace.
o Added section "Handling of XML Namespaces" to explain the previous
item.
o Completed DHCP example in Appendix C.
o Almost all text about the second mapping step is new.
Author's Address Author's Address
Ladislav Lhotka (editor) Ladislav Lhotka (editor)
CESNET CESNET
Email: lhotka@cesnet.cz EMail: lhotka@cesnet.cz
 End of changes. 199 change blocks. 
740 lines changed or deleted 543 lines changed or added

This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/