draft-ietf-netmod-dsdl-map-03.txt   draft-ietf-netmod-dsdl-map-04.txt 
NETMOD L. Lhotka NETMOD L. Lhotka
Internet-Draft CESNET Internet-Draft CESNET
Intended status: Standards Track R. Mahy Intended status: Standards Track R. Mahy
Expires: January 14, 2010 Plantronics Expires: April 22, 2010 Plantronics
S. Chisholm S. Chisholm
Nortel Nortel
July 13, 2009 October 19, 2009
Mapping YANG to Document Schema Definition Languages and Validating Mapping YANG to Document Schema Definition Languages and Validating
NETCONF Content NETCONF Content
draft-ietf-netmod-dsdl-map-03 draft-ietf-netmod-dsdl-map-04
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 14, 2010. This Internet-Draft will expire on April 22, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 19 skipping to change at page 2, line 19
coordinated set of XML schema languages standardized as ISO 19757. coordinated set of XML schema languages standardized as ISO 19757.
The following DSDL schema languages are used by the mapping: RELAX The following DSDL schema languages are used by the mapping: RELAX
NG, Schematron and DSRL. The mapping takes one or more YANG modules NG, Schematron and DSRL. The mapping takes one or more YANG modules
and produces a set of DSDL schemas for a selected target document and produces a set of DSDL schemas for a selected target document
type - datastore content, NETCONF PDU etc. Procedures for schema- type - datastore content, NETCONF PDU etc. Procedures for schema-
based validation of such documents are also discussed. based validation of such documents are also discussed.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6
2. Objectives and Motivation . . . . . . . . . . . . . . . . . . 9 2. Terminology and Notation . . . . . . . . . . . . . . . . . . 7
3. DSDL Schema Languages . . . . . . . . . . . . . . . . . . . . 11 2.1. Glossary of New Terms . . . . . . . . . . . . . . . . . 8
3.1. RELAX NG . . . . . . . . . . . . . . . . . . . . . . . . 11 3. Objectives and Motivation . . . . . . . . . . . . . . . . . . 10
3.2. Schematron . . . . . . . . . . . . . . . . . . . . . . . 12 4. DSDL Schema Languages . . . . . . . . . . . . . . . . . . . . 12
3.3. Document Semantics Renaming Language (DSRL) . . . . . . 13 4.1. RELAX NG . . . . . . . . . . . . . . . . . . . . . . . . 12
4. Additional Annotations . . . . . . . . . . . . . . . . . . . 14 4.2. Schematron . . . . . . . . . . . . . . . . . . . . . . . 13
4.1. Dublin Core Metadata Elements . . . . . . . . . . . . . 14 4.3. Document Semantics Renaming Language (DSRL) . . . . . . 14
4.2. RELAX NG DTD Compatibility Annotations . . . . . . . . . 14 5. Additional Annotations . . . . . . . . . . . . . . . . . . . 15
4.3. NETMOD-Specific Annotations . . . . . . . . . . . . . . 15 5.1. Dublin Core Metadata Elements . . . . . . . . . . . . . 15
5. Overview of the Mapping . . . . . . . . . . . . . . . . . . . 17 5.2. RELAX NG DTD Compatibility Annotations . . . . . . . . . 15
6. NETCONF Content Validation . . . . . . . . . . . . . . . . . 19 5.3. NETMOD-Specific Annotations . . . . . . . . . . . . . . 16
7. Design Considerations . . . . . . . . . . . . . . . . . . . . 20 6. Overview of the Mapping . . . . . . . . . . . . . . . . . . . 18
7.1. Conceptual Data Tree . . . . . . . . . . . . . . . . . . 20 7. NETCONF Content Validation . . . . . . . . . . . . . . . . . 20
7.2. Modularity . . . . . . . . . . . . . . . . . . . . . . . 22 8. Design Considerations . . . . . . . . . . . . . . . . . . . . 21
7.3. Granularity . . . . . . . . . . . . . . . . . . . . . . 23 8.1. Conceptual Data Tree . . . . . . . . . . . . . . . . . . 21
7.4. Handling of XML Namespaces . . . . . . . . . . . . . . . 23 8.2. Modularity . . . . . . . . . . . . . . . . . . . . . . . 23
7.5. Features and Deviations . . . . . . . . . . . . . . . . 24 8.3. Granularity . . . . . . . . . . . . . . . . . . . . . . 24
8. Mapping YANG Data Models to the Conceptual Tree Schema . . . 25 8.4. Handling of XML Namespaces . . . . . . . . . . . . . . . 24
8.1. Occurrence Rules for Data Nodes . . . . . . . . . . . . 25 8.5. Features and Deviations . . . . . . . . . . . . . . . . 25
8.1.1. Optional and Mandatory Nodes . . . . . . . . . . . 26 9. Mapping YANG Data Models to the Conceptual Tree Schema . . . 26
8.1.2. Implicit Nodes . . . . . . . . . . . . . . . . . . 27 9.1. Occurrence Rules for Data Nodes . . . . . . . . . . . . 26
8.2. Mapping YANG Groupings and Typedefs . . . . . . . . . . 28 9.1.1. Optional and Mandatory Nodes . . . . . . . . . . . 27
8.2.1. YANG Refinements and Augments . . . . . . . . . . . 30 9.1.2. Implicit Nodes . . . . . . . . . . . . . . . . . . 28
8.2.2. Type derivation chains . . . . . . . . . . . . . . 33 9.2. Mapping YANG Groupings and Typedefs . . . . . . . . . . 29
8.3. Translation of XPath Expressions . . . . . . . . . . . . 34 9.2.1. YANG Refinements and Augments . . . . . . . . . . . 31
8.4. YANG Language Extensions . . . . . . . . . . . . . . . . 35 9.2.2. Type derivation chains . . . . . . . . . . . . . . 34
9. Mapping Conceptual Tree Schema to DSDL . . . . . . . . . . . 37 9.3. Translation of XPath Expressions . . . . . . . . . . . . 37
9.1. Generating RELAX NG Schemas for Various Document Types . 37 9.4. YANG Language Extensions . . . . . . . . . . . . . . . . 37
9.1.1. Reply to <get> or <get-config> . . . . . . . . . . 38 10. Mapping Conceptual Tree Schema to DSDL . . . . . . . . . . . 39
9.1.2. Remote Procedure Calls . . . . . . . . . . . . . . 38 10.1. Generating RELAX NG Schemas for Various Document Types . 39
9.1.3. Notifications . . . . . . . . . . . . . . . . . . . 39 10.1.1. Reply to <get> or <get-config> . . . . . . . . . . 40
9.2. Mapping Semantic Constraints to Schematron . . . . . . . 40 10.1.2. Remote Procedure Calls . . . . . . . . . . . . . . 40
9.2.1. Validation Phases . . . . . . . . . . . . . . . . . 43 10.1.3. Notifications . . . . . . . . . . . . . . . . . . . 41
9.3. Constraints on Mandatory Choice . . . . . . . . . . . . 44
9.4. Mapping Default Values to DSRL . . . . . . . . . . . . . 46
10. Mapping YANG Statements to Conceptual Tree Schema . . . . . . 50
10.1. The anyxml Statement . . . . . . . . . . . . . . . . . . 50
10.2. The argument Statement . . . . . . . . . . . . . . . . . 51
10.3. The augment Statement . . . . . . . . . . . . . . . . . 52
10.4. The base Statement . . . . . . . . . . . . . . . . . . . 52
10.5. The belongs-to Statement . . . . . . . . . . . . . . . . 52
10.6. The bit Statement . . . . . . . . . . . . . . . . . . . 52
10.7. The case Statement . . . . . . . . . . . . . . . . . . . 52
10.8. The choice Statement . . . . . . . . . . . . . . . . . . 52
10.9. The config Statement . . . . . . . . . . . . . . . . . . 53
10.10. The contact Statement . . . . . . . . . . . . . . . . . 53
10.11. The container Statement . . . . . . . . . . . . . . . . 53
10.12. The default Statement . . . . . . . . . . . . . . . . . 53
10.13. The description Statement . . . . . . . . . . . . . . . 54
10.14. The deviation Statement . . . . . . . . . . . . . . . . 54
10.15. The enum Statement . . . . . . . . . . . . . . . . . . . 54
10.16. The error-app-tag Statement . . . . . . . . . . . . . . 55
10.17. The error-message Statement . . . . . . . . . . . . . . 55
10.18. The extension Statement . . . . . . . . . . . . . . . . 55
10.19. The feature Statement . . . . . . . . . . . . . . . . . 55
10.20. The grouping Statement . . . . . . . . . . . . . . . . . 55
10.21. The identity Statement . . . . . . . . . . . . . . . . . 55
10.22. The if-feature Statement . . . . . . . . . . . . . . . . 56
10.23. The import Statement . . . . . . . . . . . . . . . . . . 56
10.24. The include Statement . . . . . . . . . . . . . . . . . 56
10.25. The input Statement . . . . . . . . . . . . . . . . . . 56
10.26. The key Statement . . . . . . . . . . . . . . . . . . . 56
10.27. The leaf Statement . . . . . . . . . . . . . . . . . . . 56
10.28. The leaf-list Statement . . . . . . . . . . . . . . . . 57
10.29. The length Statement . . . . . . . . . . . . . . . . . . 57
10.30. The list Statement . . . . . . . . . . . . . . . . . . . 58
10.31. The mandatory Statement . . . . . . . . . . . . . . . . 58
10.32. The max-elements Statement . . . . . . . . . . . . . . . 58
10.33. The min-elements Statement . . . . . . . . . . . . . . . 58
10.34. The module Statement . . . . . . . . . . . . . . . . . . 58
10.35. The must Statement . . . . . . . . . . . . . . . . . . . 58
10.36. The namespace Statement . . . . . . . . . . . . . . . . 59
10.37. The notification Statement . . . . . . . . . . . . . . . 59
10.38. The ordered-by Statement . . . . . . . . . . . . . . . . 59
10.39. The organization Statement . . . . . . . . . . . . . . . 60
10.40. The output Statement . . . . . . . . . . . . . . . . . . 60
10.41. The path Statement . . . . . . . . . . . . . . . . . . . 60
10.42. The pattern Statement . . . . . . . . . . . . . . . . . 60
10.43. The position Statement . . . . . . . . . . . . . . . . . 60
10.44. The prefix Statement . . . . . . . . . . . . . . . . . . 60
10.45. The presence Statement . . . . . . . . . . . . . . . . . 60
10.46. The range Statement . . . . . . . . . . . . . . . . . . 60
10.47. The reference Statement . . . . . . . . . . . . . . . . 60
10.48. The require-instance Statement . . . . . . . . . . . . . 61
10.49. The revision Statement . . . . . . . . . . . . . . . . . 61
10.50. The rpc Statement . . . . . . . . . . . . . . . . . . . 61
10.51. The status Statement . . . . . . . . . . . . . . . . . . 62
10.52. The submodule Statement . . . . . . . . . . . . . . . . 62
10.53. The type Statement . . . . . . . . . . . . . . . . . . . 62
10.53.1. The empty Type . . . . . . . . . . . . . . . . . . 63
10.53.2. The boolean and binary Types . . . . . . . . . . . 63
10.53.3. The bits Type . . . . . . . . . . . . . . . . . . . 63
10.53.4. The enumeration and union Types . . . . . . . . . . 63
10.53.5. The identityref Type . . . . . . . . . . . . . . . 63
10.53.6. The instance-identifier Type . . . . . . . . . . . 65
10.53.7. The leafref Type . . . . . . . . . . . . . . . . . 65
10.53.8. The numeric Types . . . . . . . . . . . . . . . . . 65
10.53.9. The string Type . . . . . . . . . . . . . . . . . . 67
10.53.10. Derived Types . . . . . . . . . . . . . . . . . . . 67
10.54. The typedef Statement . . . . . . . . . . . . . . . . . 68
10.55. The unique Statement . . . . . . . . . . . . . . . . . . 68
10.56. The units Statement . . . . . . . . . . . . . . . . . . 68
10.57. The uses Statement . . . . . . . . . . . . . . . . . . . 69
10.58. The value Statement . . . . . . . . . . . . . . . . . . 69
10.59. The when Statement . . . . . . . . . . . . . . . . . . . 69
10.60. The yang-version Statement . . . . . . . . . . . . . . . 69
10.61. The yin-element Statement . . . . . . . . . . . . . . . 69
11. Mapping NETMOD-specific annotations to DSDL Schema
Languages . . . . . . . . . . . . . . . . . . . . . . . . . . 70
11.1. The @nma:config Annotation . . . . . . . . . . . . . . . 70
11.2. The @nma:default Annotation . . . . . . . . . . . . . . 70
11.3. The @nma:implicit Annotation . . . . . . . . . . . . . . 70
11.4. The <nma:error-app-tag> Annotation . . . . . . . . . . . 70
11.5. The <nma:error-message> Annotation . . . . . . . . . . . 70
11.6. The <nma:instance-identifier> Annotation . . . . . . . . 70
11.7. The @nma:key Annotation . . . . . . . . . . . . . . . . 71
11.8. The @nma:leafref Annotation . . . . . . . . . . . . . . 71
11.9. The @nma:min-elements Annotation . . . . . . . . . . . . 71
11.10. The @nma:max-elements Annotation . . . . . . . . . . . . 72
11.11. The <nma:must> Annotation . . . . . . . . . . . . . . . 72
11.12. The <nma:ordered-by> Annotation . . . . . . . . . . . . 72
11.13. The <nma:status> Annotation . . . . . . . . . . . . . . 72
11.14. The @nma:unique Annotation . . . . . . . . . . . . . . . 72
11.15. The @nma:when Annotation . . . . . . . . . . . . . . . . 73
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 74
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 75
Appendix A. RELAX NG Schema for NETMOD-specific Annotations . . 77
A.1. XML Syntax . . . . . . . . . . . . . . . . . . . . . . . 77
A.2. Compact Syntax . . . . . . . . . . . . . . . . . . . . . 80
Appendix B. Schema-Independent Library . . . . . . . . . . . . . 81 10.2. Mapping Semantic Constraints to Schematron . . . . . . . 42
B.1. XML Syntax . . . . . . . . . . . . . . . . . . . . . . . 81 10.2.1. Validation Phases . . . . . . . . . . . . . . . . . 45
B.2. Compact Syntax . . . . . . . . . . . . . . . . . . . . . 82 10.3. Constraints on Mandatory Choice . . . . . . . . . . . . 46
Appendix C. Mapping DHCP Data Model - A Complete Example . . . . 83 10.4. Mapping Default Values to DSRL . . . . . . . . . . . . . 48
C.1. Input YANG Module . . . . . . . . . . . . . . . . . . . 83 11. Mapping YANG Statements to Conceptual Tree Schema . . . . . . 53
C.2. Conceptual Tree Schema . . . . . . . . . . . . . . . . . 86 11.1. The anyxml Statement . . . . . . . . . . . . . . . . . . 53
C.2.1. XML Syntax . . . . . . . . . . . . . . . . . . . . 86 11.2. The argument Statement . . . . . . . . . . . . . . . . . 54
C.2.2. Compact Syntax . . . . . . . . . . . . . . . . . . 91 11.3. The augment Statement . . . . . . . . . . . . . . . . . 55
C.3. Final DSDL Schemas . . . . . . . . . . . . . . . . . . . 93 11.4. The base Statement . . . . . . . . . . . . . . . . . . . 55
C.3.1. RELAX NG Schema for <get> Reply - XML Syntax . . . 94 11.5. The belongs-to Statement . . . . . . . . . . . . . . . . 55
C.3.2. RELAX NG Schema for <get> Reply - Compact Syntax . 98 11.6. The bit Statement . . . . . . . . . . . . . . . . . . . 55
C.4. Schematron Schema for <get> Reply . . . . . . . . . . . 100 11.7. The case Statement . . . . . . . . . . . . . . . . . . . 55
C.5. DSRL Schema for <get> Reply . . . . . . . . . . . . . . 102 11.8. The choice Statement . . . . . . . . . . . . . . . . . . 55
Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 103 11.9. The config Statement . . . . . . . . . . . . . . . . . . 56
D.1. Changes Between Versions -02 and -03 . . . . . . . . . . 103 11.10. The contact Statement . . . . . . . . . . . . . . . . . 56
D.2. Changes Between Versions -01 and -02 . . . . . . . . . . 103 11.11. The container Statement . . . . . . . . . . . . . . . . 56
D.3. Changes Between Versions -00 and -01 . . . . . . . . . . 104 11.12. The default Statement . . . . . . . . . . . . . . . . . 56
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 105 11.13. The description Statement . . . . . . . . . . . . . . . 57
11.14. The deviation Statement . . . . . . . . . . . . . . . . 58
11.15. The enum Statement . . . . . . . . . . . . . . . . . . . 58
11.16. The error-app-tag Statement . . . . . . . . . . . . . . 58
11.17. The error-message Statement . . . . . . . . . . . . . . 58
11.18. The extension Statement . . . . . . . . . . . . . . . . 58
11.19. The feature Statement . . . . . . . . . . . . . . . . . 58
11.20. The grouping Statement . . . . . . . . . . . . . . . . . 58
11.21. The identity Statement . . . . . . . . . . . . . . . . . 59
11.22. The if-feature Statement . . . . . . . . . . . . . . . . 59
11.23. The import Statement . . . . . . . . . . . . . . . . . . 59
11.24. The include Statement . . . . . . . . . . . . . . . . . 59
11.25. The input Statement . . . . . . . . . . . . . . . . . . 59
11.26. The key Statement . . . . . . . . . . . . . . . . . . . 59
11.27. The leaf Statement . . . . . . . . . . . . . . . . . . . 60
11.28. The leaf-list Statement . . . . . . . . . . . . . . . . 60
11.29. The length Statement . . . . . . . . . . . . . . . . . . 61
11.30. The list Statement . . . . . . . . . . . . . . . . . . . 61
11.31. The mandatory Statement . . . . . . . . . . . . . . . . 62
11.32. The max-elements Statement . . . . . . . . . . . . . . . 62
11.33. The min-elements Statement . . . . . . . . . . . . . . . 62
11.34. The module Statement . . . . . . . . . . . . . . . . . . 62
11.35. The must Statement . . . . . . . . . . . . . . . . . . . 63
11.36. The namespace Statement . . . . . . . . . . . . . . . . 63
11.37. The notification Statement . . . . . . . . . . . . . . . 63
11.38. The ordered-by Statement . . . . . . . . . . . . . . . . 64
11.39. The organization Statement . . . . . . . . . . . . . . . 64
11.40. The output Statement . . . . . . . . . . . . . . . . . . 64
11.41. The path Statement . . . . . . . . . . . . . . . . . . . 64
11.42. The pattern Statement . . . . . . . . . . . . . . . . . 64
11.43. The position Statement . . . . . . . . . . . . . . . . . 64
11.44. The prefix Statement . . . . . . . . . . . . . . . . . . 64
11.45. The presence Statement . . . . . . . . . . . . . . . . . 64
11.46. The range Statement . . . . . . . . . . . . . . . . . . 65
11.47. The reference Statement . . . . . . . . . . . . . . . . 65
11.48. The require-instance Statement . . . . . . . . . . . . . 65
11.49. The revision Statement . . . . . . . . . . . . . . . . . 65
11.50. The rpc Statement . . . . . . . . . . . . . . . . . . . 65
11.51. The status Statement . . . . . . . . . . . . . . . . . . 66
11.52. The submodule Statement . . . . . . . . . . . . . . . . 66
11.53. The type Statement . . . . . . . . . . . . . . . . . . . 66
11.53.1. The empty Type . . . . . . . . . . . . . . . . . . 67
11.53.2. The boolean and binary Types . . . . . . . . . . . 67
11.53.3. The bits Type . . . . . . . . . . . . . . . . . . . 67
11.53.4. The enumeration and union Types . . . . . . . . . . 68
11.53.5. The identityref Type . . . . . . . . . . . . . . . 68
11.53.6. The instance-identifier Type . . . . . . . . . . . 70
11.53.7. The leafref Type . . . . . . . . . . . . . . . . . 70
11.53.8. The numeric Types . . . . . . . . . . . . . . . . . 70
11.53.9. The string Type . . . . . . . . . . . . . . . . . . 72
11.53.10. Derived Types . . . . . . . . . . . . . . . . . . . 73
11.54. The typedef Statement . . . . . . . . . . . . . . . . . 74
11.55. The unique Statement . . . . . . . . . . . . . . . . . . 74
11.56. The units Statement . . . . . . . . . . . . . . . . . . 74
11.57. The uses Statement . . . . . . . . . . . . . . . . . . . 74
11.58. The value Statement . . . . . . . . . . . . . . . . . . 75
11.59. The when Statement . . . . . . . . . . . . . . . . . . . 75
11.60. The yang-version Statement . . . . . . . . . . . . . . . 75
11.61. The yin-element Statement . . . . . . . . . . . . . . . 75
12. Mapping NETMOD-specific annotations to DSDL Schema
Languages . . . . . . . . . . . . . . . . . . . . . . . . . . 76
12.1. The @nma:config Annotation . . . . . . . . . . . . . . . 76
12.2. The @nma:default Annotation . . . . . . . . . . . . . . 76
12.3. The @nma:implicit Annotation . . . . . . . . . . . . . . 76
12.4. The <nma:error-app-tag> Annotation . . . . . . . . . . . 76
12.5. The <nma:error-message> Annotation . . . . . . . . . . . 76
12.6. The <nma:instance-identifier> Annotation . . . . . . . . 76
12.7. The @nma:key Annotation . . . . . . . . . . . . . . . . 77
12.8. The @nma:leafref Annotation . . . . . . . . . . . . . . 77
12.9. The @nma:min-elements Annotation . . . . . . . . . . . . 77
12.10. The @nma:max-elements Annotation . . . . . . . . . . . . 78
12.11. The <nma:must> Annotation . . . . . . . . . . . . . . . 78
12.12. The <nma:ordered-by> Annotation . . . . . . . . . . . . 78
12.13. The <nma:status> Annotation . . . . . . . . . . . . . . 78
12.14. The @nma:unique Annotation . . . . . . . . . . . . . . . 78
12.15. The @nma:when Annotation . . . . . . . . . . . . . . . . 79
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 80
14. Security Considerations . . . . . . . . . . . . . . . . . . . 81
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 82
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 83
16.1. Normative References . . . . . . . . . . . . . . . . . . 83
16.2. Informative References . . . . . . . . . . . . . . . . . 84
Appendix A. Schemas for NETMOD-Specific Annotations . . . . . . 87
A.1. NVDL Schema . . . . . . . . . . . . . . . . . . . . . . 87
A.2. Annotation Attributes for define Pattern . . . . . . . . 89
A.3. Annotation Elements for element Pattern . . . . . . . . 89
A.4. Annotation Attributes for element Pattern . . . . . . . 90
A.5. Annotation attributes for group Pattern . . . . . . . . 90
A.6. Annotation attributes for choice and ref Patterns . . . 91
A.7. Annotation attributes for element Pattern in the List
Context . . . . . . . . . . . . . . . . . . . . . . . . 91
A.8. Annotation attributes for value Pattern . . . . . . . . 92
A.9. Named Patterns for All NETMOD-Specific Annotations . . . 92
Appendix B. Schema-Independent Library . . . . . . . . . . . . . 96
Appendix C. Mapping DHCP Data Model - A Complete Example . . . . 97
C.1. Input YANG Module . . . . . . . . . . . . . . . . . . . 97
C.2. Conceptual Tree Schema . . . . . . . . . . . . . . . . . 100
C.2.1. XML Syntax . . . . . . . . . . . . . . . . . . . . 100
C.2.2. Compact Syntax . . . . . . . . . . . . . . . . . . 105
C.3. Final DSDL Schemas . . . . . . . . . . . . . . . . . . . 107
C.3.1. RELAX NG Schema for <get> Reply - XML Syntax . . . 108
C.3.2. RELAX NG Schema for <get> Reply - Compact Syntax . 112
C.4. Schematron Schema for <get> Reply . . . . . . . . . . . 114
C.5. DSRL Schema for <get> Reply . . . . . . . . . . . . . . 116
Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 117
D.1. Changes Between Versions -03 and -04 . . . . . . . . . . 117
D.2. Changes Between Versions -02 and -03 . . . . . . . . . . 117
D.3. Changes Between Versions -01 and -02 . . . . . . . . . . 118
D.4. Changes Between Versions -00 and -01 . . . . . . . . . . 119
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 120
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 [1]. 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 modeling language or management operations, but does not include a modeling language or
accompanying rules for how to model configuration and status accompanying rules for how to model configuration and status
information (in XML syntax) carried by NETCONF. The IETF Operations information (in XML syntax) carried by NETCONF. The IETF Operations
Area has a long tradition of defining data for SNMP Management Area has a long tradition of defining data for SNMP Management
Information Bases (MIBs) [2] using the SMI language [3] to model its Information Bases (MIBs) [RFC1157] using the SMI language [RFC2578]
data. While this specific modeling approach has a number of well- to model its data. While this specific modeling approach has a
understood problems, most of the data modeling features provided by number of well-understood problems, most of the data modeling
SMI are still considered extremely important. Simply modeling the features provided by SMI are still considered extremely important.
valid syntax rather than additional semantic relationships has caused Simply modeling the valid syntax rather than additional semantic
significant interoperability problems in the past. relationships has caused 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 address this problem, by defining a new human-friendly chartered to address this problem, by defining a new human-friendly
modeling language based on SMIng [4] and called YANG [5]. modeling language based on SMIng [RFC3216] and called YANG [YANG].
Since NETCONF uses XML for encoding its protocol data units (PDU), it Since NETCONF uses XML for encoding its protocol data units (PDU), it
is natural to express the constraints on NETCONF content using is natural to express the constraints on NETCONF content using
standard XML schema languages. For this purpose, the NETMOD WG standard XML schema languages. For this purpose, the NETMOD WG
selected the Document Schema Definition Languages (DSDL) that is selected the Document Schema Definition Languages (DSDL) that is
being standardized as ISO/IEC 19757 [6]. The DSDL framework being standardized as ISO/IEC 19757 [DSDL]. The DSDL framework
comprises a set of XML schema languages that address grammar rules, comprises a set of XML schema languages that address grammar rules,
semantic constraints and other data modeling aspects but also, and semantic constraints and other data modeling aspects but also, and
more importantly, do it in a coordinated and consistent way. While more importantly, do it in a coordinated and consistent way. While
it is true that some DSDL parts have not been standardized yet and it is true that some DSDL parts have not been standardized yet and
are still work in progress, the three parts that the YANG-to-DSDL are still work in progress, the three parts that the YANG-to-DSDL
mapping relies upon - RELAX NG, Schematron and DSRL - already have mapping relies upon - RELAX NG, Schematron and DSRL - already have
the status of an ISO/IEC International Standard and are supported in the status of an ISO/IEC International Standard and are supported in
a number of software tools. a number of software tools.
This document contains specification of a mapping that translates This document contains specification of a mapping that translates
skipping to change at page 7, line 5 skipping to change at page 7, line 5
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, RPC signatures and first step, the structure of the data tree, RPC signatures and
notifications is expressed as a single RELAX NG grammar with simple notifications is expressed as a single RELAX NG grammar with simple
annotations 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
validate specific XML documents such as client requests, server validate specific XML documents such as client requests, server
responses or notifications, perhaps also taking into account responses or notifications, perhaps also taking into account
additional context such as active capabilities. additional context such as active capabilities.
2. Terminology and Notation
This document relies on many terms that are defined in the
specifications of the NETCONF protocol [RFC4741] and YANG data
modeling language [YANG]. Also, the common terminology of XML and
DSDL schema languages is used as defined in the respective standards
[XML], [DSDL], [NVDL], [RNG], [Schematron] and [DSRL].
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 [7]. document are to be interpreted as described in [RFC2119].
In the text, we also use the following typographic conventions: In the text, we use the following typographic conventions:
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 elements names are always written with explicit namespace
prefixes corresponding to the following XML vocabularies: prefixes corresponding to the following XML vocabularies:
"a" DTD compatibility annotations [8] "a" DTD compatibility annotations [RNG-DTD]
"dc" Dublin Core metadata elements [9] "dc" Dublin Core metadata elements [RFC5013]
"nc" NETCONF protocol [1] "dsrl" Document Semantics Renaming Language [DSRL]
"en" NETCONF event notifications [10] "en" NETCONF event notifications [RFC5277]
"nma" NETMOD-specific schema annotations (see Section 4.3) "nc" NETCONF protocol [RFC4741]
"nmt" Conceptual tree (see Section 7.1) "nma" NETMOD-specific schema annotations (see Section 5.3)
"dsrl" Document Semantics Renaming Language [11] "nmf" NETMOD-specific XPath extension functions
"rng" RELAX NG [12] "nmt" Conceptual tree (see Section 8.1)
"sch" ISO Schematron [13] "rng" RELAX NG [RNG]
"xsd" W3C XML Schema [14] "sch" ISO Schematron [Schematron]
"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 |
| | | | | |
| dc | http://purl.org/dc/terms | | dc | http://purl.org/dc/terms |
| | | | | |
| nc | urn:ietf:params:xml:ns:netconf:base:1.0 | | dsrl | http://purl.oclc.org/dsdl/dsrl |
| | | | | |
| en | urn:ietf:params:xml:ns:netconf:notification:1.0 | | en | urn:ietf:params:xml:ns:netconf:notification:1.0 |
| | | | | |
| nc | urn:ietf:params:xml:ns:netconf:base:1.0 |
| | |
| nma | urn:ietf:params:xml:ns:netmod:dsdl-annotations:1 | | nma | urn:ietf:params:xml:ns:netmod:dsdl-annotations:1 |
| | | | | |
| nmt | urn:ietf:params:xml:ns:netmod:conceptual-tree:1 | | nmf | urn:ietf:params:xml:ns:netmod:xpath-extensions:1 |
| | | | | |
| dsrl | http://purl.oclc.org/dsdl/dsrl | | nmt | urn:ietf:params:xml:ns:netmod:conceptual-tree:1 |
| | | | | |
| rng | http://relaxng.org/ns/structure/1.0 | | rng | http://relaxng.org/ns/structure/1.0 |
| | | | | |
| 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. Objectives and Motivation 2.1. Glossary of New Terms
o ancestor datatype: Any datytype a given datatype is (transitively)
derived from.
o ancestor built-in datatype: The built-in datatype that is at the
start of the type derivation chain for a given datatype.
o conceptual data tree: A virtual XML document integrating all
components of a YANG data model, i.e., configuration datastore,
RPC methods (both requests and replies) and notifications. The
conceptual tree is normally not instantiated, it only serves as a
conceptual target for its schema. See Section 8.1 for details.
o implicit node: A node that, if missing, may be added to the
information set of an XML document (configuration, RPC input or
output, notification) without changing the meaning of that XML
document for the NETCONF server.
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 by validation capabilities of DSDL schema modeling language by validation capabilities of DSDL schema
languages, primarily RELAX NG and Schematron. This document languages, primarily RELAX NG and Schematron. 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 constructs. type constraints expressed in YANG and equivalent DSDL constructs.
The ultimate goal is to be able to capture all substantial 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 is in While the mapping from YANG to DSDL described in this document is in
principle invertible, the inverse mapping from DSDL to YANG is not in principle invertible, the inverse mapping from DSDL to YANG is not in
its scope. its scope.
XML-encoded data appear in several different forms in various phases XML-based information models and XML-encoded data appear in several
of the NETCONF workflow - configuration datastore contents, RPC different forms in various phases of YANG data modeling and NETCONF
requests and replies, and notifications. Moreover, RPC methods are workflow - configuration datastore contents, RPC requests and
characterized by an inherent diversity resulting from selective replies, and notifications. Moreover, RPC methods are characterized
availability of capabilities and features. YANG modules can also by an inherent diversity resulting from selective availability of
define new RPC methods. The mapping should be able to accommodate capabilities and features. YANG modules can also define new RPC
this variability and generate schemas that are specifically tailored methods. The mapping should be able to accommodate this variability
to a particular situation and thus considerably more efficient than and generate schemas that are specifically tailored to a particular
situation and thus considerably more effective for validation than
generic all-encompassing schemas. generic all-encompassing schemas.
In order to cope with this variability, we assume that the schemas In order to cope with this variability, we assume that the schemas
can be generated on demand from the available collection of YANG can be generated on demand from the available collection of YANG
modules and their lifetime will be relatively short. In other words, modules and their lifetime will be relatively short. In other words,
we don't envision that any collection of DSDL schemas will be created we don't envision that any collection of DSDL schemas will be created
and maintained over an extended period of time in parallel to YANG and maintained over an extended period of time in parallel to YANG
modules. modules.
The generated schemas are primarily intended as input to the existing The generated schemas are primarily intended as input to the existing
skipping to change at page 11, line 5 skipping to change at page 12, line 5
NG, the schema is augmented by simple annotations. The output of NG, the schema is augmented by simple annotations. The output of
the first step can thus be considered a reasonably readable the first step can thus be considered a reasonably readable
equivalent of the input YANG modules. equivalent of the input YANG modules.
2. In the second step, the annotated RELAX NG schema from step 1 is 2. In the second step, the annotated RELAX NG schema from step 1 is
transformed further to a coordinated set of fully conformant DSDL transformed further to a coordinated set of fully conformant DSDL
schemas containing constraints for a particular data object and a schemas 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.
3. 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 an international standard ISO/ languages that is being developed as an international standard ISO/
IEC 19757. Unlike other approaches to XML document validation, IEC 19757. Unlike other approaches to XML document validation,
notably W3C XML Schema (XSD) [14], the DSDL framework adheres to the notably W3C XML Schema (XSD) [XSD], the DSDL framework adheres to the
principle of "small languages": Each of the DSDL constituents is a principle of "small languages": Each of the DSDL constituents is a
stand-alone schema languages with a relatively narrow purpose and stand-alone schema language with a relatively narrow purpose and
focus. Together, these schema languages may be used in a coordinated focus. Together, these schema languages may be used in a coordinated
way to accomplish various validation tasks. way to accomplish various 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, Schematron and DSRL. languages, namely RELAX NG, Schematron and DSRL.
3.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 [12]. Like the W3C XML Schema language [14], it is able to standards [RNG]. Like the W3C XML Schema language [XSD], it is able
describe constraints on the structure and content of XML documents. to describe constraints on the structure and content of XML
However, unlike the DTD [15] and XSD schema languages, RELAX NG documents. However, unlike the DTD [XML] and XSD schema languages,
intentionally avoids any infoset augmentation such as defining RELAX NG intentionally avoids any infoset augmentation such as
default values. In the DSDL architecture, the particular task of defining default values. In the DSDL architecture, the particular
defining and applying default values is delegated to another schema task of defining and applying default values is delegated to another
language, DSRL (see Section 3.3). schema language, DSRL (see Section 4.3).
As its base datatype library, RELAX NG uses the W3C XML Schema As its base datatype library, RELAX NG uses the W3C XML Schema
Datatype Library [16], but unlike XSD, other datatype libraries may Datatype Library [XSD-D], but unlike XSD, other datatype libraries
be used along with it or even replace it if necessary. may be 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 few exceptions, such annotations may be placed namespaces. With 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 n 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 [17], 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 syntaxes can be accomplished using several tools, for example
Trang [23]. Trang [1].
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 and
other software tools generally require the XML syntax. However, the other software tools generally require the XML syntax. However, the
compact syntax has two drawbacks: 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 four different syntactic constructs: documentation, syntax uses four different syntactic constructs: documentation,
grammar, initial and following annotations. Therefore, the impact grammar, initial and following annotations. Therefore, the impact
of annotations on readability is often much stronger for the of annotations on readability is often much stronger for the
compact syntax than for the XML syntax. compact syntax than for the XML syntax.
o In a program, it is more difficult to generate compact syntax than o In a computer program, it is more difficult to generate compact
XML syntax. While a number of software libraries exist that make syntax than XML syntax. While a number of software libraries
it easy to create an XML tree in memory and serialize it, no such exist that make it easy to create an XML tree in memory and
aid is available for compact syntax. serialize it, no such aid is available for 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 W3C
Schema Datatype Library is Schema Datatype Library is
"http://www.w3.org/2001/XMLSchema-datatypes". "http://www.w3.org/2001/XMLSchema-datatypes".
3.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 [13]. In contrast to the traditional schema IEC standard in 2006 [Schematron]. In contrast to the traditional
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 the
concept of a formal grammar, Schematron utilizes a rule-based 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;
o human-readable message that is displayed when the assert condition o human-readable message that is displayed when the assert condition
is false or report condition is true. is false or report condition is true.
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 [18] and Schematron draws most of its expressive power from XPath [XPath] and
XSLT [19]. ISO Schematron allows for dynamic query language binding XSLT [XSLT]. ISO Schematron allows for dynamic query language
so that the following XML query languages can be used: STX, XSLT 1.0, binding so that the following XML query languages can be used: STX,
XSLT 1.1, EXSLT, XSLT 2.0, XPath 1.0, XPath 2.0 and XQuery 1.0 (this XSLT 1.0, XSLT 1.1, EXSLT, XSLT 2.0, XPath 1.0, XPath 2.0 and XQuery
list may be extended in future). 1.0 (this list may be extended in future).
The human-readable error messages are another feature that The human-readable error messages are another feature that
distinguishes Schematron from other common schema languages. The distinguishes Schematron from other common schema languages. The
messages may even contain XPath expressions that are evaluated in the messages may even contain XPath expressions that are evaluated in the
actual context and thus refer to existing XML document nodes and actual context and thus refer to existing XML document nodes and
their content. their content.
The rules defined by a Schematron schema may be divided into several The rules defined by a Schematron schema may be divided into several
subsets known as _phases_. Validations may then be set up to include subsets known as _phases_. Validations may then be set up to include
only selected phases. In the context of NETCONF data validation, only selected phases. In the context of NETCONF data validation,
this is useful for relaxing constraints that may not always apply. this is useful for relaxing constraints that may not always apply.
For example, the reference integrity may not be enforced for a For example, the reference integrity may not be enforced for a
candidate configuration. candidate configuration.
Schematron elements are qualified with namespace URI Schematron elements are qualified with namespace URI
"http://purl.oclc.org/dsdl/schematron". "http://purl.oclc.org/dsdl/schematron".
3.3. Document Semantics Renaming Language (DSRL) 4.3. Document Semantics Renaming Language (DSRL)
DSRL (pronounced "disrule") is Part 8 of DSDL that reached the status DSRL (pronounced "disrule") is Part 8 of DSDL that reached the status
of a full ISO/IEC standard in 2008 [11]. Unlike RELAX NG and of a full ISO/IEC standard in 2008 [DSRL]. Unlike RELAX NG and
Schematron, it is specifically designed to modify XML information set Schematron, it is specifically designed to modify XML information set
of the validated document. While DSRL is primarily intended for of the validated document. While DSRL is primarily intended for
renaming XML elements and attributes, it can also define default renaming XML elements and attributes, it can also define default
values for XML attributes and default content for XML elements so values for XML attributes and default content for XML elements so
that elements or attributes with these default values are inserted if that elements or attributes with these default values are inserted if
they are missing (or present and empty) in the validated documents. they are missing (or present and empty) in the validated documents.
The latter feature is used by the YANG-to-DSDL mapping for The latter feature is used by the YANG-to-DSDL mapping for
representing YANG default values for leaf nodes. representing YANG default values for leaf nodes.
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".
4. 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. Two of the annotation sets - Dublin elements to RELAX NG schemas. Two of the annotation sets - Dublin
Core elements and DTD compatibility annotations - are standard Core elements and DTD compatibility annotations - are standard
vocabularies for representing metadata and documentation, vocabularies for representing metadata and documentation,
respectively. Although these data model items are not used for respectively. Although these data model items are not used for
formal validation, they quite often carry important information for formal validation, they quite often carry important information for
data model implementers. Therefore, they SHOULD be included in the data model implementers. Therefore, they SHOULD be included in the
conceptual tree schema and MAY also appear in the final validation conceptual tree schema and MAY also appear in the final validation
schemas. schemas.
The third set are NETMOD-specific annotations conveying YANG semantic The third set are NETMOD-specific annotations conveying YANG semantic
constraints and other information that cannot be expressed natively constraints and other information that cannot be expressed natively
in RELAX NG. These annotations are only used in the first step of in RELAX NG. These annotations are only used in the first step of
the mapping, i.e., in the conceptual tree schema. In the second the mapping, i.e., in the conceptual tree schema. In the second
mapping step, these annotations are converted to Schematron and DSRL mapping step, these annotations are converted to Schematron and DSRL
rules. rules.
4.1. Dublin Core Metadata Elements 5.1. Dublin Core Metadata Elements
Dublin Core [24] is a system of metadata elements that was originally Dublin Core [2] is a system of metadata elements that was originally
created for describing metadata of World Wide Web resources in order created for describing metadata of World Wide Web resources in order
to facilitate their automated lookup. Later it was accepted as a to facilitate their automated lookup. Later it was accepted as a
standard for describing metadata of arbitrary resources. This standard for describing metadata of arbitrary resources. This
specification uses the definition from [9]. specification uses the definition from [RFC5013].
Dublin Core elements are qualified with namespace URI Dublin Core elements are qualified with namespace URI
"http://purl.org/dc/terms". "http://purl.org/dc/terms".
4.2. RELAX NG DTD Compatibility Annotations 5.2. RELAX NG DTD Compatibility Annotations
DTD compatibility annotations are part of the RELAX NG DTD DTD compatibility annotations are part of the RELAX NG DTD
Compatibility specification [8]. YANG-to-DSDL mapping uses only the Compatibility specification [RNG-DTD]. YANG-to-DSDL mapping uses
<a:documentation> annotation for representing YANG 'description' and only the <a:documentation> annotation for representing YANG
'reference' texts. 'description' and 'reference' texts.
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 interpreted by several RELAX they are well supported and adequately interpreted by several RELAX
NG tools. NG 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".
4.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 qualified
with the namespace URI with the namespace URI
"urn:ietf:params:xml:ns:netmod:dsdl-annotations:1" that appear in "urn:ietf:params:xml:ns:netmod:dsdl-annotations:1" that appear in
various locations in the conceptual tree schema. YANG statements are various locations in the conceptual tree schema. YANG statements are
mapped to these annotations in a very straightforward way. In most mapped to these annotations in a straightforward way. In most cases,
cases, the annotation attributes and elements always have the same the annotation attributes and elements always have the same name as
name as the corresponding YANG statement. the corresponding YANG statement.
Table 2 lists alphabetically the names of NETMOD-specific annotation Table 2 lists alphabetically the names of NETMOD-specific annotation
attributes (prefixed with "@") and elements (in angle brackets) along attributes (prefixed with "@") and elements (in angle brackets) along
with a reference to the section where their use is described. with a reference to the section where their use is described.
Appendix A then contains the RELAX NG schema of this annotation Appendix A contains the formal specification of this annotation
vocabulary. vocabulary.
+---------------------------+--------------------+------+ +---------------------------+--------------------+------+
| annotation | section | note | | annotation | section | note |
+---------------------------+--------------------+------+ +---------------------------+--------------------+------+
| @nma:config | 10.9 | | | @nma:config | 11.9 | |
| | | | | | | |
| @nma:default | 10.12 | | | @nma:default | 11.12 | |
| | | | | | | |
| @nma:implicit | 10.11, 10.7, 10.12 | | | @nma:implicit | 11.11, 11.7, 11.12 | |
| | | | | | | |
| <nma:error-app-tag> | 10.16 | 1 | | <nma:error-app-tag> | 11.16 | 1 |
| | | | | | | |
| <nma:error-message> | 10.17 | 1 | | <nma:error-message> | 11.17 | 1 |
| | | | | | | |
| <nma:instance-identifier> | 10.53.6 | 2 | | <nma:instance-identifier> | 11.53.6 | 2 |
| | | | | | | |
| @nma:key | 10.26 | | | @nma:key | 11.26 | |
| | | | | | | |
| @nma:leafref | 10.53.7 | | | @nma:leafref | 11.53.7 | |
| | | | | | | |
| @nma:min-elements | 10.28 | | | @nma:min-elements | 11.28 | |
| | | | | | | |
| @nma:max-elements | 10.28 | | | @nma:max-elements | 11.28 | |
| | | | | | | |
| <nma:must> | 10.35 | 3 | | <nma:must> | 11.35 | 3 |
| | | | | | | |
| @nma:ordered-by | 10.38 | | | @nma:ordered-by | 11.38 | |
| | | | | | | |
| @nma:presence | 10.45 | | | @nma:presence | 11.45 | |
| | | | | | | |
| @nma:status | 10.51 | | | @nma:status | 11.51 | |
| | | | | | | |
| @nma:unique | 10.55 | | | @nma:unique | 11.55 | |
| | | | | | | |
| @nma:units | 10.56 | | | @nma:units | 11.56 | |
| | | | | | | |
| @nma:when | 10.59 | | | @nma:when | 11.59 | |
+---------------------------+--------------------+------+ +---------------------------+--------------------+------+
Table 2: NETMOD-specific annotations Table 2: NETMOD-specific annotations
Notes: Notes:
1. Appears only as subelement of <nma:must>. 1. Appears only as subelement of <nma:must>.
2. Has an optional attribute @require-instance. 2. Has an optional attribute @require-instance.
3. Has a mandatory attribute @assert and two optional subelements 3. Has a mandatory attribute @assert and two optional subelements
<nma:error-app-tag> and <nma:error-message>. <nma:error-app-tag> and <nma:error-message>.
5. Overview of the Mapping 6. Overview of the Mapping
This section gives an overview of the YANG-to-DSDL mapping, its This section gives an overview of the YANG-to-DSDL mapping, its
inputs and outputs. Figure 1 presents an overall structure of the inputs and outputs. Figure 1 presents an overall structure of the
mapping: mapping:
+----------------+ +----------------+
| YANG module(s) | | YANG module(s) |
+----------------+ +----------------+
| |
|T |T
skipping to change at page 17, line 34 skipping to change at page 18, line 34
+---------+ +-----+ +-------+ +------+ +---------+ +-----+ +-------+ +------+
|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 a single RELAX NG schema for the conceptual tree (see to a single RELAX NG schema for the conceptual tree (see
Section 7.1). Constraints that cannot be expressed directly in Section 8.1). Constraints that cannot be expressed directly in
RELAX NG (list key definitions, 'must' statements etc.) and RELAX NG (list key definitions, 'must' statements etc.) and
various documentation texts are recorded in the schema as simple various documentation texts are recorded in the schema as simple
annotations belonging to special namespaces. annotations belonging to special namespaces.
2. In the second step, the conceptual tree schema is transformed in 2. In the second step, the conceptual tree schema is 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 just three simplest possibilities as context. Figure 1 shows just three simple possibilities as
examples. In the process, appropriate parts of the conceptual examples. In the process, appropriate parts of the conceptual
tree schema are extracted and specific annotations transformed to tree schema are extracted and specific annotations transformed to
equivalent, but usually more complex, Schematron patterns, DSRL equivalent, but usually more complex, Schematron patterns, DSRL
element maps etc. element maps etc.
3. As indicated in Figure 1, the second step of the mapping also 3. As indicated in Figure 1, the second step of the mapping also
uses a schema-independent library that contains common schema uses a schema-independent library that contains common schema
objects such as RELAX NG named pattern definitions. objects such as RELAX NG named pattern definitions.
An implementation of the mapping algorithm accepts one or more valid An implementation of the mapping algorithm accepts one or more valid
skipping to change at page 18, line 19 skipping to change at page 19, line 19
roots. In addition, the input modules may be further coupled by the roots. In addition, the input modules may be further coupled by the
'augment' statement in which one module augments the data tree of 'augment' statement in which one module augments the data tree of
another module. 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 module(s) imports (transitively). to all YANG modules that the module(s) imports (transitively).
The output of the first mapping step is an annotated RELAX NG schema The output of the first mapping step is an annotated RELAX NG schema
for the conceptual tree - a virtual XML document containing, in its for the conceptual tree - a virtual XML document containing, in its
different subtrees, the entire datastore, all RPC requests and different subtrees, the entire datastore, all RPC requests and
replies, and notifications defined by the input YANG modules. By replies, and notifications as defined by the input YANG modules. By
"virtual" we mean that such an XML document need not correspond to "virtual" we mean that such an XML document need not correspond to
the actual layout of the configuration database in a NETCONF agent, the actual layout of the configuration database in a NETCONF agent,
and will certainly never appear on the wire as the content of a and will certainly never appear on the wire as the content of a
NETCONF PDU. Hence, the RELAX NG schema for the conceptual tree is NETCONF PDU. Hence, the RELAX NG schema for the conceptual tree is
not intended for any direct validations but rather as a not intended for any direct validations but rather as a
representation of a particular data model expressed in RELAX NG and representation of a particular data model expressed in RELAX NG and
the common starting point for subsequent transformations that may the common starting point for subsequent transformations that may
produce practical validation schemas. The conceptual tree is further produce practical validation schemas. The conceptual tree is further
described in Section 7.1. described in Section 8.1.
Other information contained in input YANG modules, such as semantic Other information contained in input YANG modules, such as semantic
constraints or default values, are recorded in the conceptual tree constraints or default values, are recorded in the conceptual tree
schema as annotations - XML attributes or elements qualified with schema as annotations - XML attributes or elements qualified with
namespace URI "urn:ietf:params:xml:ns:netmod:dsdl-annotations:1". namespace URI "urn:ietf:params:xml:ns:netmod:dsdl-annotations:1".
Metadata describing the YANG modules are mapped to annotations Metadata describing the YANG modules are mapped to annotations
utilizing Dublin Core elements (Section 4.1). Finally, documentation utilizing Dublin Core elements (Section 5.1). Finally, documentation
strings are mapped to the <a:documentation> elements belonging to the strings are mapped to the <a:documentation> elements belonging to the
DTD compatibility vocabulary (Section 4.2). DTD compatibility vocabulary (Section 5.2).
The output from the second step is a coordinated set of three DSDL The output from 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 datatype
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 a specification of default content. o DSRL schema containing a specification of default content.
6. 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
mapping are supposed to be applied for validating XML instance mapping are supposed to be applied for validating XML instance
documents such as the content of a datastore or various NETCONF PDUs. documents such as the content of a datastore or various NETCONF PDUs.
The validation proceeds in the following steps, which are also The validation proceeds in the following steps, which are also
illustrated in Figure 2: illustrated in Figure 2:
1. The XML instance document can be immediately checked for 1. The XML instance document can be immediately checked for
grammatical and data type validity using the RELAX NG schema. grammatical and data type validity using the RELAX NG schema.
2. Second, the default values for leaves have to be applied and 2. Second, default values for leaf nodes have to be applied and
their ancestor containers added where necessary. It is important their ancestor containers added where necessary. It is important
to apply the defaults before the next validation step because to apply the defaults before the next validation step because
YANG specification [5] states that the data tree against which YANG specification [YANG] states that the data tree against which
XPath expressions are evaluated already has all defaults XPath expressions are evaluated already has all defaults
filled-in. Note that this step modifies the information set of filled-in. Note that this step modifies the information set of
the input XML document. the input XML document.
3. The semantic constraints are checked using the Schematron schema. 3. The semantic constraints are checked using the Schematron schema.
+----------+ +----------+ +----------+ +----------+
| | | XML | | | | XML |
| XML | | document | | XML | | document |
| document |-----------o----------->| with | | document |-----------o----------->| with |
skipping to change at page 20, line 5 skipping to change at page 21, line 5
| grammar, | defaults | semantic | grammar, | defaults | semantic
| datatypes | | constraints | datatypes | | 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
7. Design Considerations 8. Design Considerations
YANG modules could be mapped to DSDL schemas in a number of ways. YANG modules could in principle be mapped to DSDL schemas in a number
The mapping procedure described in this document uses several of ways. The mapping procedure described in this document uses
specific design decisions that are discussed in the following several specific design decisions that are discussed in the following
subsections. subsections.
7.1. Conceptual Data Tree 8.1. Conceptual Data Tree
DSDL schemas generated from YANG modules using the procedure DSDL schemas generated from YANG modules using the procedure
described in this document are intended to be used for validating described in this document are intended to be used for validating
XML-encoded NETCONF data in various forms: every YANG-based model XML-encoded NETCONF data in various forms: every YANG-based model
represents the contents of a datastore but also implies an array of represents the contents of a datastore but also implies an array of
schemas for all types of NETCONF PDUs. For a reasonably strict schemas for all types of NETCONF PDUs. For a reasonably strict
validation of a given data object, the schemas have to be quite validation of a given data object, the schemas have to be quite
specific. To begin with, effective validation of NETCONF PDU content specific. To begin with, effective validation of NETCONF PDU content
requires separation of client and server schemas. While the decision requires separation of client and server schemas. While the decision
about proper structuring of all PDU-validating schemas is beyond the about proper structuring of all PDU-validating schemas is beyond the
skipping to change at page 21, line 41 skipping to change at page 22, line 41
</nmt:notifications> </nmt:notifications>
</nmt:netmod> </nmt:netmod>
The namespace URI "urn:ietf:params:xml:ns:netmod:conceptual-tree:1" The namespace URI "urn:ietf:params:xml:ns:netmod:conceptual-tree:1"
identifies a simple vocabulary consisting of a few elements that identifies a simple vocabulary consisting of a few elements that
encapsulate and separate the various parts of the conceptual data encapsulate and separate the various parts of the conceptual data
tree. tree.
The conceptual tree schema is not intended for direct validation but The conceptual tree schema is not intended for direct validation but
rather serves as a well-defined starting point for subsequent rather serves as a well-defined starting point for subsequent
transformations that generate various validation schemas. Such transformations that generate validation schemas. In general, these
transformations should be relatively simple, they will typically transformations should be relatively simple - they will typically
extract one or several subtrees from the conceptual tree schema, extract one or more subtrees from the conceptual tree schema, modify
modify them as necessary and add encapsulating elements such as those them as necessary and add encapsulating elements such as those from
from the NETCONF RPC layer. the NETCONF RPC layer.
Additional information contained in the source YANG module(s), such Additional information contained in the source YANG module(s), such
as semantic constraints and default values, is represented in the as semantic constraints and default values, is represented in the
form of interim NETMOD-specific annotations that are included as form of interim NETMOD-specific annotations that are included as
foreign-namespace elements or attributes in the RELAX NG schema for foreign-namespace elements or attributes in the RELAX NG schema for
the conceptual tree. In the second phase of the mapping, these the conceptual tree. In the second phase of the mapping, these
annotations are translated to equivalent Schematron and DSRL rules. annotations are translated to equivalent Schematron and DSRL rules.
As a useful side effect, by introducing the conceptual data tree we As a useful side effect, by introducing the conceptual data tree we
are also able to resolve the difficulties arising from the fact that are also able to resolve the difficulties arising from the fact that
a single datastore may consist of multiple parallel data hierarchies a single datastore may consist of multiple parallel data hierarchies
defined in one or more YANG modules, which cannot be mapped to a defined in one or more YANG modules, which cannot be mapped to a
valid XML document. In the conceptual data tree, such multiple valid XML document. In the conceptual data tree, such multiple
hierarchies appear under the single <nmt:top> element. hierarchies appear under the single <nmt:top> element.
7.2. Modularity 8.2. Modularity
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 MIBs. The YANG assumes a large set of modules similar to SNMP MIBs. 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
namespace. In RELAX NG, the names of patterns are unqualified and module's namespace. In RELAX NG, the names of patterns are
so named patterns defined in both the importing and imported unqualified and so named patterns defined in both the importing
module share the same flat namespace. The contents of RELAX NG and imported module share the same flat namespace. The contents
named patterns may either keep the namespace of the schema where of RELAX NG named patterns may either keep the namespace of the
they are defined or inherit the namespace of the importing module, schema where they are defined or inherit the namespace of the
analogically to YANG. However, in order to achieve the latter importing module, analogically to YANG. However, in order to
behavior, the imported module must be prepared in a special way as achieve the latter behavior, the imported module must be prepared
a library module that cannot be used as a stand-alone schema. in a special way as a library module that cannot be used as a
stand-alone schema.
So the conclusion is that the modularity mechanisms of YANG and RELAX So the conclusion is that the modularity mechanisms of YANG and RELAX
NG, albeit similar, are not directly compatible. Therefore, the NG, albeit similar, are not directly compatible. Therefore, the
corresponding design decision for the mapping algorithm is to collect corresponding design decision for the mapping algorithm is to collect
all information in a single schema for the conceptual tree, even if all information in a single schema for the conceptual tree, even if
it comes from multiple YANG modules or submodules. In other words, it comes from multiple YANG modules or submodules. In other words,
translations of imported groupings and typedefs are installed in the translations of imported groupings and typedefs are installed in the
translation of importing module - but only if they are really used translation of importing module - but only if they are really used
there. there.
NOTE: The 'include' statement that is used in YANG for including NOTE: The 'include' statement that is used in YANG for including
submodules has in fact the same semantics as the <rng:include> submodules has in fact the same semantics as the <rng:include>
pattern. However, since we don't map the modular structure for YANG pattern. However, since we don't map the modular structure for YANG
modules, it seems to have little sense to do it for submodules. modules, it seems to have little sense to do it for submodules.
Consequently, the contents of submodules appear directly in the Consequently, the contents of submodules appear directly in the
conceptual tree schema, too. conceptual tree schema, too.
7.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 is introduced inside a new named schema language - every XML element corresponds to a named pattern
pattern. 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 that's closer to the "Russian Doll" modules are organized in a way that's closer to the "Russian Doll"
style, which provides a better insight into the structure of the style, 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
skipping to change at page 23, line 38 skipping to change at page 24, line 39
YANG this is not an issue since its 'augment' and 'refine' statements YANG this is not an issue since its 'augment' and 'refine' statements
can delve, by using path expressions, into arbitrary depths of can delve, by using path expressions, into arbitrary depths of
existing structures. existing structures.
In general, it not feasible to map YANG extension mechanisms to those In general, it not feasible to map YANG extension mechanisms to those
of RELAX NG. For this reason, the mapping essentially keeps the of RELAX NG. For this reason, the mapping essentially keeps the
granularity of the original YANG data model: definitions of named granularity of the original YANG data model: definitions of named
patterns in the resulting RELAX NG schema usually have direct patterns in the resulting RELAX NG schema usually have direct
counterparts in YANG groupings and definitions of derived types. counterparts in YANG groupings and definitions of derived types.
7.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, which
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 YANG-to-DSDL mapping allows for multiple input YANG
modules that naturally leads to compound document schemas. modules that 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.
2. One of the target namespace URIs may be declared using the @ns 2. One of the target namespace URIs may be declared using the @ns
attribute. attribute.
skipping to change at page 24, line 25 skipping to change at page 25, line 25
prefixes declared in the input modules are recorded in the resulting prefixes declared in the input modules are recorded in the resulting
schema - the prefix for the namespace declared using @ns would be schema - the prefix for the namespace declared using @ns would be
lost. lost.
DSRL schemas can declare any number of target namespaces via the DSRL schemas can declare any number of target namespaces via the
standard XML attributes xmlns:xxx. standard XML attributes xmlns:xxx.
In contrast, Schematron requires all the target namespaces to be In contrast, Schematron requires all the target namespaces to be
defined in the <sch:ns> subelements of the root <sch:schema> element. defined in the <sch:ns> subelements of the root <sch:schema> element.
7.5. Features and Deviations 8.5. Features and Deviations
YANG provides statements that allow for marking parts of the schema YANG provides statements that allow for marking parts of the schema
as conditional ('feature' and 'if-feature' statements) or declaring as conditional ('feature' and 'if-feature' statements) or declaring
deviations from a data model ('deviation' statement). These deviations from a data model ('deviation' statement). These
statements are not handled by the YANG-to-DSDL mapping. It is statements are not handled by the YANG-to-DSDL mapping. Instead, it
assumed that all features and deviations are specified beforehand and is assumed that all features and deviations are specified beforehand
the corresponding changes in the input YANG modules are already and the corresponding changes in the input YANG modules are already
applied. applied.
8. Mapping YANG Data Models to the Conceptual Tree Schema 9. Mapping YANG Data Models to the Conceptual Tree Schema
This section explains the main principles underlying the first step This section explains the main principles underlying the first step
of the mapping. Its result is an annotated RELAX NG schema of the of the mapping. Its result is an annotated RELAX NG schema of the
conceptual tree, which is described in Section 7.1. conceptual tree, which is described in Section 8.1.
As a special case, if the input YANG modules contain no data nodes As a special case, if the input YANG modules contain no data nodes
(this is typical, e.g., for datatype library modules), an (this is typical, e.g., for datatype library modules), an
implementation MAY entirely remove the schema of the (empty) implementation MAY entirely remove the schema of the (empty)
conceptual tree - the <rng:start> element with all its contents. The conceptual tree - the <rng:start> element with all its contents. The
output RELAX NG schema will then contain only named pattern output RELAX NG schema will then contain only named pattern
definitions translated from YANG groupings and typedefs. definitions translated from YANG groupings and typedefs.
Detailed specification of the mapping of individual YANG statements Detailed specification of the mapping of individual YANG statements
is contained in Section 10. is contained in Section 11.
8.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 RELAX NG, for example, always localized together with that node. In RELAX NG, for example,
<rng:optional> pattern always appears as the parent element of the <rng:optional> pattern appears as the parent element of the pattern
pattern defining the node in the schema. Similarly, DSRL specifies defining the node in the schema, be it a leaf or container node.
default content separately for every single node, be it a leaf or Similarly, DSRL specifies default content separately for every single
non-leaf element. node, be it a leaf or non-leaf element.
In contrast, for a YANG container it is often necessary to examine For leaf nodes in YANG modules, the occurrence constraints are also
the entire subtree under that container in order to determine the easily inferred from the substatements of 'leaf'. In contrast, for a
container's occurrence constraints. YANG container it is often necessary to examine its entire subtree in
order to determine the container's occurrence constraints.
Therefore, one of the goals of the first mapping step is to infer the Therefore, one of the goals of the first mapping step is to infer the
occurrence constraints for all containers and mark accordingly the occurrence constraints for all containers and mark accordingly the
corresponding <rng:element> patterns in the conceptual tree schema so corresponding <rng:element> patterns in the conceptual tree schema so
that all transformation procedures in the second mapping step can that any transformation procedure in the second mapping step can
simply use this information and need not examine the subtree again. simply use this information and need not examine the subtree again.
The following two occurrence characteristics have to be determined First, it has to be decided whether a given container element must
for every container: always be present in a valid configuration. If so, such a container
element is called mandatory, otherwise it is called optional. This
1. optional/mandatory - mandatory containers must exist in a valid constraint is very closely related to the notion of mandatory nodes
instance document while optional ones may be omitted; in Section 3.1 in [YANG]. The only difference is that we also
consider list keys to be mandatory.
2. implicit - an implicit container is added to the instance The other occurrence constraint has to do with the semantics of the
document in the process of substituting defaults for missing leaf 'default' statement and the possibility of removing empty non-
values. presence containers. As a result, the information set of a valid
configuration may be modified by adding or removing certain leaf or
container elements without changing the meaning of the configuration.
Both characteristics apply to containers at the top level of the data Such elements are called implicit.
tree, and then also to other containers under the additional
condition that their parent node exists in the instance document.
For example, consider the following YANG fragment: Note that both occurrence constraints apply to containers at the top
level of the data tree, and then also to other containers under the
additional condition that their parent node exists in the instance
document. For example, consider the following YANG fragment:
container outer { container outer {
presence 'Presence of "outer" means something.'; presence 'Presence of "outer" means something.';
container c1 { container c1 {
leaf foo { leaf foo {
type uint8; type uint8;
default 1; default 1;
} }
} }
container c2 { container c2 {
skipping to change at page 26, line 39 skipping to change at page 27, line 44
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 their description, it is useful to define these order to simplify the recursive definition of these occurrence
occurrence characteristics for other types of nodes - leaf, list, characteristics, it is useful to define them for other types of nodes
leaf-list and anyxml. as well, i.e., leaf, list, leaf-list and anyxml.
8.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, see Section 3.1 in [5]: 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 that
at least one node from exactly one case branch must exist. at least one node from exactly one case branch must exist.
o In addition, leaf nodes are mandatory if they are declared as list o In addition, leaf nodes are mandatory if they are declared as list
keys. keys.
o List or leaf-list nodes are mandatory if they contain 'min- o List or leaf-list nodes are mandatory if they contain 'min-
elements' substatement with argument value greater than zero. elements' substatement with 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 is optional if it is not mandatory. A node is optional iff it is not mandatory.
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 explicitly wrapped in the <rng:optional> element. The mapping MUST
algorithm thus uses the above rules to determine whether a YANG node use the above rules to determine whether a YANG node is optional and
is optional and if so, inserts the <rng:optional> element in the if so, insert the <rng:optional> element in the conceptual tree
conceptual tree schema. schema.
However, alternatives in <rng:choice> are never defined as optional However, alternatives in <rng:choice> are never defined as optional
in the conceptual tree schema. Therefore, 'anyxml', 'container', in the conceptual tree schema. Therefore, 'anyxml', 'container',
'leaf', 'list' and 'leaf-list' statements appearing as children of 'leaf', 'list' and 'leaf-list' statements appearing as children of
'choice' (shorthand cases) are always mapped to mandatory RELAX NG 'choice' (shorthand cases) are always mapped to mandatory RELAX NG
patterns. If a choice in YANG is not mandatory, <rng:optional> is patterns. If a choice in YANG is not mandatory, <rng:optional> is
used to wrap the entire <rng:choice> pattern. used to wrap the entire <rng:choice> pattern.
8.1.2. Implicit Nodes 9.1.2. Implicit Nodes
The following rules are used to determine whether a given node is The following rules are used to determine whether a given node is
implicit: 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 specified default o A leaf node is implicit if and only if it has a specified default
value (either directly or via its datatype). value (either directly or via its datatype).
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 is mandatory and at 'presence' substatement, none of its children is mandatory and at
least one child is implicit. least one child is implicit.
o As an exception to the above two rules, a leaf or container node o As an exception to the above two rules, a leaf or container node
appearing inside a case of a choice can be implicit only if that appearing inside a case of a choice can be implicit only if that
case is declared as default by using the 'default' statement, see case is declared as default by using the 'default' statement, see
Section 7.9.3 in [5]. Section 7.9.3 in [YANG].
In the conceptual tree schema, all implicit containers MUST be marked In the conceptual tree schema, all implicit containers MUST be marked
with @nma:implicit attribute with the value "true". In addition, the with @nma:implicit attribute with the value "true". In addition, the
default case in a choice (if defined by the 'default' substatement of default case in a choice (defined by the 'default' substatement of
'choice') MUST be also marked in the same way, i.e., by @nma:implicit 'choice') MUST be also marked in the same way, i.e., by @nma:implicit
set to "true". set to "true".
8.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 [5]. Moreover, top-level symbols from external modules are 5.5 in [YANG]. Moreover, top-level symbols from external modules are
imported as qualified names represented using the external module imported as qualified names represented using the external module
namespace prefix and the name of the symbol. In contrast, named namespace prefix and the name of the symbol. In contrast, named
patterns in RELAX NG (both local and imported via the <rng:include> patterns in RELAX NG (both local and imported via the <rng:include>
pattern) share the same namespace and within a grammar they are pattern) share the same namespace and within a grammar they are
always global - their definitions may only appear at the top level as always global - their definitions may only appear at the top level as
children of the <rng:grammar> element. Consequently, whenever YANG children of the <rng:grammar> element. Consequently, whenever YANG
groupings and typedefs are mapped to RELAX NG named pattern groupings and typedefs are mapped to RELAX NG named pattern
definitions, their names MUST be disambiguated in order to avoid definitions, their names MUST be disambiguated in order to avoid
naming conflicts. The mapping uses the following procedure for 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:
skipping to change at page 28, line 39 skipping to change at page 29, line 44
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 Since the names of groupings and typedefs in YANG have different o Since the names of groupings and typedefs in YANG have different
namespaces, an additional underline character is added to the namespaces, an additional underline character is added to the
beginning of the mangled names of all groupings. beginning of the mangled names of all groupings.
For example, consider the following YANG module which imports the EXAMPLE. Consider the following YANG module which imports the
standard module "inet-types" [20]: standard module "ietf-inet-types" [Ytypes]:
module example1 { module example1 {
namespace "http://example.com/ns/example1"; namespace "http://example.com/ns/example1";
prefix ex1; prefix ex1;
import "inet-types" { import "ietf-inet-types" {
prefix "inet"; prefix "inet";
} }
typedef vowels { typedef vowels {
type string { type string {
pattern "[aeiouy]*"; pattern "[aeiouy]*";
} }
} }
grouping "grp1" { grouping "grp1" {
leaf "void" { leaf "void" {
type "empty"; type "empty";
skipping to change at page 30, line 22 skipping to change at page 31, line 22
<rng:optional> <rng:optional>
<rng:element name="ex1:void"> <rng:element name="ex1:void">
<rng:empty/> <rng:empty/>
</rng:element> </rng:element>
</rng:optional> </rng:optional>
</rng:define> </rng:define>
<rng:define name="_example1__cont__grp2"> <rng:define name="_example1__cont__grp2">
<rng:optional> <rng:optional>
<rng:element name="ex1:address"> <rng:element name="ex1:address">
<rng:ref name="inet-types__ip-address"/> <rng:ref name="ietf-inet-types__ip-address"/>
</rng:element> </rng:element>
</rng:optional> </rng:optional>
</rng:define> </rng:define>
<rng:define name="inet-types__ip-address"> <rng:define name="ietf-inet-types__ip-address">
<rng:choice> <rng:choice>
<rng:ref name="inet-types__ipv4-address"/> <rng:ref name="ietf-inet-types__ipv4-address"/>
<rng:ref name="inet-types__ipv6-address"/> <rng:ref name="ietf-inet-types__ipv6-address"/>
</rng:choice> </rng:choice>
</rng:define> </rng:define>
<rng:define name="inet-types__ipv4-address"> <rng:define name="ietf-inet-types__ipv4-address">
<rng:data type="string"> <rng:data type="string">
<rng:param name="pattern">... regex pattern ...</param> <rng:param name="pattern">... regex pattern ...</param>
</rng:data> </rng:data>
</rng:define> </rng:define>
<rng:define name="inet-types__ipv6-address"> <rng:define name="ietf-inet-types__ipv6-address">
<rng:data type="string"> <rng:data type="string">
<rng:param name="pattern">... regex pattern ...</param> <rng:param name="pattern">... regex pattern ...</param>
</rng:data> </rng:data>
</rng:define> </rng:define>
8.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 allows for modifying themselves are modified whereas YANG allows for modifying
_expansions_ of groupings. Specifically, YANG provides two _expansions_ of groupings. Specifically, YANG provides two
statements for this purpose that may appear as substatements of statements for this purpose that may appear as substatements of
'uses': 'uses':
o 'refine' statement allows for changing parameters of a schema node o 'refine' statement allows for changing parameters of a schema node
inside the grouping referenced by the parent 'uses' statement; inside the grouping referenced by the parent 'uses' statement;
o 'augment' statement can be used for adding new schema nodes to the o 'augment' statement can be used for adding new schema nodes to the
grouping content. grouping content.
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 arguments, schema they can address, using XPath-like expressions as arguments, schema
nodes that are arbitrarily deep inside the grouping content. In nodes that are arbitrarily deep inside the grouping content. In
contrast, definitions of named patterns in RELAX NG operate contrast, modifications of named pattern definitions in RELAX NG are
exclusively at the topmost level of the named pattern content. In applied exclusively at the topmost level of the named pattern
order to achieve a modifiability of named patterns comparable to content. In order to achieve a modifiability of named patterns
YANG, the RELAX NG schema would have to be extremely flat (cf. comparable to YANG, the RELAX NG schema would have to be extremely
Section 7.3) and very difficult to read. flat (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 which has 'refine'
and/or 'augment' substatements is virtually replaced by the content and/or 'augment' substatements is replaced by the content of the
of the corresponding grouping, the changes specified in the 'refine' corresponding grouping, the changes specified in the 'refine' and
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 content, If there are further 'uses' statements inside the grouping content,
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 33, line 13 skipping to change at page 34, line 13
<rng:ref name="_example2__leaves"/> <rng:ref name="_example2__leaves"/>
Now assume that the "uses leaves" statement is refined: Now assume that the "uses leaves" statement is refined:
uses leaves { uses leaves {
refine "hoja" { refine "hoja" {
default "alamo"; default "alamo";
} }
} }
The resulting conceptual tree schema now contains just one named The resulting conceptual tree schema now contains just one named
pattern definition - "_example__fr". The other two groupings pattern definition - "_example2__fr". The other two groupings
"leaves" and "es" have to be expanded because they both lie on the "leaves" and "es" have to be expanded because they both lie on the
"modification path", i.e., contain the leaf "hoja" that is being "modification path", i.e., contain the leaf "hoja" that is being
refined. The configuration data part of the conceptual tree now refined. The configuration data part of the conceptual tree now
looks like this: looks like this:
<rng:ref name="_example2__fr"/> <rng:ref name="_example2__fr"/>
<rng:optional> <rng:optional>
<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>
8.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,
where a base built-in type may be modified (in multiple steps) by where a ancestor built-in type may be modified (perhaps in multiple
adding new restrictions. Therefore, when mapping YANG derived types steps) by adding new restrictions. Therefore, when mapping YANG
with restrictions, the derived types MUST be "unwound" all the way derived types with restrictions, the derived types MUST be "unwound"
back to the base built-in type. At the same time, all restrictions all the way back to the ancestor built-in type. At the same time,
found along the type derivation chain MUST be combined and their all restrictions found along the type derivation chain MUST be
intersection used as facets restricting the corresponding type in combined and their intersection used as facets restricting the
RELAX NG. corresponding type in RELAX NG.
When a derived YANG type is used without restrictions, the 'type' When a derived YANG type is used without restrictions - as a
substatement of either 'leaf' or another 'typedef' - the 'type'
statement is mapped simply to the <rng:ref> element, i.e., a named statement is mapped simply to the <rng:ref> element, i.e., a named
pattern reference. However, if restrictions are specified as pattern reference. However, if restrictions are specified as
substatements of the 'type' statement, the type MUST be expanded at substatements of the 'type' statement, the type definition MUST be
that point so that only the base built-in type appears in the output expanded at that point so that only the ancestor built-in type
schema, restricted with facets that again correspond to the appears in the output schema, restricted with facets that again
combination of all restrictions found along the type derivation chain correspond to the combination of all restrictions found along the
and also in the 'type' statement. 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";
prefix ex3; prefix ex3;
typedef dozen { typedef dozen {
type uint8 { type uint8 {
range 1..12; range 1..12;
} }
} }
leaf month { leaf month {
type dozen; type dozen;
} }
The 'type' statement in "leaf month" is mapped simply to the The 'type' statement in "leaf month" is mapped simply to the
reference <rng:ref name="example__dozen"/> and the corresponding reference <rng:ref name="example3__dozen"/> and the corresponding
named pattern is defined as follows: named pattern is 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</param> <rng:param name="minInclusive">1</param>
<rng:param name="maxInclusive">12</param> <rng:param name="maxInclusive">12</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
skipping to change at page 34, line 46 skipping to change at page 35, line 46
The output RELAX NG schema then won't contain any named pattern The output RELAX NG schema then won't contain any named pattern
definition and leaf "month" will be mapped directly to definition and 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</param> <rng:param name="minInclusive">7</param>
<rng:param name="maxInclusive">12</param> <rng:param name="maxInclusive">12</param>
</rng:data> </rng:data>
</rng:element> </rng:element>
8.3. Translation of XPath Expressions The mapping of type derivation chains may be further complicated by
the presence of the 'default' statement in type definitions. In the
simple case, when a type definition containing the 'default'
statement is used without restrictions, the 'default' statement is
mapped to the @nma:default attribute attached to the <rng:define>
element.
YANG uses full XPath 1.0 syntax [18] for the arguments of 'must', However, if that type definition has to be expanded, the @nma:default
annotation arising from the expanded type or ancestor types in the
type derivation chain MUST be attached to the element where the
expansion occurs. If there are multiple 'default' statements in
consecutive steps of the type derivation, only the 'default'
statement that is closest to the expanded type is used.
EXAMPLE. Consider this variation of the last example:
module example3bis {
namespace "http://example.com/ns/example3bis";
prefix ex3bis;
typedef dozen {
type uint8 {
range 1..12;
}
default 7;
}
leaf month {
type dozen;
}
The 'typedef' statement in this module is mapped to the following
named pattern definition:
<rng:define name="example3bis__dozen" @nma:default="7">
<rng:data type="unsignedByte">
<rng:param name="minInclusive">1</param>
<rng:param name="maxInclusive">12</param>
</rng:data>
</rng:define>
If the "dozen" type is restricted when used in the leaf "month"
definition as in the previous example, the "dozen" type has to be
expanded and @nma:default becomes an attribute of the <ex3bis:month>
element definition:
<rng:element name="ex3bis:month" @nma:default="7">
<rng:data type="unsignedByte">
<rng:param name="minInclusive">7</param>
<rng:param name="maxInclusive">12</param>
</rng:data>
</rng:element>
However, if the definition of leaf "month" itself contained the
'default' substatement, the default specified for the "dozen" type
will be ignored.
9.3. Translation of XPath Expressions
YANG uses full XPath 1.0 syntax [XPath] for the arguments of 'must',
'when' and 'path' statements. However, since the names of data nodes 'when' and 'path' statements. However, since the names of data nodes
defined in a YANG module always belong to the namespace of that YANG defined in a YANG module always belong to the namespace of that YANG
module, YANG adopted a simplification similar to the concept of module, YANG adopted a simplification similar to the concept of
_default namespace_ in XPath 2.0: node names needn't carry a _default namespace_ in XPath 2.0: node names needn't carry a
namespace prefix inside the module where they are defined, in which namespace prefix inside the module where they are defined, in which
case the module's namespace is assumed. case the module's namespace is assumed.
If an XPath expression is carried over to a NETMOD-specific If an XPath expression is carried over to a NETMOD-specific
annotation in the conceptual tree schema, it MUST be translated into annotation in the conceptual tree schema, it MUST be translated into
a fully conformant XPath 1.0 expression that also reflects the a fully conformant XPath 1.0 expression that also reflects the
hierarchy of the conceptual data tree: hierarchy of the conceptual data tree:
1. Each unprefixed node name MUST be prepended with the local 1. Each unprefixed node name MUST be prepended with the local
module's namespace prefix declared by the 'prefix' statement. module's namespace prefix declared by the 'prefix' statement.
2. Absolute XPath expressions, i.e., those starting with a slash, 2. Absolute XPath expressions, i.e., those starting with a slash,
MUST be prepended with appropriate path in the conceptual tree, MUST be prepended with appropriate path in the conceptual tree,
according to the YANG specification of context for XPath according to the YANG specification of context for XPath
expressions, see [5], sections 7.5.3 and 7.19.5 in [5]. expressions, see [YANG], sections 7.5.3 and 7.19.5 in [YANG].
Translation rule 2 means for example that absolute XPath expressions Translation rule 2 means for example that absolute XPath expressions
appearing in the main configuration data tree always start with "nmt: appearing in the main configuration data tree always start with "nmt:
netmod-tree/nmt:top/", those appearing in a notification always start netmod-tree/nmt:top/", those appearing in a notification always start
with "nmt:netmod-tree/nmt:notifications/nmt:notification/", etc. with "nmt:netmod-tree/nmt:notifications/nmt:notification/", etc.
EXAMPLE. YANG XPath expression "/dhcp/max-lease-time" appearing in EXAMPLE. YANG XPath expression "/dhcp/max-lease-time" appearing in
the main configuration data will be translated to "nmt:netmod-tree/ the main configuration data will be translated to "nmt:netmod-tree/
nmt:top/dhcp:dhcp/dhcp:max-lease-time". nmt:top/dhcp:dhcp/dhcp:max-lease-time".
The key identifiers and "descendant schema node identifiers" (see the The key identifiers and "descendant schema node identifiers" (see the
ABNF production for and "descendant-schema-nodeid" in Section 12 of ABNF production for and "descendant-schema-nodeid" in Section 12 of
[5]) are not XPath expressions but SHOULD be translated by adding [YANG]) are not XPath expressions but SHOULD be translated by adding
local module prefixes as well. local module prefixes as well.
8.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
can be used as the native statements, only with a namespace prefix can be used as the native statements, only with a namespace prefix
qualifying the extension keyword. RELAX NG has a similar extension qualifying the extension keyword. RELAX NG has a similar extension
mechanism - XML elements and attributes with names from foreign mechanism - XML elements and attributes with names from foreign
namespaces may be inserted at almost every place of a RELAX NG namespaces may be inserted at almost every place of a RELAX NG
schema. schema.
skipping to change at page 37, line 5 skipping to change at page 39, line 5
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.
9. Mapping Conceptual Tree Schema to DSDL 10. Mapping Conceptual Tree Schema to DSDL
As explained in Section 5, the second step of the YANG-to-DSDL As explained in Section 6, the second step of the YANG-to-DSDL
mapping takes the conceptual tree schema and transforms it to various mapping takes the conceptual tree schema and transforms it to various
DSDL schemas ready for validation. As an input parameter, this step DSDL schemas ready for validation. As an input parameter, this step
gets in the simplest case a specification of the NETCONF XML document gets in the simplest case a specification of the NETCONF XML document
type (or combination of multiple types) that is to be validated. type (or combination of multiple types) that is to be validated.
These document type can be, for example, the content of a datastore, These document type can be, for example, the content of a datastore,
reply to <nc:get> or <nc:get-config>, other RPC requests or replies reply to <nc:get> or <nc:get-config>, other RPC requests or replies
and notifications. and notifications.
In general, the second mapping step has to accomplish the following In general, the second mapping step has to accomplish the following
three tasks: three tasks:
skipping to change at page 37, line 35 skipping to change at page 39, line 35
elements mandated by the RPC layer. These are, for example, <nc: elements mandated by the RPC layer. These are, for example, <nc:
rpc> and <nc:data> elements in the case of a datastore or <en: rpc> and <nc:data> elements in the case of a datastore or <en:
notification> for a notification. notification> for a notification.
3. Finally, NETMOD-specific annotations that are relevant for the 3. Finally, NETMOD-specific annotations that are relevant for the
schema language of the generated schema must be mapped to schema language of the generated schema must be mapped to
corresponding schema-language-specific rules. corresponding schema-language-specific rules.
These three tasks are together much simpler than the first mapping These three tasks are together much simpler than the first mapping
step. Presumably, they can be effectively realized using XSL step. Presumably, they can be effectively realized using XSL
transformations [19]. transformations [XSLT].
The following subsections describe the details of the second mapping The following subsections describe the details of the second mapping
step for the individual DSDL schema languages. Section 11 then step for the individual DSDL schema languages. Section 12 then
contains a detailed specification for the mapping of all NETMOD- contains a detailed specification for the mapping of all NETMOD-
specific annotations. specific annotations.
9.1. Generating RELAX NG Schemas for Various Document Types 10.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 conceptual tree schema really means only taking appropriate parts the conceptual tree schema really means only taking appropriate parts
from the conceptual tree schema and assembling them in a new RELAX NG from the conceptual tree schema and assembling them in a new RELAX NG
grammar, perhaps after removing all unwanted annotations. Depending grammar, perhaps after removing all unwanted annotations. Depending
on the XML document type that is the target for validation (<get>/ on the XML document type that is the target for validation (<get>/
<get-config> reply, RPC or notification) a corresponding top-level <get-config> reply, RPC or notification) a corresponding top-level
part of the grammar MUST be added as described in the following part of the grammar MUST be added as described in the following
subsections. subsections.
skipping to change at page 38, line 18 skipping to change at page 40, line 18
In order to avoid copying identical named pattern definitions to the In order to avoid copying identical named pattern definitions to the
output RELAX NG file, these schema-independent definitions SHOULD be output RELAX NG file, these schema-independent definitions SHOULD be
collected in a library file which is then included by the validating collected in a library file which is then included by the validating
RELAX NG schemas. Appendix B has the listing of this library file. RELAX NG schemas. Appendix B has the listing of this 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 <get-config> which must be observed if the target document type is <get-config>
reply. In this case, each element definition that has this attribute reply. In this case, each element definition that has this attribute
with the value "false" MUST be removed from the schema together with with the value "false" MUST be removed from the schema together with
its descendants. See Section 11.1 for more details. its descendants. See Section 12.1 for more details.
9.1.1. Reply to <get> or <get-config> 10.1.1. Reply to <get> or <get-config>
For a reply to <get> or <get-config>, the mapping must take the part For a reply to <get> or <get-config>, the mapping must take the part
of the conceptual tree schema under the definition of <nmt:top> and of the conceptual tree schema under the definition of <nmt:top> and
insert it in the following grammar: insert it in the following grammar:
<rng:grammar ... namespaces etc. ...> <rng:grammar ... namespaces etc. ...>
<rng:include href="relaxng-lib.rng"/> <rng:include href="relaxng-lib.rng"/>
<rng:start> <rng:start>
<rng:element name="nc:rpc-reply"> <rng:element name="nc:rpc-reply">
<rng:ref name="message-id-attribute"/> <rng:ref name="message-id-attribute"/>
skipping to change at page 38, line 48 skipping to change at page 40, line 48
The definition for the named pattern "message-id-attribute" is found The definition for the named pattern "message-id-attribute" is found
in the library file "relaxng-lib.rng" which is included on the second in the library file "relaxng-lib.rng" which is included on the second
line (see Appendix B). line (see Appendix B).
Definitions of other named patterns MUST be copied from the Definitions of other named patterns MUST be copied from the
conceptual tree schema without any changes to the resulting grammar. conceptual tree schema without any changes to the resulting grammar.
However, an implementation MAY choose to copy only those definitions However, an implementation MAY choose to copy only those definitions
that are really used in the particular output grammar. that are really used in the particular output grammar.
9.1.2. Remote Procedure Calls 10.1.2. Remote Procedure Calls
For an RPC method named "myrpc" and defined in a YANG module with For an RPC method named "myrpc" and defined in a YANG module with
prefix "yam", the corresponding schema subtree is identified by the prefix "yam", the corresponding schema subtree is identified by the
definition of <nmt:rpc-method> element whose <nmt:input> subelement definition of <nmt:rpc-method> element whose <nmt:input> subelement
has <yam:myrpc> as the only child. has <yam:myrpc> as the only child.
The mapping must also take into account whether the target document The mapping must also take into account whether the target document
type is an RPC request or reply. For "yam:myrpc" request, the type is an RPC request or reply. For "yam:myrpc" request, the
resulting grammar looks as follows: resulting grammar looks as follows:
skipping to change at page 39, line 42 skipping to change at page 41, line 42
... "nmt:rpc-method/nmt:output" subtree ... ... "nmt:rpc-method/nmt:output" subtree ...
</rng:element> </rng:element>
</rng:start> </rng:start>
... named pattern definitions ... ... named pattern definitions ...
</rng:grammar> </rng:grammar>
In both cases, exact copies of named pattern definitions from the In both cases, exact copies of named pattern definitions from the
conceptual tree schema MUST be inserted, but an implementation MAY conceptual tree schema MUST be inserted, but an implementation MAY
choose to include only those used for the given RPC. choose to include only those used for the given RPC.
9.1.3. Notifications 10.1.3. Notifications
For a notification named "mynotif" and defined in a YANG module with For a notification named "mynotif" and defined in a YANG module with
prefix "yam", the corresponding schema subtree is identified by the prefix "yam", the corresponding schema subtree is identified by the
definition of <nmt:notification> element that has the single child definition of <nmt:notification> element that has the single child
<yam:mynotif>. <yam:mynotif>.
The resulting grammar looks as follows: The resulting grammar looks as follows:
<rng:grammar ... namespaces etc. ...> <rng:grammar ... namespaces etc. ...>
<rng:include href="relaxng-lib.rng"/> <rng:include href="relaxng-lib.rng"/>
<rng:start> <rng:start>
<rng:element name="en:notification"> <rng:element name="en:notification">
<rng:ref name="eventTime-element"/> <rng:ref name="eventTime-element"/>
<rng:element name="yam:myrpc"> <rng:element name="yam:mynotif">
<!-- patterns defining contents of <!-- patterns defining contents of
"nmt:rpc-notification/yam:mynotif" subtree --> "nmt:rpc-notification/yam:mynotif" subtree -->
</rng:element> </rng:element>
</rng:element> </rng:element>
</rng:start> </rng:start>
<!-- named pattern definitions --> <!-- named pattern definitions -->
</rng:grammar> </rng:grammar>
The definition of the named pattern "eventTime-element" is found in The definition of the named pattern "eventTime-element" is found in
the "relaxng-lib.rng" library file. the "relaxng-lib.rng" library file, see Appendix B.
Again, exact copies of named pattern definitions from the conceptual Again, exact copies of named pattern definitions from the conceptual
tree schema MUST be inserted, but an implementation MAY choose to tree schema MUST be inserted, but an implementation MAY choose to
include only those used for the given notification. include only those used for the given notification.
9.2. Mapping Semantic Constraints to Schematron 10.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. Every rule corresponds to exactly one element definition element. Every rule corresponds to exactly one element definition
pattern in the conceptual tree schema: pattern in the conceptual tree schema:
skipping to change at page 41, line 8 skipping to change at page 43, line 8
elements, @nma:max-elements, <nma:must>, @nma:unique and <nma:when>. elements, @nma:max-elements, <nma:must>, @nma:unique and <nma:when>.
In the opposite direction, however, not every element definition In the opposite direction, however, not every element definition
pattern in the conceptual tree schema has a corresponding rule in the pattern in the conceptual tree schema has a corresponding rule in the
Schematron schema: definitions of elements the carry none of the Schematron schema: definitions of elements the carry none of the
above annotations are omitted. above annotations are omitted.
Schematron rules may be further grouped into _patterns_ represented Schematron rules may be further grouped into _patterns_ represented
by the <sch:pattern> element. The mapping uses patterns only for by the <sch:pattern> element. The mapping uses patterns only for
discriminating between subsets of rules that belong to different discriminating between subsets of rules that belong to different
validation phases, see Section 9.2.1. Therefore, the <sch:schema> validation phases, see Section 10.2.1. Therefore, the <sch:schema>
always has exactly two <sch:pattern> children: one named "standard" always has exactly two <sch:pattern> children: one named "standard"
contains rules for all annotations except <nma:instance-identifier> contains rules for all annotations except <nma:instance-identifier>
and @nma:leafref, and another named "ref-integrity" containing rules and @nma:leafref, and another named "ref-integrity" containing rules
for these two remaining annotations, i.e., referential integrity for these two remaining annotations, i.e., referential integrity
checks. checks.
Element definitions in the conceptual tree schema that appear inside Element definitions in the conceptual tree schema that appear inside
a named pattern definition (i.e., have <rng:define> among its a named pattern definition (i.e., have <rng:define> among its
ancestors) are subject to a different treatment. This is because ancestors) are subject to a different treatment. This is because
their path in the data tree is not fixed - the named pattern may be their path in the data tree is not fixed - the named pattern may be
referred to in multiple different places. The mapping uses referred to in multiple different places. The mapping uses
Schematron _abstract rules_ to handle this case: An element Schematron _abstract rules_ to handle this case: An element
definition inside a named pattern is mapped to an abstract rule and definition inside a named pattern is mapped to an abstract rule and
every use of the named pattern then extends (uses) this abstract rule every use of the named pattern then extends (uses) this abstract rule
in the concrete context. in the concrete context.
EXAMPLE. Consider this element definition annotated with <nma:must>: EXAMPLE. Consider this element pattern annotated with <nma:must>:
<rng:element name="dhcp:default-lease-time"> <rng:element name="dhcp:default-lease-time">
<rng:data type="unsignedInt"/> <rng:data type="unsignedInt"/>
<nma:must assert=". &lt;= ../dhcp:max-lease-time"> <nma:must assert=". &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>
</rng:element> </rng:element>
If this element definition appears outside any named pattern and as a If this element pattern appears outside any named pattern and as a
child of <dhcp:dhcp> (as it does in the DHCP schema, see child of <dhcp:dhcp> (as it does in the DHCP schema, see
Appendix C.2), it is mapped to the following Schematron rule: Appendix C.2), it is mapped to the following Schematron rule:
<sch:rule context="/nc:rpc-reply/nc:data/dhcp:dhcp/ <sch:rule context="/nc:rpc-reply/nc:data/dhcp:dhcp/
dhcp:default-lease-time"> dhcp:default-lease-time">
<sch:assert test=". &lt;= ../dhcp:max-lease-time"> <sch:assert test=". &lt;= ../dhcp:max-lease-time">
The default-lease-time must be less than max-lease-time The default-lease-time must be less than max-lease-time
</sch:assert> </sch:assert>
</sch:rule> </sch:rule>
Now assume the element definition is inside a named pattern Now assume the element definition is inside a named pattern
definition, say definition, say
<rng:define name="_dhcp__default-lease-time"> <rng:define name="_dhcp__default-lease-time">
<rng:element name="dhcp:default-lease-time"> <rng:element name="dhcp:default-lease-time">
... same content ... ... same content ...
</rng:element> </rng:element>
</rng:define> </rng:define>
In this case it is mapped to an abstract rule: In this case it is mapped to an abstract rule, for instance
<sch:rule id="id31415926" abstract="true"> <sch:rule id="id31415926" abstract="true">
<sch:assert test=". &lt;= ../dhcp:max-lease-time"> <sch:assert test=". &lt;= ../dhcp:max-lease-time">
The default-lease-time must be less than max-lease-time The default-lease-time must be less than max-lease-time
</sch:assert> </sch:assert>
</sch:rule> </sch:rule>
Any use of the named pattern definition via <rng:ref Any use of the named pattern definition via <rng:ref
name="_dhcp__default-lease-time"/> then results in a new rule name="_dhcp__default-lease-time"/> then results in a new rule
extending the abstract one, for example extending the abstract one, for example
skipping to change at page 43, line 5 skipping to change at page 45, line 5
This procedure is identical to the RELAX NG case, including the This procedure is identical to the RELAX NG case, including the
handling of @nma:config if the target document type is <get- handling of @nma:config if the target document type is <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/dhcp" prefix="dhcp"/> <sch:ns uri="http://example.com/ns/dhcp" prefix="dhcp"/>
3. Validation phases are defined (see Section 9.2.1) and their 3. Validation phases are defined (see Section 10.2.1) and their
constituting patterns "standard" and "ref-integrity" created. constituting patterns "standard" and "ref-integrity" created.
4. For either validation phase, the input conceptual tree schema is 4. For either validation phase, the input conceptual tree schema is
scanned and element definitions with annotations relevant for the scanned and element definitions with annotations relevant for the
given phase are selected and a <sch:rule> is created for each of given phase are selected and a <sch:rule> is created for each of
them. The rule is abstract if the element definition appears them. The rule is abstract if the element definition appears
inside a named pattern, see above. inside a named pattern, see above.
5. All annotations attached to the given element definition are then 5. All annotations attached to the given element definition are then
mapped using the mapping rules specified in Section 11. The mapped using the mapping rules specified in Section 12. The
resulting <sch:assert> or <sch:report> elements are the installed resulting <sch:assert> or <sch:report> elements are the installed
as children of the <sch:rule> element. as children of the <sch:rule> element.
9.2.1. Validation Phases 10.2.1. Validation Phases
In certain situations it is useful to validate XML instance documents In certain situations it is useful to validate XML instance documents
without enforcing the referential integrity constraints represented without enforcing the referential integrity constraints represented
by the @nma:leafref and <nma:instance-identifier> annotations. For by the @nma:leafref and <nma:instance-identifier> annotations. For
example, a candidate configuration referring to configuration example, a candidate configuration referring to configuration
parameters or state data of certain hardware will not pass full parameters or state data of certain hardware will not pass full
validation before the hardware is installed. To handle this, the validation before the hardware is installed. To handle this, the
Schematron mapping introduces two _validation phases_: Schematron mapping introduces two _validation phases_:
o Validation phase "full", which is the default, checks all semantic o Validation phase "full", which is the default, checks all semantic
skipping to change at page 44, line 23 skipping to change at page 46, line 23
<sch:active pattern="standard"/> <sch:active pattern="standard"/>
</sch:phase> </sch:phase>
<sch:pattern id="standard"> <sch:pattern id="standard">
... all rules except ref. integrity checks ... ... all rules except ref. integrity checks ...
</sch:pattern> </sch:pattern>
<sch:pattern id="ref-integrity"> <sch:pattern id="ref-integrity">
... rules for ref. integrity checks ... ... rules for ref. integrity checks ...
</sch:pattern> </sch:pattern>
</sch:schema> </sch:schema>
9.3. Constraints on Mandatory Choice 10.3. Constraints on Mandatory Choice
In order to fully represent the semantics of YANG 'choice' statement In order to fully represent the semantics of YANG 'choice' statement
with "mandatory true;" substatement, the RELAX NG grammar has to be with "mandatory true;" substatement, the RELAX NG grammar has to be
combined with a special Schematron rule. Consider the following combined with a special Schematron rule.
module:
EXAMPLE. Consider the following module:
module example4 { module example4 {
namespace "http://example.com/ns/example4"; namespace "http://example.com/ns/example4";
prefix ex4; prefix ex4;
choice foobar { choice foobar {
mandatory true; mandatory true;
case foo { case foo {
leaf foo1 { leaf foo1 {
type uint8; type uint8;
} }
skipping to change at page 45, line 7 skipping to change at page 47, line 8
} }
} }
In this module, all three leaf nodes in both case branches are In this module, all three leaf nodes in both case branches are
optional but because of the "mandatory true;" statement, at least one optional but because of the "mandatory true;" statement, at least one
of them must be present in a valid configuration. The 'choice' of them must be present in a valid configuration. The 'choice'
statement from this module is mapped to the following fragment of the statement from this module is mapped to the following fragment of the
conceptual tree schema: conceptual tree schema:
<rng:choice> <rng:choice>
<rng:group> <rng:interleave>
<rng:optional> <rng:optional>
<rng:element name="ex4:foo1"> <rng:element name="ex4:foo1">
<rng:data type="unsignedByte"/> <rng:data type="unsignedByte"/>
</rng:element> </rng:element>
</rng:optional> </rng:optional>
<rng:optional> <rng:optional>
<rng:element name="ex4:foo2"> <rng:element name="ex4:foo2">
<rng:data type="unsignedByte"/> <rng:data type="unsignedByte"/>
</rng:element> </rng:element>
</rng:optional> </rng:optional>
</rng:group> </rng:interleave>
<rng:element name="ex4:bar"> <rng:element name="ex4:bar">
<rng:data type="unsignedByte"/> <rng:data type="unsignedByte"/>
</rng:element> </rng:element>
</rng:choice> </rng:choice>
In the second case branch, the "ex4:bar" element is defined as In the second case branch, the "ex4: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,
skipping to change at page 46, line 5 skipping to change at page 48, line 5
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="ex4:foo1 or ex4:foo2 or ex4:bar"> <sch:assert test="ex4:foo1 or ex4:foo2 or ex4: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>
9.4. Mapping Default Values to DSRL 10.4. Mapping Default Values to DSRL
DSRL is the only component of DSDL that 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 has other information set of the validated XML document. While DSRL has other
functions, the YANG-to-DSDL mapping uses it only for specifying functions, the YANG-to-DSDL mapping uses it only for specifying
default content. For XML instance documents based on YANG data default content. For XML instance documents based on YANG data
models, insertion of default content takes place for all implicit models, insertion of default content may potentially take place for
nodes, see Section 8.1. all implicit nodes, see Section 9.1.
In DSRL, the default content of an element is specified using the In DSRL, the default content of an element is 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 application of the default content, see [11]: context for application of the default content, see [DSRL]:
o <dsrl:parent> element contains an XSLT pattern specifying the o <dsrl:parent> element contains an XSLT pattern specifying the
parent element; the default content is applied only if the parent parent element; the default content is applied only if the parent
element exists in the instance document. element exists in the instance document.
o <dsrl:name> contains the XML name of the element which, if missing o <dsrl:name> contains the XML name of the element which, if missing
or empty, is inserted together with the content of <dsrl:default- or empty, is inserted together with the content of <dsrl:default-
content>. 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 proper application of default always present in order to guarantee proper application of default
content. content.
DSRL mapping only deals with element patterns defining implicit nodes DSRL mapping only deals with element patterns defining implicit nodes
(see Section 8.1.2). In the conceptual tree schema, such element (see Section 9.1.2). In the conceptual tree schema, such element
patterns are distinguished by NETMOD-specific annotation attributes patterns are distinguished by NETMOD-specific annotation attributes
that @nma:default or @nma:implicit, i.e., they are either @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 47, line 14 skipping to change at page 49, line 14
<dsrl:element-map> <dsrl:element-map>
<dsrl:parent>XPARENT</dsrl:parent> <dsrl:parent>XPARENT</dsrl:parent>
<dsrl:name>ELEM</dsrl:name> <dsrl:name>ELEM</dsrl:name>
<dsrl:default-content>DEFCONT</dsrl:default-content> <dsrl:default-content>DEFCONT</dsrl:default-content>
</dsrl:element-map> </dsrl:element-map>
where XPARENT is the absolute XPath of ELEM's parent element in the where XPARENT is the absolute XPath of ELEM's parent element in the
data tree and DEFCONT is constructed as follows: data tree and DEFCONT is constructed as follows:
If the element pattern defining ELEM is annotated with @nma: o If the element pattern defining ELEM is annotated with @nma:
default, DEFCONT is equal to the value of this attribute denoted default, DEFCONT is equal to the value of this attribute (denoted
above as DEFVALUE. above as DEFVALUE).
Otherwise, if the element pattern defining ELEM is annotated with o Otherwise, if the element pattern defining ELEM is annotated with
@nma:implicit, DEFCONT is an XML fragment containing all @nma:implicit, DEFCONT is an XML fragment containing all
descendant elements of ELEM that have either @nma:implicit or descendant elements of ELEM that have either @nma:implicit or
@nma:default attribute. @nma:default attribute.
A more complicated situation arises when the element pattern defining Inside the subtree of <rng:choice>, the @nma:default and @nma:
an implicit node ELEM is a child of <rng:group> with @nma:implicit implicit annotations MUST be ignored unless they are descendants of a
attribute. This corresponds to the default case of a YANG choice <rng:group> or <rng:interleave> pattern with @nma:implicit attribute
(see Section 10.12) and the DSRL mapping has to make sure that the set to "true" - this corresponds to the default case of a YANG choice
default content is applied only if none of the nodes from any non- (see Section 11.12).
When mapping such a default case, it has to be guaranteed that the
default content is be applied if any of the nodes from any non-
default case are present. This is accomplished by setting <dsrl: default case are present. This is accomplished by setting <dsrl:
parent> in a special way: 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 top-level nodes from where ELEM1, ELEM2, ... ELEMn are the names of top-level nodes from
all non-default cases. The rest of the element map is exactly as all non-default cases. The rest of the element map is exactly as
above. above.
EXAMPLE. Consider the following YANG module: EXAMPLE. Consider the following YANG module:
skipping to change at page 50, line 5 skipping to change at page 51, line 48
<dsrl:parent>/nc:rpc-reply/nc:data/ex5:outer/ex5:one</dsrl:parent> <dsrl:parent>/nc:rpc-reply/nc:data/ex5:outer/ex5:one</dsrl:parent>
<dsrl:name>ex5:leaf2</dsrl:name> <dsrl:name>ex5: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 can never become an implicit element. choice and as such can never become an implicit element.
10. Mapping YANG Statements to Conceptual Tree Schema YANG leaf nodes may also obtain a default value from their type
definition. Consequently, @nma:default attributes may also be
attached to <rng:define> elements. The DSRL mapping MUST handle all
<rng:element> patterns that refer to such a named pattern definition
and don't have their own @nma:default attribute in the same way as if
the @nma:default attributed was attached to the referring <rng:
element>.
Finally, if there is a chain of named pattern definitions containing
multiple @nma:default attributes, only the topmost @nma:default
annotation is taken into account.
11. Mapping YANG Statements to Conceptual Tree 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 how the statement is mapped to the provides the specification how the statement is mapped to the
annotated RELAX NG schema of the conceptual tree. This is the first annotated RELAX NG schema of the conceptual tree. This is the first
step of the mapping procedure, see Section 5. The subsections are step of the mapping procedure, see Section 6. The subsections are
sorted alphabetically by the statement keyword. sorted alphabetically by the 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 algorithm 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. substatements. Any changes to this default recursive procedure are
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:
1. Within the <nmt:rpc-methods> subtree (i.e., for RPC input and 1. Within the <nmt:rpc-methods> subtree (i.e., for RPC input and
output parameters) the order of subelements is fixed and their output parameters) the order of subelements is fixed and their
definitions in the conceptual tree schema MUST follow the order definitions in the conceptual tree schema MUST follow the order
specified in the source YANG module. specified in the source YANG module.
2. When mapping the 'list' statement, all keys MUST come before any 2. When mapping the 'list' statement, all keys MUST come before any
skipping to change at page 50, line 46 skipping to change at page 53, line 47
3. Otherwise, all definitions of subelements in the conceptual tree 3. Otherwise, all definitions of subelements in the conceptual tree
schema MUST be enclosed in the <rng:interleave> element. schema MUST be enclosed in the <rng:interleave> element.
We use the following notation: We use the following notation:
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 11.1. The anyxml Statement
This statement is mapped to <rng:element> element and ARGUMENT with This statement is mapped to <rng:element> element and ARGUMENT with
prepended local namespace prefix becomes the value of its @name prepended local namespace prefix becomes the value of its @name
attribute. The content of <rng:element> is attribute. The content of <rng:element> is
<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 RELAX NG element definition. additional children of the RELAX NG element definition.
If the 'anyxml' statement occurs in any of the input YANG modules, If the 'anyxml' statement occurs in any of the input YANG modules,
the following pattern definition MUST be added exactly once to the the following pattern definition MUST be added exactly once to the
RELAX NG schema as a child of the <rng:grammar> element (cf. [21], p. RELAX NG schema as a child of the <rng:grammar> element (cf. [Vli04],
172): p. 172):
<rng:define name="__anyxml__"> <rng:define name="__anyxml__">
<rng:zeroOrMore> <rng:zeroOrMore>
<rng:choice> <rng:choice>
<rng:attribute> <rng:attribute>
<rng:anyName/> <rng:anyName/>
</rng:attribute> </rng:attribute>
<rng:element> <rng:element>
<rng:anyName/> <rng:anyName/>
<rng:ref name="__anyxml__"/> <rng:ref name="__anyxml__"/>
skipping to change at page 51, line 44 skipping to change at page 54, line 46
<rng:element name="yam:data"> <rng:element name="yam:data">
<a:documentation>Any XML content allowed here</a:documentation> <a:documentation>Any XML content allowed here</a:documentation>
<rng:ref name="__anyxml__"/> <rng:ref name="__anyxml__"/>
</rng:element> </rng:element>
An anyxml node is optional if there is no "mandatory true;" An anyxml node is optional if there is no "mandatory true;"
substatement. The <rng:element> element then MUST be wrapped in substatement. The <rng:element> element then MUST be wrapped in
<rng:optional>, except when the 'anyxml' statement is a child of the <rng:optional>, except when the 'anyxml' statement is a child of the
'choice' statement and thus forms a shorthand case for that choice 'choice' statement and thus forms a shorthand case for that choice
(see Section 8.1.1 for details). (see Section 9.1.1 for details).
10.2. The argument Statement 11.2. The argument Statement
This statement is not mapped to the output schema, but see the rules This statement is not mapped to the output schema, but see the rules
for handling extensions in Section 8.4. for handling extensions in Section 9.4.
10.3. The augment Statement 11.3. The augment Statement
As a substatement of 'uses', this statement is handled as a part of As a substatement of 'uses', this statement is handled as a part of
'uses' mapping, see Section 10.57. 'uses' mapping, see Section 11.57.
At the top level of a module or submodule, the 'augment' statement is At the top level of a module or submodule, the 'augment' statement is
used for augmenting the schema tree of another YANG module. If the used for augmenting the schema tree of another YANG module. If the
latter module is not processed within the same mapping session, the latter module is not processed within the same mapping session, the
top-level 'augment' statement MUST be ignored. Otherwise, the top-level 'augment' statement MUST be ignored. Otherwise, the
contents of the statement are added to the foreign module with the contents of the statement are added to the foreign module with the
namespace of the module where the 'augment' statement appears. namespace of the module where the 'augment' statement appears.
10.4. The base Statement 11.4. The base Statement
This statement is ignored as a substatement of 'identity' and handled This statement is ignored as a substatement of 'identity' and handled
within the 'identityref' type if it appears as a substatement of that within the 'identityref' type if it appears as a substatement of that
type definition, see Section 10.53.5. type definition, see Section 11.53.5.
10.5. The belongs-to Statement 11.5. The belongs-to Statement
This statement is not used since processing of submodules is always This statement is not used since processing of submodules is always
initiated from the main module, see Section 10.24. initiated from the main module, see Section 11.24.
10.6. The bit Statement 11.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.3. Section 11.53.3.
10.7. The case Statement 11.7. The case Statement
This statement is mapped to <rng:group> element. If the argument of This statement is mapped to <rng:group> or <rng:interleave> element,
a sibling 'default' statement equals to ARGUMENT, @nma:implicit depending on whether the statement belongs to an RPC definition or
attribute with the value "true" MUST be added to that <rng:group> not. If the argument of a sibling 'default' statement equals to
element. The @nma:implicit attribute MUST NOT be used for nodes that ARGUMENT, @nma:implicit attribute with the value "true" MUST be added
belong to non-default cases of a choice (see Section 7.9.3 in [5]). to that <rng:group> or <rng:interleave> element. The @nma:implicit
attribute MUST NOT be used for nodes that belong to non-default cases
of a choice (see Section 7.9.3 in [YANG]).
10.8. The choice Statement 11.8. The choice Statement
This statement is mapped to <rng:choice> element. This statement is mapped to <rng:choice> element.
Unless 'choice' has the 'mandatory' substatement with the value Unless 'choice' has the 'mandatory' substatement with the value
"true", the <rng:choice> element MUST be wrapped in <rng:optional>. "true", the <rng:choice> element MUST be wrapped in <rng:optional>.
The 'choice' statement with "mandatory true;" requires additional The 'choice' statement with "mandatory true;" requires additional
handling, see Section 9.3. handling, see Section 10.3.
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 11.9. The config Statement
This statement is mapped to @nma:config attribute and ARGUMENT This statement is mapped to @nma:config attribute and ARGUMENT
becomes its value. becomes its value.
10.10. The contact Statement 11.10. The contact Statement
This statement is not used by the mapping since the output RELAX NG This statement is not used by the mapping since the output RELAX NG
schema may result from multiple YANG modules created by different schema may result from multiple YANG modules created by different
authors. The schema contains references to all input modules in the authors. The schema contains references to all input modules in the
Dublin Core elements <dc:source>, see Section 10.34. The original Dublin Core elements <dc:source>, see Section 11.34. The original
YANG modules are the authoritative sources of the authorship YANG modules are the authoritative sources of the authorship
information. information.
10.11. The container Statement 11.11. The container Statement
Using the rules specified in Section 8.1.1, the mapping algorithm Using the rules specified in Section 9.1.1, the mapping algorithm
MUST determine whether the statement defines an optional container, MUST determine whether the statement defines an optional container,
and if so, insert the <rng:optional> element and make it the new and if so, insert the <rng:optional> element and make it the new
PARENT. PARENT.
The container defined by this statement is then mapped to the <rng: The container defined by this statement is then mapped to the <rng:
element> element, which becomes a child of PARENT and uses ARGUMENT element> element, which becomes a child of PARENT and uses ARGUMENT
with prepended local namespace prefix as the value of its @name with prepended local namespace prefix as the value of its @name
attribute. attribute.
Finally, using the rules specified in Section 8.1.2, the mapping Finally, using the rules specified in Section 9.1.2, the mapping
algorithm MUST determine whether the container is implicit, and if algorithm MUST determine whether the container is implicit, and if
so, add the attribute @nma:implicit with the value "true" to the so, add the attribute @nma:implicit with the value "true" to the
<rng:element> element. <rng:element> element.
10.12. The default Statement 11.12. The default Statement
If this statement is a substatement of 'typedef' or 'leaf', it is If this statement is a substatement of 'leaf', it is mapped to the
mapped to the @nma:default attribute of PARENT and ARGUMENT becomes @nma:default attribute of PARENT and ARGUMENT becomes its value.
its value.
The @nma:default attribute MUST NOT be used for nodes that belong to As a substatement of 'typedef', the 'default' statement is also
non-default cases of a choice (see Section 7.9.3 in [5]). mapped to the @nma:default attribute with the value of ARGUMENT. The
placement of this attribute depends on whether or not the type
definition has to be expanded when it is used:
As a substatement of 'choice', the 'default' statement identifies the o If the type definition is not expanded, @nma:default becomes an
default case and is handled within the 'case' statement, see attribute of the <rng:define> pattern resulting from the parent
Section 10.7. If the default case uses the shorthand notation where 'typedef' mapping.
the 'case' statement is omitted, an extra <rng:group> element MUST be
inserted with @nma:implicit attribute set to "true" and map the o Otherwise, @nma:default becomes an attribute of the ancestor RELAX
default case node inside this element. The net result is then the NG pattern inside which the expansion takes place.
same as if the 'case' statement wasn't omitted for the default case.
Details and an example are given in Section 9.2.2.
Finally, as a substatement of 'choice', the 'default' statement
identifies the default case and is handled within the 'case'
statement, see Section 11.7. If the default case uses the shorthand
notation where the 'case' statement is omitted, an extra <rng:group>
or <rng:interleave> element MUST be inserted with @nma:implicit
attribute set to "true" and the default case node is mapped inside
this element. The net result is then the same as if the 'case'
statement wasn't omitted for the default case.
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 mapped to is mapped to
<rng:choice> <rng:choice>
<rng:group nma:implicit="true"> <rng:interleave nma:implicit="true">
<rng:element name="yam:feuille"> <rng:element name="yam:feuille">
<rng:empty/> <rng:empty/>
</rng:element> </rng:element>
</rng:group> </rng:interleave>
<rng:element name="yam:hoja"> <rng:element name="yam:hoja">
<rng:empty/> <rng:empty/>
</rng:element/> </rng:element/>
</rng:choice> </rng:choice>
10.13. The description Statement 11.13. The description Statement
This statement is ignored if it appears at the top level of each
input YANG module. The description can be found in the source module
that is referred to by Dublin Core element <dc:source> and use
ARGUMENT as its content.
Otherwise, this statement is mapped to the DTD compatibility element This statement MAY be ignored. Otherwise, it is mapped to the DTD
<a:documentation> and ARGUMENT becomes its text. compatibility element <a:documentation> and ARGUMENT becomes its
text.
In order to get properly formatted in the RELAX NG compact syntax, In order to get properly formatted in the RELAX NG compact syntax,
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 11.14. The deviation Statement
This statement is ignored, see Section 7.5. This statement is ignored, see Section 8.5.
10.15. The enum Statement 11.15. The enum Statement
This statement is mapped to <rng:value> element and ARGUMENT becomes This statement is mapped to <rng:value> element and ARGUMENT becomes
its text. All substatements except 'status' are ignored because the its text. All substatements except 'status' are ignored because the
<rng:value> element cannot contain annotations, see [12], section 6. <rng:value> element cannot contain annotation elements, see [RNG],
section 6.
10.16. The error-app-tag Statement 11.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. See
also Section 10.35. also Section 11.35.
10.17. The error-message Statement 11.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. See
also Section 10.35. also Section 11.35.
10.18. The extension Statement 11.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 8.4. MAY be mapped as described in Section 9.4.
10.19. The feature Statement 11.19. The feature Statement
This statement is ignored, see Section 7.5. This statement is ignored, see Section 8.5.
10.20. The grouping Statement 11.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 8.2. according to the rules specified in Section 9.2.
Whenever a grouping is used with additional refinements and/or Whenever a grouping is used with additional refinements and/or
augments, the grouping is expanded so that the refinements and augments, the grouping is expanded so that the refinements and
augments may be applied directly to the prescribed schema nodes. See augments may be applied directly to the prescribed schema nodes. See
Section 8.2.1 for further details and an example. Section 9.2.1 for further details and an example.
An implementation MAY offer the option of recording all 'grouping' An implementation MAY offer the option of recording all 'grouping'
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.21. The identity Statement 11.21. The identity Statement
This statement is not specifically mapped. However, if the identity This statement is not specifically mapped. However, if the identity
defined by this statement is used as the base for an "identityref" defined by this statement is used as the base for an "identityref"
type in any of the input modules, ARGUMENT will appear as the text of type in any of the input modules, ARGUMENT will appear as the text of
one of the <rng:value> elements in the mapping of that "identityref" one of the <rng:value> elements in the mapping of that "identityref"
type. See Section 10.53.5 for more details and an example. type. See Section 11.53.5 for more details and an example.
10.22. The if-feature Statement 11.22. The if-feature Statement
This statement is ignored, see Section 7.5. This statement is ignored, see Section 8.5.
10.23. The import Statement 11.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 be able to in ARGUMENT has to be parsed so that the importing module be able to
use its top-level groupings and typedefs and also augment the data use its top-level groupings and typedefs and also augment the data
tree of the imported module. tree of the imported module.
If the 'import' statement has the 'revision' substatement, the If the 'import' statement has the 'revision' substatement, the
corresponding revision of the imported module MUST be used. The corresponding revision of the imported module MUST be used. The
mechanism for finding a given module revision is outside the scope of mechanism for finding a given module revision is outside the scope of
this document. this document.
10.24. The include Statement 11.24. The include Statement
This statement is not specifically mapped. The submodule whose name This statement is not specifically mapped. The submodule whose name
is in ARGUMENT has to be parsed and its contents mapped exactly as if is in ARGUMENT has to be parsed and its contents mapped exactly as if
the submodule text was a subset of the main module text. the submodule text was a subset of the main module text.
If the 'include' statement has the 'revision' substatement, the If the 'include' statement has the 'revision' substatement, the
corresponding revision of the submodule MUST be used. The mechanism corresponding revision of the submodule MUST be used. The mechanism
for finding a given submodule revision is outside the scope of this for finding a given submodule revision is outside the scope of this
document. document.
10.25. The input Statement 11.25. The input Statement
This statement is handled within 'rpc' statement, see Section 10.50. This statement is handled within 'rpc' statement, see Section 11.50.
10.26. The key Statement 11.26. The key Statement
This statement is mapped to @nma:key attribute. ARGUMENT is MUST be This statement is mapped to @nma:key attribute. ARGUMENT is MUST be
translated so that every key is prefixed with the namespace prefix of translated so that every key is prefixed with the namespace prefix of
the local module. The result of this translation then becomes the the local module. The result of this translation then becomes the
value of the @nma:key attribute. value of the @nma:key attribute.
10.27. The leaf Statement 11.27. The leaf Statement
This statement is mapped to the <rng:element> element and ARGUMENT This statement is mapped to the <rng:element> element 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. attribute.
A leaf is optional if there is no "mandatory true;" substatement and A leaf is optional if there is no "mandatory true;" substatement and
if the leaf is not declared among the keys of an enclosing list. The if the leaf is not declared among the keys of an enclosing list. The
<rng:element> element then MUST be wrapped in <rng:optional>, except <rng:element> element then MUST be wrapped in <rng:optional>, except
when the 'leaf' statement is a child of the 'choice' statement and when the 'leaf' statement is a child of the 'choice' statement and
thus forms a shorthand case for that choice (see Section 8.1.1 for thus forms a shorthand case for that choice (see Section 9.1.1 for
details). details).
10.28. The leaf-list Statement 11.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 <rng:
zeroOrMore> or <rng:oneOrMore> element depending on whether the zeroOrMore> or <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 the 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. If the 'leaf-list' statement has the 'min-elements' attribute. If the 'leaf-list' statement has the 'min-elements'
substatement and its argument is greater than one, additional substatement and its argument is greater than one, additional
attribute @nma:min-elements is attached to <rng:element> and the attribute @nma:min-elements is attached to <rng:element> and the
argument of 'min-elements' becomes the value of this attribute. argument of 'min-elements' becomes the value of this attribute.
Similarly, if there is the 'max-elements' substatement and its Similarly, if there is the 'max-elements' substatement and its
argument value is not "unbounded", attribute @nma:max-elements is argument value is not "unbounded", attribute @nma:max-elements is
attached to this element and the argument of 'max-elements' becomes attached to this element and the argument of 'max-elements' becomes
the value of this attribute. the value of this attribute.
skipping to change at page 57, line 42 skipping to change at page 61, line 4
type string; type string;
} }
is mapped to the following RELAX NG fragment: is mapped to the following RELAX NG fragment:
<rng:oneOrMore> <rng:oneOrMore>
<rng:element name="yam:foliage" nma:ordered-by="user" <rng:element name="yam:foliage" 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 11.29. The length Statement
This statement is handled within the "string" type, see This statement is handled within the "string" type, see
Section 10.53.9. Section 11.53.9.
10.30. The list Statement 11.30. The list Statement
This statement is mapped exactly as the 'leaf-list' statement, see This statement is mapped exactly as the 'leaf-list' statement, see
Section 10.28. Section 11.28.
10.31. The mandatory Statement When mapping the substatements of 'list', the order of children of
the list element MUST be specified so that list keys always appear in
the same order as they are defined in the input YANG module and
before other children, see [YANG], Section 7.8.5. In particular, if
any list key is defined in a grouping but the list itself is not
defined in the same grouping, and the position of the 'uses'
statement would violate the above ordering requirement, the grouping
MUST be expanded, i.e., the 'uses' statement replaced by the grouping
contents.
For example, consider the following YANG fragment of a module with
prefix "yam":
grouping keygrp {
leaf clef {
type uint8;
}
}
list foo {
key clef;
leaf bar {
type string;
}
leaf baz {
type string;
}
uses keygrp;
}
is mapped to the following RELAX NG fragment:
<rng:zeroOrMore>
<rng:element name="yam:foo" nma:key="yam:clef">
<rng:element name="yam:clef">
<rng:data type="unsignedByte"/>
</rng:element>
<rng:interleave>
<rng:element name="yam:bar">
<rng:data type="string"/>
</rng:element>
<rng:element name="yam:baz">
<rng:data type="string"/>
</rng:element>
</rng:interleave>
</rng:element>
</rng:zeroOrMore>
Note that the "keygrp" grouping is expanded and the "yam:clef"
definition moved before the <rng:interleave> pattern.
11.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 8.1.1. mapped as mandatory, see Section 9.1.1.
10.32. The max-elements Statement 11.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 11.28.
10.33. The min-elements Statement 11.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 11.28.
10.34. The module Statement 11.34. The module Statement
This statement is not specifically mapped except that a <dc:source> This statement is not specifically mapped except that a <dc:source>
element SHOULD be created as a child of <rng:grammar> and contain element SHOULD be created as a child of <rng:grammar> and contain
ARGUMENT as a reference to the input YANG module. See also ARGUMENT as a reference to the input YANG module. See also
Section 10.49. Section 11.49.
With respect to the conceptual tree schema, substatements of 'module' With respect to the conceptual tree schema, substatements of 'module'
MUST be mapped so that MUST be mapped so that
o top level data elements be defined as children of the <nmt:top> o top level data elements be defined as children of the <nmt:top>
element; element;
o elements mapped from 'rpc' statements be defined as children of o elements mapped from 'rpc' statements be defined as children of
the <nmt:rpc-methods> element; the <nmt:rpc-methods> element;
o elements mapped from 'notification' statements be defined as o elements mapped from 'notification' statements be defined as
children of the <nmt:notifications> element. children of the <nmt:notifications> element.
10.35. The must Statement 11.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), which contains
ARGUMENT transformed into a valid XPath expression (see Section 8.3). ARGUMENT transformed into a valid XPath expression (see Section 9.3).
The <nma:must> element may get other subelements resulting from The <nma:must> element may get other subelements resulting from
mapping 'error-app-tag' and 'error-message' substatements. Other mapping '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 EXAMPLE. YANG statement
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 11.36. The namespace Statement
This statement is mapped to @xmlns:xxx attribute of the <rng:grammar> This statement is mapped to @xmlns:xxx attribute of the <rng:grammar>
element where "xxx" is the namespace prefix specified by the sibling element where "xxx" is the namespace prefix specified by the sibling
'prefix' statement. ARGUMENT becomes the value of this attribute. 'prefix' statement. ARGUMENT becomes the value of this attribute.
10.37. The notification Statement 11.37. The notification Statement
This statement is mapped to the following subtree in the RELAX NG This statement is mapped to the following subtree in the RELAX NG
schema ("yam" is the prefix of the local YANG module): schema ("yam" is the prefix of the local YANG module):
<rng:element name="nmt:notification"> <rng:element name="nmt:notification">
<rng:element name="yam:ARGUMENT"> <rng:element name="yam:ARGUMENT">
... ...
</rng:element> </rng:element>
</rng:element> </rng:element>
Substatements of 'notification' are mapped under <rng:element Substatements of 'notification' are mapped under <rng:element
name="yam:ARGUMENT">. name="yam:ARGUMENT">.
The <rng:element name="nmt:rpc-notification"> element is a child of The <rng:element name="nmt:rpc-notification"> element is a child of
<rng:element name="nmt:notifications">. <rng:element name="nmt:notifications">.
10.38. The ordered-by Statement 11.38. The ordered-by Statement
This statement is mapped to @nma:ordered-by attribute and ARGUMENT This statement is mapped to @nma:ordered-by attribute and ARGUMENT
becomes the value of this attribute. See Section 10.28 for an becomes the value of this attribute. See Section 11.28 for an
example. example.
10.39. The organization Statement 11.39. The organization Statement
This statement is not used by the mapping since the output RELAX NG This statement is not used by the mapping since the output RELAX NG
schema may result from multiple YANG modules authored by different schema may result from multiple YANG modules authored by different
parties. The schema contains references to all input modules in the parties. The schema contains references to all input modules in the
Dublin Core elements <dc:source>, see Section 10.34. The original Dublin Core elements <dc:source>, see Section 11.34. The original
modules are the authoritative sources of the authorship information. modules are the authoritative sources of the authorship information.
10.40. The output Statement 11.40. The output Statement
This statement is handled within 'rpc' statement, see Section 10.50. This statement is handled within 'rpc' statement, see Section 11.50.
10.41. The path Statement 11.41. The path Statement
This statement is handled within "leafref" type, see Section 10.53.7. This statement is handled within "leafref" type, see Section 11.53.7.
10.42. The pattern Statement 11.42. The pattern Statement
This statement is handled within "string" type, see Section 10.53.9. This statement is handled within "string" type, see Section 11.53.9.
10.43. The position Statement 11.43. The position Statement
This statement is ignored. This statement is ignored.
10.44. The prefix Statement 11.44. The prefix Statement
This statement is handled within the sibling 'namespace' statement, This statement is handled within the sibling 'namespace' statement,
see Section 10.36, or within the parent 'import' statement, see see Section 11.36, or within the parent 'import' statement, see
Section 10.23. As a substatement of 'belongs-to' (in submodules), Section 11.23. As a substatement of 'belongs-to' (in submodules),
the 'prefix' statement is ignored. the 'prefix' statement is ignored.
10.45. The presence Statement 11.45. The presence Statement
This statement is mapped to the annotation attribute @nma:presence This statement is mapped to the annotation attribute @nma:presence
with the value "true". In addition, it influences the mapping of with the value "true". In addition, it influences the mapping of
'container' (Section 10.11): the parent container definition MUST be 'container' (Section 11.11): the parent container definition MUST be
wrapped in <rng:optional>, regardless of its content. See also wrapped in <rng:optional>, regardless of its content. See also
Section 8.1.1. Section 9.1.1.
10.46. The range Statement
This statement is handled within numeric types, see Section 10.53.8. 11.46. The range Statement
10.47. The reference Statement This statement is handled within numeric types, see Section 11.53.8.
This statement is ignored if it appears at the top level of a module 11.47. The reference Statement
or submodule.
Otherwise, this statement is mapped to <a:documentation> element and This statement MAY be ignored. Otherwise, it is mapped to
its text is set to ARGUMENT prefixed with "See: ". <a:documentation> element and its text is set to ARGUMENT prefixed
with "See: ".
10.48. The require-instance Statement 11.48. The require-instance Statement
This statement is handled within "instance-identifier" type This statement is handled within "instance-identifier" type
(Section 10.53.6). (Section 11.53.6).
10.49. The revision Statement 11.49. The revision Statement
The mapping uses only the most recent instance of the 'revision' The mapping uses only the most recent instance of the 'revision'
statement, i.e., one with the latest date in ARGUMENT, which statement, i.e., one with the latest date in ARGUMENT, which
specifies the current revision of the input YANG module [5]. This specifies the current revision of the input YANG module [YANG]. This
date SHOULD be recorded, together with the name of the YANG module, date SHOULD be recorded, together with the name of the YANG module,
in the corresponding Dublin Core element <dc:source> (see in the corresponding Dublin Core element <dc:source> (see
Section 10.34), for example in this form: Section 11.34), for example in this form:
<dc:source>YANG module 'foo', revision 2009-01-19</dc:source> <dc:source>YANG module 'foo', revision 2009-01-19</dc:source>
The 'description' substatement of 'revision' is not used. The 'description' substatement of 'revision' is not used.
10.50. The rpc Statement 11.50. The rpc Statement
This statement is mapped to the following subtree in the RELAX NG This statement is mapped to the following subtree in the RELAX NG
schema ("yam" is the prefix of the local YANG module): schema ("yam" is the prefix of the local YANG module):
<rng:element name="nmt:rpc-method"> <rng:element name="nmt:rpc-method">
<rng:element name="nmt:input"> <rng:element name="nmt:input">
<rng:element name="yam:ARGUMENT"> <rng:element name="yam:ARGUMENT">
<!-- mapped content of 'input' --> <!-- mapped content of 'input' -->
</rng:element> </rng:element>
</rng:element> </rng:element>
skipping to change at page 62, line 5 skipping to change at page 66, line 13
As indicated by the comments, contents of the 'input' substatement As indicated by the comments, contents of the 'input' substatement
(if any) are mapped under <rng:element name="yam:ARGUMENT">. (if any) are mapped under <rng:element name="yam:ARGUMENT">.
Similarly, contents of the 'output' substatement are mapped under Similarly, contents of the 'output' substatement are mapped under
<rng:element name="nmt:output">. If there is no 'output' <rng:element name="nmt:output">. If there is no 'output'
substatement, the <rng:element name="nmt:output"> MUST NOT be substatement, the <rng:element name="nmt:output"> MUST NOT be
present. present.
The <rng:element name="nmt:rpc-method"> element is a child of <rng: The <rng:element name="nmt:rpc-method"> element is a child of <rng:
element name="nmt:rpc-methods">. element name="nmt:rpc-methods">.
10.51. The status Statement 11.51. The status Statement
This statement is mapped to @nma:status attribute and ARGUMENT This statement MAY be ignored. Otherwise, it is mapped to @nma:
becomes its value. status attribute and ARGUMENT becomes its value.
10.52. The submodule Statement 11.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 the submodule
belongs to. belongs to.
10.53. The type Statement 11.53. The type Statement
Most YANG built-in types have an equivalent in the XSD datatype Most YANG built-in types have an equivalent in the XSD datatype
library [16] as shown in Table 3. library [XSD-D] as shown in Table 3.
+-----------+---------------+--------------------------------+ +-----------+---------------+--------------------------------+
| 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 63, line 5 skipping to change at page 67, line 36
| boolean | boolean | "true" or "false" | | boolean | boolean | "true" or "false" |
| | | | | | | |
| binary | base64Binary | binary data in base64 encoding | | binary | base64Binary | binary data in base64 encoding |
+-----------+---------------+--------------------------------+ +-----------+---------------+--------------------------------+
Table 3: Selected datatypes from the W3C XML Schema Type Library Table 3: Selected datatypes from the W3C XML Schema Type Library
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 11.53.1. The empty Type
This type is mapped to <rng:empty/>. This type is mapped to <rng:empty/>.
10.53.2. The boolean and binary Types 11.53.2. The boolean and binary Types
These two built-in types do not allow any restrictions and are mapped These two built-in types do not allow any restrictions and are mapped
simply by inserting <rng:data> element whose @type attribute is set simply by inserting <rng:data> element whose @type attribute is set
to ARGUMENT mapped according to Table 3. to ARGUMENT mapped according to Table 3 above.
10.53.3. The bits Type 11.53.3. The bits Type
This type is mapped to <rng:list> and for each 'bit' substatement the This type is mapped to <rng:list> and for each 'bit' substatement the
following XML fragment is inserted as a child of <rng:list>: 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 the where bit_name is the name of the bit as found in the argument of the
corresponding 'bit' statement. corresponding 'bit' statement.
10.53.4. The enumeration and union Types 11.53.4. The enumeration and union Types
These types are mapped to <rng:choice> element. These types are mapped to <rng:choice> element.
10.53.5. The identityref Type 11.53.5. The identityref Type
This type is mapped to <rng:choice> element with one or more <rng: This type is mapped to <rng:choice> element with one or more <rng:
value> subelements. Each of the <rng:value> subelements MUST have value> subelements. Each of the <rng:value> subelements MUST have
the @type attribute and its value set to "QName". One <rng:value> the @type attribute and its value set to "QName". One <rng:value>
subelement with argument of the 'base' substatement as its text MUST subelement for the base identity MUST always be present - it contains
always be present. In addition, one <rng:value> substatement MUST be the argument of the 'base' substatement as its text. In addition,
added for each identity declared locally or in an imported module one <rng:value> substatement MUST be added for each identity declared
that has the argument of the 'base' substatement as its base locally or in an imported module that is derived from this base
identity. identity.
All namespace prefixes that are used for identities from imported All namespace prefixes that are used for identities from imported
modules MUST be appropriately defined. modules MUST be appropriately defined.
EXAMPLE (taken from Section 7.16.3 of [5]). Consider the following EXAMPLE (taken from Section 7.16.3 of [YANG]). Consider the
two YANG modules: following two 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 65, line 7 skipping to change at page 70, line 7
<rng:element name="yam:crypto"> <rng:element name="yam:crypto">
<rng:choice> <rng:choice>
<rng:value type="QName">crypto:crypto-alg</value> <rng:value type="QName">crypto:crypto-alg</value>
<rng:value type="QName">des:des</value> <rng:value type="QName">des:des</value>
<rng:value type="QName">des:des3</value> <rng:value type="QName">des:des3</value>
</rng:choice> </rng:choice>
</rng:element> </rng:element>
The "crypto" and "des" prefixes will by typically defined via The "crypto" and "des" prefixes will by typically defined via
attributes of the <rng:grammar> element. attributes of the <rng:grammar> element.
10.53.6. The instance-identifier Type 11.53.6. The instance-identifier Type
This type is mapped to <rng:data> element with @type attribute set to This type is mapped to <rng:data> element with @type attribute set to
"string". In addition, empty <nma:instance-identifier> element MUST "string". In addition, empty <nma:instance-identifier> element MUST
be inserted as a child of PARENT. be inserted as a child of PARENT.
The 'require-instance' substatement, if it exists, is mapped to the The 'require-instance' substatement, if it exists, is mapped to the
@require-instance attribute of <nma:instance-identifier>. @require-instance attribute of <nma:instance-identifier>.
10.53.7. The leafref Type 11.53.7. The leafref Type
This type is mapped exactly as the type of the leaf given in the This type is mapped exactly as the type of the leaf given in the
argument of 'path' substatement. In addition, @nma:leafref attribute argument of 'path' substatement. In addition, @nma:leafref attribute
MUST be added to PARENT. The argument of the 'path' substatement, MUST be added to PARENT. The argument of the 'path' substatement,
translated according to Section 8.3, is set as the value of this translated according to Section 9.3, is set as the value of this
attribute. attribute.
10.53.8. The numeric Types 11.53.8. 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 <rng:data> element with @type attribute set to ARGUMENT
mapped according to Table 3. mapped according to Table 3.
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 datatype library. Its precision and number
of fractional digits are controlled with the following facets, which of fractional digits are controlled with the following facets, which
MUST always be present: MUST always be present:
skipping to change at page 66, line 11 skipping to change at page 71, line 11
} }
is mapped to the following RELAX NG datatype: is mapped to the following RELAX NG datatype:
<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 handled All numeric types support the 'range' restriction, which is handled
in the following way: as follows:
o If the range expression consists of a single range part, insert If the range expression has just a single range, then
the pair of RELAX NG facets
o if the range consists of a single number, the <rng:value> pattern
is inserted and its content set to this number.
o Otherwise the range consists of both lower and upper bound and the
following pair of datatype facets are inserted:
<rng:param name="minInclusive">...</rng:param>
<rng:param name="minInclusive">...</rng:param>
and and
<rng:param name="maxInclusive">...</rng:param> <rng:param name="maxInclusive">...</rng:param>
Their contents are the lower and upper bound of the range part,
respectively. If the range part consists of a single number, both
"minInclusive" and "maxInclusive" facets use this value as their
content. If the lower bound is "min", the "minInclusive" facet is
omitted and if the upper bound is "max", the "maxInclusive" facet
is omitted.
o If the range expression has multiple parts separated by "|", then Their contents are the lower and upper bound, respectively. If
repeat the <rng:data> element once for every range part and wrap the lower bound is "min", the "minInclusive" facet is omitted and
them all in <rng:choice> element. Each <rng:data> element if the upper bound is "max", the "maxInclusive" facet is omitted.
contains the "minInclusive" and "maxInclusive" facets for one part
of the range expression as described in the previous item.
For example, the 'typedef' statement If the range expression has multiple parts separated by "|", then the
parent <rng:data> element must be repeated once for every range part
and all the <rng:data> elements are wrapped in <rng:choice> element.
Each <rng:data> element contains the <rng:value> pattern or the
"minInclusive" and "maxInclusive" facets for the corresponding part
of the range expression as described in the previous paragraph. For
the "decimal64" type, the "totalDigits" and "fractionDigits" must be
repeated inside each of the <rng:data> elements.
typedef rt { For example,
type int32 {
type int32 {
range "-6378..0|42|100..max"; range "-6378..0|42|100..max";
}
} }
appearing at the top level of the "example" module is mapped to the is mapped to the following RELAX NG fragment:
following RELAX NG fragment:
<rng:define name="example__rt"> <rng:choice>
<rng:choice> <rng:data type="int">
<rng:data type="int"> <rng:param name="minInclusive">-6378</rng:param>
<rng:param name="minInclusive">-6378</rng:param> <rng:param name="maxInclusive">0</rng:param>
<rng:param name="maxInclusive">0</rng:param> </rng:data>
</rng:data> <rng:data type="int">
<rng:data type="int"> <rng:value>42</rng:value>
<rng:param name="minInclusive">42</rng:param> </rng:data>
<rng:param name="maxInclusive">42</rng:param> <rng:data type="int">
</rng:data> <rng:param name="minInclusive">100</rng:param>
<rng:data type="int"> </rng:data>
<rng:param name="minInclusive">100</rng:param> </rng:choice>
</rng:data>
</rng:choice>
</rng:define>
10.53.9. The string Type 11.53.9. The string Type
This type is mapped to <rng:data> element with the @type attribute This type is mapped to <rng:data> element with the @type attribute
set to "string". set to "string".
For the 'pattern' restriction, insert <rng:param> element with @name The 'length' restriction is handled analogically to the 'range'
attribute set to "pattern". The argument of the 'pattern' statement restriction for the numeric types (Section 11.53.8):
(regular expression) becomes the content of this element.
The 'length' restriction is handled in the same way as the 'range' If the length expression has just a single range, then
restriction for the numeric types, with the additional twist that if
the length expression has multiple parts, the "pattern" facet o if the length range consists of a single number L, the following
datatype facet is inserted:
<rng:param name="length">L</rng:param>.
o Otherwise the length range consists of both lower and upper bound
and the following pair of datatype facets are inserted:
<rng:param name="minLength">...</rng:param>
and
<rng:param name="maxLength">...</rng:param>
Their contents are the lower and upper bound of the length range,
respectively. If the lower bound is "min", the "minLength" facet
is omitted and if the upper bound is "max", the "maxLength" facet
is omitted.
If the length expression has of multiple parts separated by "|", then
the parent <rng:data> element must be repeated once for every range
part and all the <rng:data> elements are wrapped in <rng:choice>
element. Each <rng:data> element contains the "length" or
"minLength" and "maxLength" facets for the corresponding part of the
length expression as described in the previous paragraph.
Every 'pattern' restriction of the "string" datatype is mapped to the
"pattern" facet
<rng:param name="pattern">...</rng:param> <rng:param name="pattern">...</rng:param>
if there is any, must be repeated inside each copy of the <rng:data>
element, i.e., for each length part.
10.53.10. Derived Types with content equal to the argument of the 'pattern' statement. All
such "pattern" facets must be repeated inside each copy of the <rng:
data> element, i.e., once for each length range.
For example,
type string {
length "1|3..8";
pattern "[A-Z][a-z]*";
}
is mapped to the following RELAX NG fragment:
<rng:choice>
<rng:data type="string">
<rng:param name="length">1</rng:param>
<rng:param name="pattern">[A-Z][a-z]*</rng:param>
</rng:data>
<rng:data type="string">
<rng:param name="minLength">3</rng:param>
<rng:param name="maxLength">8</rng:param>
<rng:param name="pattern">[A-Z][a-z]*</rng:param>
</rng:data>
</rng:choice>
11.53.10. Derived Types
If the 'type' statement refers to a derived type, it is mapped in one If the 'type' statement refers to a derived type, it is mapped in one
of the following ways depending on whether it contains any of the following ways depending on whether it contains any
restrictions as its substatements: restrictions as its substatements:
1. Without restrictions, the 'type' statement is mapped simply to 1. Without restrictions, the 'type' statement is mapped simply to
the <rng:ref> element, i.e., a reference to a named pattern. If the <rng:ref> element, i.e., a reference to a named pattern. If
the RELAX NG definition of this named pattern has not been added the RELAX NG definition of this named pattern has not been added
to the output schema yet, the corresponding 'typedef' must be to the output schema yet, the corresponding 'typedef' must be
found and its mapping installed as a subelement of <rng:grammar>, found and its mapping installed as a subelement of <rng:grammar>,
see Section 10.54. Even if a given derived type is used more see Section 11.54. Even if a given derived type is used more
than once in the input YANG modules, the mapping of the than once in the input YANG modules, the mapping of the
corresponding 'typedef' MUST be installed only once. corresponding 'typedef' MUST be installed only once.
2. If any restrictions are present, the base type for the given 2. If any restrictions are present, the ancestor built-in type for
derived type must be determined and the mapping of this base type the given derived type must be determined and the mapping of this
is used. Restrictions appearing at all stages of the derivation base type is used. Restrictions appearing at all stages of the
chain must be taken into account and their conjunction added to derivation chain must be taken into account and their conjunction
the <rng:data> element which defines the basic type. added to the <rng:data> element which defines the basic type.
See Section 8.2.2 for more details and an example. See Section 9.2.2 for more details and an example.
10.54. The typedef Statement 11.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 the <rng: case, the named pattern definition becomes a child of the <rng:
grammar> element and its name is ARGUMENT mangled according to the grammar> element and its name is ARGUMENT mangled according to the
rules specified in Section 8.2. rules specified in Section 9.2.
Whenever a derived type is used with additional restrictions, the the Whenever a derived type is used with additional restrictions, the
base type for the derived type is used instead with restrictions ancestor built-in type for the derived type is used instead with
(facets) that are a combination of all restrictions specified along restrictions (facets) that are a combination of all restrictions
the type derivation chain. See Section 10.53.10 for further details specified along the type derivation chain. See Section 11.53.10 for
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 11.55. The unique Statement
This statement is mapped to @nma:unique attribute. ARGUMENT is This statement is mapped to @nma:unique attribute. ARGUMENT is
translated so that every node identifier in each of its components is translated so that every node identifier in each of its components is
prefixed with the namespace prefix of the local module, unless the 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 11.56. The units Statement
This statement is mapped to @nma:units attribute and ARGUMENT becomes This statement is mapped to @nma:units attribute and ARGUMENT becomes
its value. its value.
10.57. The uses Statement 11.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 and the value of its @name it is mapped to <rng:ref> element and the value of its @name
attribute is set to ARGUMENT mangled according to Section 8.2 attribute is set to ARGUMENT mangled according to Section 9.2
If there are any 'refine' or 'augment' substatements, the If there are any 'refine' or 'augment' substatements, the
corresponding grouping must be looked up and its contents is inserted corresponding grouping must be looked up and its contents is inserted
as children of PARENT. See Section 8.2.1 for further details and an under PARENT. See Section 9.2.1 for further details and an example.
example.
10.58. The value Statement 11.58. The value Statement
This statement is ignored. This statement is ignored.
10.59. The when Statement 11.59. The when Statement
This statement is mapped to @nma:when attribute and ARGUMENT, This statement is mapped to @nma:when attribute and ARGUMENT,
translated according to Section 8.3, becomes it value. translated according to Section 9.3, becomes it value.
10.60. The yang-version Statement 11.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). version declared by the statement (currently version 1).
10.61. The yin-element Statement 11.61. The yin-element Statement
This statement is not mapped to the output schema, but see the rules This statement is not mapped to the output schema, but see the rules
for extension handling in Section 8.4. for extension handling in Section 9.4.
11. Mapping NETMOD-specific annotations to DSDL Schema Languages 12. Mapping NETMOD-specific annotations to DSDL Schema Languages
This section contains mapping specification for individual NETMOD- This section contains mapping specification for individual NETMOD-
specific annotations. In each case, the result of the mapping must specific annotations. In each case, the result of the mapping must
be inserted into an appropriate context of the target DSDL schema as be inserted into an appropriate context of the target DSDL schema as
described in Section 9. The context is determined by the element described in Section 10. The context is determined by the element
definition in the conceptual tree schema to which the annotation is definition in the conceptual tree schema to which the annotation is
attached. In the rest of this section, we will denote CONTELEM the attached. In the rest of this section, we will denote CONTELEM the
name of this context element properly qualified with its namespace name of this context element properly qualified with its namespace
prefix. Unless otherwise stated, Schematron asserts are descendants prefix. Unless otherwise stated, Schematron asserts are descendants
of the "standard" pattern and therefore active in both validation of the "standard" pattern and therefore active in both validation
phases. phases.
11.1. The @nma:config Annotation 12.1. The @nma:config Annotation
This annotation MUST be observed when generating any schema for the If this annotation is present with the value "true", the following
reply to <nc:get-config>. In particular: rules apply for DSDL schemas of <nc:get-config> reply. In
particular:
o When generating RELAX NG, the contents of the CONTELEM definition o When generating RELAX NG, the contents of the CONTELEM definition
MUST be changed to <rng:notAllowed>. MUST be changed to <rng:notAllowed>.
o When generating Schematron or DSRL, the CONTELEM definition and o When generating Schematron or DSRL, the CONTELEM definition and
all its descendants in the conceptual tree schema MUST be ignored. all its descendants in the conceptual tree schema MUST be ignored.
11.2. The @nma:default Annotation 12.2. The @nma:default 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 9.4. in Section 10.4.
11.3. The @nma:implicit Annotation 12.3. 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 9.4. in Section 10.4.
11.4. The <nma:error-app-tag> Annotation 12.4. The <nma:error-app-tag> Annotation
This annotation currently has no mapping defined. This annotation currently has no mapping defined.
11.5. The <nma:error-message> Annotation 12.5. The <nma:error-message> Annotation
This annotation is handled within <nma:must>, see Section 11.11. This annotation is handled within <nma:must>, see Section 12.11.
11.6. The <nma:instance-identifier> Annotation 12.6. 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 "false", it is ignored. Otherwise it is mapped to the the value "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 [19]) that evaluates an XPath expression at Extension Functions in [XSLT]) that evaluates an XPath expression at
runtime. Such an extension function is provided by some XSLT runtime. Such an extension function is provided by some XSLT
processors, for example Saxon [25]. processors, for example Saxon [3].
11.7. The @nma:key Annotation 12.7. The @nma:key Annotation
Assume this annotation has the value "k_1 k_2 ... k_n", i.e., Assume this annotation has the value "k_1 k_2 ... k_n", i.e.,
specifies n child leaves as keys. The annotation is then mapped to specifies n child leaves as keys. The annotation is then mapped to
the following Schematron report: the following Schematron report:
<sch:report test="CONDITION"> <sch:report test="CONDITION">
Duplicate key of list "CONTELEM" Duplicate key of list "CONTELEM"
</sch:report> </sch:report>
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 C_i, for i=1,2,...,n, specifies the condition for violation of Each C_i, for i=1,2,...,n, specifies the condition for violation of
uniqueness of key k_i, namely uniqueness of key k_i, namely
k_i=current()/k_i k_i=current()/k_i
11.8. The @nma:leafref Annotation 12.8. The @nma:leafref Annotation
This annotation is mapped to the following assert: This annotation is mapped to the following assert:
<sch:assert test="PATH=."> <sch:assert test="PATH=.">
Leafref "CONTELEM" must have the same value as "PATH" Leafref "CONTELEM" must have the same value as "PATH"
</sch:assert> </sch:assert>
where PATH is the value of @nma:leafref. The assert is a descendant where PATH is the value of @nma:leafref. The assert is a descendant
of the "ref-integrity" pattern, which means that it will be used only of the "ref-integrity" pattern, which means that it will be used only
for the "full" validation phase. for the "full" validation phase.
11.9. The @nma:min-elements Annotation 12.9. The @nma:min-elements Annotation
This annotation is mapped to the following Schematron assert: This annotation is mapped to the following Schematron assert:
<sch:assert test="count(../CONTELEM)&gt;=MIN"> <sch:assert test="count(../CONTELEM)&gt;=MIN">
List "CONTELEM" - item count must be at least MIN List "CONTELEM" - item count must be at least MIN
</sch:assert> </sch:assert>
where MIN is the value of @nma:min-elements. where MIN is the value of @nma:min-elements.
11.10. The @nma:max-elements Annotation 12.10. The @nma:max-elements Annotation
This annotation is mapped to the following Schematron assert: This annotation is mapped to the following Schematron assert:
<sch:assert test="count(../CONTELEM)&lt;=MAX"> <sch:assert test="count(../CONTELEM)&lt;=MAX">
List "CONTELEM" - item count must be at most MAX List "CONTELEM" - item count must be at most MAX
</sch:assert> </sch:assert>
where MAX is the value of @nma:min-elements. where MAX is the value of @nma:min-elements.
11.11. The <nma:must> Annotation 12.11. 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 content, otherwise it is set to the default message set to its content, otherwise it is set to the default message
"Condition EXPRESSION must be true". "Condition EXPRESSION must be true".
11.12. The <nma:ordered-by> Annotation 12.12. The <nma:ordered-by> Annotation
This annotation currently has no mapping defined. This annotation currently has no mapping defined.
11.13. The <nma:status> Annotation 12.13. The <nma:status> Annotation
This annotation currently has no mapping defined. This annotation currently has no mapping defined.
11.14. The @nma:unique Annotation 12.14. The @nma:unique Annotation
The mapping of this annotation is almost identical as for @nma:key, The mapping of this annotation is almost identical as for @nma:key,
see Section 11.7, with two small differences: see Section 12.7, with two small differences:
o The value of @nma:unique is a list of descendant schema node o The value of @nma:unique is a list of descendant schema node
identifiers rather than simple leaf names. However, the XPath identifiers rather than simple leaf names. However, the XPath
expressions specified in Section 11.7 work without any expressions specified in Section 12.7 work without any
modifications if the descendant schema node identifiers are modifications if the descendant schema node identifiers are
substituted for k_1, k_2, ..., k_n. substituted for k_1, k_2, ..., k_n.
o The message appearing as the text of <sch:report> is different: o The message appearing as the text of <sch:report> is different:
"Violated uniqueness for list CONTELEM". "Violated uniqueness for list CONTELEM".
11.15. The @nma:when Annotation 12.15. The @nma:when 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">
Node "CONTELEM" is only valid if "EXPRESSION" is true. Node "CONTELEM" is only valid if "EXPRESSION" is true.
</sch:assert> </sch:assert>
where EXPRESSION is the value of @nma:when. where EXPRESSION is the value of @nma:when.
12. IANA Considerations 13. IANA Considerations
This document registers two namespace URIs in the IETF XML registry This document registers three namespace URIs in the IETF XML registry
[22]: [RFC3688]:
URI: urn:ietf:params:xml:ns:netmod:dsdl-annotations:1 URI: urn:ietf:params:xml:ns:netmod:dsdl-annotations:1
URI: urn:ietf:params:xml:ns:netmod:conceptual-tree:1 URI: urn:ietf:params:xml:ns:netmod:conceptual-tree:1
urn:ietf:params:xml:ns:netmod:xpath-extensions:1
13. References 14. Security Considerations
[1] Enns, R., "NETCONF Configuration Protocol", RFC 4741, This document defines a procedure that maps data models expressed in
December 2006. the YANG language to a coordinated set of DSDL schemas. The
procedure itself has no security impact on the Internet.
[2] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple DSDL schemas obtained by the mapping procedure may be used for
Network Management Protocol (SNMP)", STD 15, RFC 1157, validating the content of NETCONF protocol data units or entire data
May 1990. stores and thus provide additional validity checks above those
performed by NETCONF server and client implementations supporting
YANG data models. The strictness of this validation is directly
derived from the source YANG modules that the validated XML data
adhere to.
[3] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, 15. Acknowledgements
Ed., "Structure of Management Information Version 2 (SMIv2)",
STD 58, RFC 2578, April 1999.
[4] Elliott, C., Harrington, D., Jason, J., Schoenwaelder, J., The authors wish to thank the following individuals who provided
Strauss, F., and W. Weiss, "SMIng Objectives", RFC 3216, helpful suggestions and/or comments on various versions of this
December 2001. document: Andy Bierman, Martin Bjorklund, Jirka Kosek and Phil
Shafer.
[5] Bjorklund, M., Ed., "YANG - A data modeling language for 16. References
NETCONF", draft-ietf-netmod-yang-04 (work in progress),
March 2009.
[6] ISO/IEC, "Document Schema Definition Languages (DSDL) - Part 1: 16.1. Normative References
Overview", ISO/IEC 19757-1, 11 2004.
[7] Bradner, S., "Key words for use in RFCs to Indicate Requirement [DSDL] ISO/IEC, "Document Schema Definition Languages (DSDL) -
Levels", BCP 14, RFC 2119, March 1997. Part 1: Overview", ISO/IEC 19757-1, 11 2004.
[8] Clark, J., Ed. and M. Murata, Ed., "RELAX NG DTD [DSRL] ISO/IEC, "Information Technology - Document Schema
Compatibility", OASIS Committee Specification 3 December 2001, Definition Languages (DSDL) - Part 8: Document Semantics
December 2001. Renaming Language - DSRL", ISO/IEC 19757-8:2008(E),
12 2008.
[9] Kunze, J., "The Dublin Core Metadata Element Set", RFC 5013, [NVDL] ISO/IEC, "Information Technology - Document Schema
August 2007. Definition Languages (DSDL) - Part 4: Namespace-Based
Validation Dispatching Language (NVDL)", ISO/
IEC 19757-4:2006(E), 6 2006.
[10] Chisholm, S. and H. Trevino, "NETCONF Event Notifications", [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
RFC 5277, July 2008. Requirement Levels", BCP 14, RFC 2119, March 1997.
[11] ISO/IEC, "Information Technology - Document Schema Definition [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
Languages (DSDL) - Part 8: Document Semantics Renaming Language January 2004.
- DSRL", ISO/IEC 19757-8:2008(E), 12 2008.
[12] ISO/IEC, "Information Technology - Document Schema Definition [RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741,
Languages (DSDL) - Part 2: Regular-Grammar-Based Validation - December 2006.
RELAX NG. Second Edition.", ISO/IEC 19757-2:2008(E), 12 2008.
[13] ISO/IEC, "Information Technology - Document Schema Definition [RFC5013] Kunze, J., "The Dublin Core Metadata Element Set",
Languages (DSDL) - Part 3: Rule-Based Validation - Schematron", RFC 5013, August 2007.
ISO/IEC 19757-3:2006(E), 6 2006.
[14] Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, "XML [RNG] ISO/IEC, "Information Technology - Document Schema
Schema Part 1: Structures Second Edition", World Wide Web Definition Languages (DSDL) - Part 2: Regular-Grammar-
Consortium Recommendation REC-xmlschema-1-20041028, Based Validation - RELAX NG. Second Edition.", ISO/
October 2004, IEC 19757-2:2008(E), 12 2008.
<http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>.
[15] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and F. [RNG-CS] ISO/IEC, "Information Technology - Document Schema
Yergeau, "Extensible Markup Language (XML) 1.0 (Fourth Definition Languages (DSDL) - Part 2: Regular-Grammar-
Edition)", World Wide Web Consortium Recommendation REC-xml- Based Validation - RELAX NG. AMENDMENT 1: Compact Syntax",
20060816, August 2006, ISO/IEC 19757-2:2003/Amd. 1:2006(E), 1 2006.
<http://www.w3.org/TR/2006/REC-xml-20060816>.
[16] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes Second [RNG-DTD] Clark, J., Ed. and M. Murata, Ed., "RELAX NG DTD
Edition", World Wide Web Consortium Recommendation REC- Compatibility", OASIS Committee Specification 3 December
xmlschema-2-20041028, October 2004, 2001, December 2001.
<http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.
[17] ISO/IEC, "Information Technology - Document Schema Definition [Schematron]
Languages (DSDL) - Part 2: Regular-Grammar-Based Validation - ISO/IEC, "Information Technology - Document Schema
RELAX NG. AMENDMENT 1: Compact Syntax", ISO/IEC 19757-2:2003/ Definition Languages (DSDL) - Part 3: Rule-Based
Amd. 1:2006(E), 1 2006. Validation - Schematron", ISO/IEC 19757-3:2006(E), 6 2006.
[18] Clark, J. and S. DeRose, "XML Path Language (XPath) Version [XML] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and
1.0", World Wide Web Consortium Recommendation REC-xpath- F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fourth
19991116, November 1999, Edition)", World Wide Web Consortium Recommendation REC-
<http://www.w3.org/TR/1999/REC-xpath-19991116>. xml-20060816, August 2006,
<http://www.w3.org/TR/2006/REC-xml-20060816>.
[19] Clark, J., "XSL Transformations (XSLT) Version 1.0", World Wide [XPath] Clark, J. and S. DeRose, "XML Path Language (XPath)
Web Consortium Recommendation REC-xslt-19991116, November 1999. Version 1.0", World Wide Web Consortium
Recommendation REC-xpath-19991116, November 1999,
<http://www.w3.org/TR/1999/REC-xpath-19991116>.
[20] Schoenwaelder, J., Ed., "Common YANG Data Types", [XSD-D] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes
draft-ietf-netmod-yang-types-01 (work in progress), Second Edition", World Wide Web Consortium
November 2008. Recommendation REC-xmlschema-2-20041028, October 2004,
<http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.
[21] van der Vlist, E., "RELAX NG", O'Reilly , 2004. [XSLT] Clark, J., "XSL Transformations (XSLT) Version 1.0", World
Wide Web Consortium Recommendation REC-xslt-19991116,
November 1999.
[22] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [YANG] Bjorklund, M., Ed., "YANG - A data modeling language for
January 2004. NETCONF", draft-ietf-netmod-yang-04 (work in progress),
March 2009.
[23] <http://www.thaiopensource.com/relaxng/trang.html> 16.2. Informative References
[24] <http://dublincore.org/> [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin,
"Simple Network Management Protocol (SNMP)", STD 15,
RFC 1157, May 1990.
[25] <http://www.saxonica.com/> [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Structure of Management Information
Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[26] <http://www.yang-central.org/twiki/bin/view/Main/DhcpTutorial> [RFC3216] Elliott, C., Harrington, D., Jason, J., Schoenwaelder, J.,
Strauss, F., and W. Weiss, "SMIng Objectives", RFC 3216,
December 2001.
[27] <http://code.google.com/p/pyang/> [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event
Notifications", RFC 5277, July 2008.
[28] <http://thaiopensource.com/relaxng/trang.html> [Vli04] van der Vlist, E., "RELAX NG", O'Reilly , 2004.
Appendix A. RELAX NG Schema for NETMOD-specific Annotations [XSD] Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn,
"XML Schema Part 1: Structures Second Edition", World Wide
Web Consortium Recommendation REC-xmlschema-1-20041028,
October 2004,
<http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>.
This appendix contains the RELAX NG schema for the NETMOD-specific [Ytypes] Schoenwaelder, J., Ed., "Common YANG Data Types",
annotations in both XML and compact syntax. draft-ietf-netmod-yang-types-03 (work in progress),
May 2009.
[Editor's note: It is currently only a set of named pattern URIs
definitions as templates for the annotation elements and attributes.
We should find a way how to connect this to the schema for RELAX NG,
which these annotations extend. One option may be NVDL or it can
also be done as in the spec for DTD compatibility annotations.]
A.1. XML Syntax [1] <http://www.thaiopensource.com/relaxng/trang.html>
[2] <http://dublincore.org/>
[3] <http://www.saxonica.com/>
[4] <http://www.yang-central.org/twiki/bin/view/Main/DhcpTutorial>
[5] <http://code.google.com/p/pyang/>
[6] <http://thaiopensource.com/relaxng/trang.html>
Appendix A. Schemas for NETMOD-Specific Annotations
This appendix utilizes Namespace-Based Validation Dispatching
Language (NVDL, Part 4 of DSDL) [NVDL] to define NETMOD-specific
annotations as extensions of the RELAX NG language. The NVDL schema
may be used for validating conceptual tree schemas as compound XML
documents consisting of RELAX NG sections and embedded sections with
NETMOD-specific annotations. The NVDL schema dispatches the
validation as follows:
1. RELAX NG sections identified by the namespace URI
"http://relaxng.org/ns/structure/1.0" is validated with the
standard RELAX NG schema for RELAX NG, see [RNG], Annex A.
2. NETMOD-specific annotation sections identified by the namespace
URI "urn:ietf:params:xml:ns:netmod:dsdl-annotations:1" are
validated by several context-dependent RELAX NG schemas given
below.
3. Other sections such as Dublin Core metadata or <a:documentation>
annotation are attached to and validated together with the parent
RELAX NG section.
A.1. NVDL Schema
== CODE BEGINS: file "nmannot.nvdl"
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE nvdl:rules [<!ENTITY nmannot-uri
"urn:ietf:params:xml:ns:netmod:dsdl-annotations:1">
]>
<rules xmlns="http://purl.oclc.org/dsdl/nvdl/ns/structure/1.0"
startMode="rng">
<mode name="rng">
<namespace ns="http://relaxng.org/ns/structure/1.0">
<validate schema="http://relaxng.org/relaxng.rng"
useMode="other">
<context path="define" useMode="define"/>
<context path="oneOrMore/element" useMode="list"/>
<context path="element" useMode="element"/>
<context path="choice/group|choice/interleave"
useMode="group-interleave"/>
<context path="choice|ref" useMode="choice-ref"/>
<context path="value" useMode="value"/>
</validate>
</namespace>
</mode>
<mode name="define">
<namespace ns="&nmannot-uri;" match="attributes">
<validate schema="define.rng"/>
</namespace>
</mode>
<mode name="element">
<namespace ns="&nmannot-uri;" match="elements">
<validate schema="element-el.rng"/>
</namespace>
<namespace ns="&nmannot-uri;" match="attributes">
<validate schema="element-att.rng"/>
</namespace>
</mode>
<mode name="group-interleave">
<namespace ns="&nmannot-uri;" match="attributes">
<validate schema="group-interleave.rng"/>
</namespace>
</mode>
<mode name="choice-ref">
<namespace ns="&nmannot-uri;" match="attributes">
<validate schema="choice-ref.rng"/>
</namespace>
</mode>
<mode name="list">
<namespace ns="&nmannot-uri;" match="attributes">
<validate schema="list.rng"/>
</namespace>
</mode>
<mode name="value">
<namespace ns="&nmannot-uri;" match="attributes">
<validate schema="value.rng"/>
</namespace>
</mode>
<mode name="other">
<namespace ns="&nmannot-uri;" match="elements attributes">
<reject/>
</namespace>
<anyNamespace match="elements attributes">
<attach/>
</anyNamespace>
</mode>
</rules>
== CODE ENDS
A.2. Annotation Attributes for define Pattern
== CODE BEGINS: file "define.rng"
<?xml version="1.0" encoding="UTF-8"?>
<grammar xmlns="http://relaxng.org/ns/structure/1.0">
<include href="nmannotdefs.rng"/>
<start>
<group>
<ref name="default-attribute"/>
<ref name="status-attribute"/>
<ref name="units-attribute"/>
</group>
</start>
</grammar>
== CODE ENDS
A.3. Annotation Elements for element Pattern
== CODE BEGINS: file "element-el.rng"
<?xml version="1.0" encoding="UTF-8"?>
<grammar xmlns="http://relaxng.org/ns/structure/1.0">
<include href="nmannotdefs.rng"/>
<start>
<choice>
<ref name="must-element"/>
<ref name="instance-identifier-element"/>
</choice>
</start>
</grammar>
== CODE ENDS
A.4. Annotation Attributes for element Pattern
== CODE BEGINS: file "element-att.rng"
<?xml version="1.0" encoding="UTF-8"?>
<grammar xmlns="http://relaxng.org/ns/structure/1.0">
<include href="nmannotdefs.rng"/>
<start>
<group>
<ref name="config-attribute"/>
<ref name="default-attribute"/>
<ref name="implicit-attribute"/>
<ref name="leafref-attribute"/>
<ref name="presence-attribute"/>
<ref name="status-attribute"/>
<ref name="units-attribute"/>
<ref name="when-attribute"/>
</group>
</start>
</grammar>
== CODE ENDS
A.5. Annotation attributes for group Pattern
== CODE BEGINS: file "group-interleave.rng"
<?xml version="1.0" encoding="UTF-8"?>
<grammar xmlns="http://relaxng.org/ns/structure/1.0">
<include href="nmannotdefs.rng"/>
<start>
<group>
<ref name="implicit-attribute"/>
<ref name="status-attribute"/>
<ref name="when-attribute"/>
</group>
</start>
</grammar>
== CODE ENDS
A.6. Annotation attributes for choice and ref Patterns
== CODE BEGINS: file "choice-ref.rng"
<?xml version="1.0" encoding="UTF-8"?>
<grammar xmlns="http://relaxng.org/ns/structure/1.0">
<include href="nmannotdefs.rng"/>
<start>
<group>
<ref name="status-attribute"/>
<ref name="when-attribute"/>
</group>
</start>
</grammar>
== CODE ENDS
A.7. Annotation attributes for element Pattern in the List Context
== CODE BEGINS: file "list.rng"
<?xml version="1.0" encoding="UTF-8"?>
<grammar xmlns="http://relaxng.org/ns/structure/1.0">
<include href="nmannotdefs.rng"/>
<start>
<group>
<ref name="key-attribute"/>
<ref name="min-elements-attribute"/>
<ref name="max-elements-attribute"/>
<ref name="ordered-by-attribute"/>
<ref name="unique-attribute"/>
</group>
</start>
</grammar>
== CODE ENDS
A.8. Annotation attributes for value Pattern
== CODE BEGINS: file "value.rng"
<?xml version="1.0" encoding="UTF-8"?>
<grammar xmlns="http://relaxng.org/ns/structure/1.0">
<include href="nmannotdefs.rng"/>
<start>
<ref name="status-attribute"/>
</start>
</grammar>
== CODE ENDS
A.9. Named Patterns for All NETMOD-Specific Annotations
== CODE BEGINS: file "nmannotdefs.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:nma="urn:ietf:params:xml:ns:netmod:dsdl-annotations:1" xmlns:nma="urn:ietf:params:xml:ns:netmod:dsdl-annotations:1"
datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes"> datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes">
<define name="config-attribute"> <define name="config-attribute">
<attribute name="nma:config"> <optional>
<data type="boolean"/> <attribute name="nma:config">
</attribute> <data type="boolean"/>
</attribute>
</optional>
</define> </define>
<define name="default-attribute"> <define name="default-attribute">
<attribute name="nma:default"/> <optional>
<attribute name="nma:default"/>
</optional>
</define> </define>
<define name="implicit-attribute"> <define name="implicit-attribute">
<attribute name="nma:implicit"> <optional>
<data type="boolean"/> <attribute name="nma:implicit">
</attribute> <data type="boolean"/>
</attribute>
</optional>
</define> </define>
<define name="error-app-tag-element"> <define name="error-app-tag-element">
<optional> <optional>
<element name="nma:error-app-tag"> <element name="nma:error-app-tag">
<text/> <text/>
</element> </element>
</optional> </optional>
</define> </define>
skipping to change at page 79, line 18 skipping to change at page 93, line 28
<element name="nma:instance-identifier"> <element name="nma:instance-identifier">
<optional> <optional>
<attribute name="nma:require-instance"> <attribute name="nma:require-instance">
<data type="boolean"/> <data type="boolean"/>
</attribute> </attribute>
</optional> </optional>
</element> </element>
</define> </define>
<define name="key-attribute"> <define name="key-attribute">
<attribute name="nma:key"> <optional>
<list> <attribute name="nma:key">
<data type="QName"/> <list>
</list> <data type="QName"/>
</attribute> </list>
</attribute>
</optional>
</define> </define>
<define name="leafref-attribute"> <define name="leafref-attribute">
<attribute name="nma:leafref"> <optional>
<data type="string"/> <attribute name="nma:leafref">
</element> <data type="string"/>
</attribute>
</optional>
</define> </define>
<define name="min-elements-attribute"> <define name="min-elements-attribute">
<attribute name="nma:min-elements"> <optional>
<data type="integer"/> <attribute name="nma:min-elements">
</attribute> <data type="nonNegativeInteger"/>
</attribute>
</optional>
</define> </define>
<define name="max-elements-attribute"> <define name="max-elements-attribute">
<attribute name="nma:max-elements"> <optional>
<data type="integer"/> <attribute name="nma:max-elements">
</attribute> <data type="nonNegativeInteger"/>
</attribute>
</optional>
</define> </define>
<define name="must-element"> <define name="must-element">
<element name="nma:must"> <element name="nma:must">
<attribute name="nma:assert"> <attribute name="assert">
<data type="string"/> <data type="string"/>
</attribute> </attribute>
<interleave> <interleave>
<ref name="err-app-tag-element"/> <ref name="error-app-tag-element"/>
<ref name="err-message-element"/> <ref name="error-message-element"/>
</interleave> </interleave>
</element> </element>
</define> </define>
<define name="ordered-by-attribute"> <define name="ordered-by-attribute">
<attribute name="nma:ordered-by"> <optional>
<choice> <attribute name="nma:ordered-by">
<value>user</value> <choice>
<value>system</value> <value>user</value>
</choice> <value>system</value>
</attribute> </choice>
</attribute>
</optional>
</define> </define>
<define name="presence-attribute"> <define name="presence-attribute">
<attribute name="nma:presence"> <optional>
<value>true</value> <attribute name="nma:presence">
</attribute> <value>true</value>
</attribute>
</optional>
</define> </define>
<define name="status-attribute"> <define name="status-attribute">
<attribute name="nma:status"> <optional>
<choice> <attribute name="nma:status">
<value>current</value> <choice>
<value>deprecated</value> <value>current</value>
<value>obsolete</value> <value>deprecated</value>
</choice> <value>obsolete</value>
</attribute> </choice>
</attribute>
</optional>
</define> </define>
<define name="unique-attribute"> <define name="unique-attribute">
<attribute name="nma:unique"> <optional>
<list> <attribute name="nma:unique">
<data type="string"/> <list>
</list> <data type="token"/>
</attribute> </list>
</attribute>
</optional>
</define> </define>
<define name="units-attribute"> <define name="units-attribute">
<attribute name="nma:units"> <optional>
<data type="string"/> <attribute name="nma:units">
</attribute> <data type="string"/>
</attribute>
</optional>
</define> </define>
<define name="when-attribute"> <define name="when-attribute">
<attribute name="nma:when"> <optional>
<data type="string"/> <attribute name="nma:when">
</attribute> <data type="string"/>
</attribute>
</optional>
</define> </define>
</grammar> </grammar>
A.2. Compact Syntax == CODE ENDS
namespace nma = "urn:ietf:params:xml:ns:netmod:dsdl-annotations:1"
config-attribute = attribute nma:config { xsd:boolean }
default-attribute = attribute nma:default { text }
implicit-attribute = attribute nma:implicit { xsd:boolean }
error-app-tag-element = element nma:error-app-tag { text }?
error-message-element = element nma:error-message { text }?
instance-identifier-element =
element nma:instance-identifier {
attribute nma:require-instance { xsd:boolean }?
}
key-attribute =
attribute nma:key {
list { xsd:QName }
}
leafref-element =
attribute nma:leafref {
xsd:string
}
min-elements-attribute = attribute nma:min-elements { xsd:integer }
max-elements-attribute = attribute nma:max-elements { xsd:integer }
must-element =
element nma:must {
attribute nma:assert { xsd:string },
(err-app-tag-element & err-message-element)
}
ordered-by-attribute = attribute nma:ordered-by { "user" | "system" }
presence-attribute = attribute nma:presence { "true" }
status-attribute =
attribute nma:status { "current" | "deprecated" | "obsolete" }
unique-attribute =
attribute nma:unique {
list { xsd:string }
}
units-attribute = attribute nma:units { xsd:string }
when-attribute = attribute nma:when { xsd:string }
Appendix B. Schema-Independent Library Appendix B. Schema-Independent Library
In order to avoid copying the same named pattern definitions to the In order to avoid copying the same named pattern definitions to the
RELAX NG schemas generated in the second mapping step, we collected RELAX NG schemas generated in the second mapping step, we collected
these definitions to a library file - schema-independent library - these definitions to a library file - schema-independent library -
which is included by the validating schemas under the file name which is included by the validating schemas under the file name
"relaxng-lib.rng" (XML syntax) and "relaxng-lib.rnc" (compact "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 [1] and event notifications [10]. from base NETCONF [RFC4741] and event notifications [RFC5277].
B.1. XML Syntax == CODE BEGINS: file "relaxng-lib.rng"
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<!-- Library of RELAX NG pattern definitions -->
<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"
xmlns:en="urn:ietf:params:xml:ns:netconf:notification:1.0" xmlns:en="urn:ietf:params:xml:ns:netconf:notification:1.0"
datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes"> datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes">
<define name="message-id-attribute"> <define name="message-id-attribute">
<attribute name="message-id"> <attribute name="message-id">
<data type="string"> <data type="string">
<param name="maxLength">4095</param> <param name="maxLength">4095</param>
</data> </data>
skipping to change at page 83, line 5 skipping to change at page 96, line 45
</element> </element>
</define> </define>
<define name="eventTime-element"> <define name="eventTime-element">
<element name="en:eventTime"> <element name="en:eventTime">
<data type="dateTime"/> <data type="dateTime"/>
</element> </element>
</define> </define>
</grammar> </grammar>
B.2. Compact Syntax == CODE ENDS
# Library of RELAX NG pattern definitions
namespace en = "urn:ietf:params:xml:ns:netconf:notification:1.0"
namespace nc = "urn:ietf:params:xml:ns:netconf:base:1.0"
message-id-attribute =
attribute message-id {
xsd:string { maxLength = "4095" }
}
ok-element = element nc:ok { empty }
eventTime-element = element en:eventTime { xsd:dateTime }
Appendix C. Mapping DHCP Data Model - A Complete Example Appendix C. Mapping DHCP Data Model - A Complete Example
This appendix demonstrates both steps of the YANG-to-DSDL mapping This appendix demonstrates both steps of the YANG-to-DSDL mapping
applied to the "canonical" DHCP tutorial [26] data model. The input applied to the "canonical" DHCP tutorial [4] data model. The input
(single) YANG module is shown in Appendix C.1 and the output schemas (single) YANG module is shown in Appendix C.1 and the output schemas
in the following two subsections. in the following two subsections.
The conceptual tree schema was obtained by the "rng" plugin of the The conceptual tree schema was obtained by the "rng" plugin of the
pyang [27] tool and the validating DSDL schemas by XSLT stylesheets pyang [5] tool and the validating DSDL schemas by XSLT stylesheets
that are also part of pyang distribution. RELAX NG schemas are shown that are also part of pyang distribution. RELAX NG schemas are shown
in both XML and compact syntax. The latter was obtained from the in both XML and compact syntax. The latter was obtained from the
former by using the Trang tool [28] former by using the Trang tool [6]
Due to the limit of 72 characters per line, few long strings required Due to the limit of 72 characters per line, few long strings required
manual editing, in particular the regular expression patterns for IP manual editing, in particular the regular expression patterns for IP
addresses etc. in the RELAX NG schemas. In the compact syntax we addresses etc. in the RELAX NG schemas. In the compact syntax we
broke the patterns to appropriate segments and joined them with the broke the patterns to appropriate segments and joined them with the
concatenation operator "~". In the XML syntax, though, the long concatenation operator "~". In the XML syntax, though, the long
patterns had to be replaced by the placeholder string "... regex patterns had to be replaced by the placeholder string "... regex
pattern ...". Also, line breaks were added to several documentation pattern ...". Also, line breaks were added to several documentation
strings and Schematron messages. Other than that, the results of the strings and Schematron messages. Other than that, the results of the
automatic translations were not changed. automatic translations were not 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 yang-types { prefix yang; } import ietf-yang-types { prefix yang; }
import inet-types { prefix inet; } import ietf-inet-types { prefix inet; }
organization organization
"yang-central.org"; "yang-central.org";
description description
"Partial data model for DHCP, based on the config of "Partial data model for DHCP, based on the config of
the ISC DHCP reference implementation."; the ISC DHCP reference implementation.";
container dhcp { container dhcp {
description description
"configuration and operational parameters for a DHCP server."; "configuration and operational parameters for a DHCP server.";
skipping to change at page 104, line 7 skipping to change at page 117, line 7
/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 Appendix D. Change Log
D.1. Changes Between Versions -02 and -03 D.1. 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
RPCs) 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 15 (Acknowledgements).
o Removed compact syntax schema from Appendix B.
o Editorial changes: symbolic citation labels.
D.2. Changes Between Versions -02 and -03
o Changed @nma:default-case to @nma:implicit. o Changed @nma:default-case to @nma:implicit.
o Changed nma:leafref annotation from element to attribute. o Changed nma:leafref annotation from element to attribute.
o Added skeleton rule to Section 9.2. o Added skeleton rule to Section 10.2.
o Reworked Section 9.4, added skeleton element maps,corrected the o Reworked Section 10.4, added skeleton element maps,corrected the
example. example.
o Added section Section 7.5 on 'feature' and 'deviation'. o Added Section 8.5 on 'feature' and 'deviation'.
o New Section 8.1 integrating discussion of both optional/mandatory o New Section 9.1 integrating discussion of both optional/mandatory
(was in -02) and implicit nodes (new). (was in -02) and implicit nodes (new).
o Reflected that key argument and schema node identifiers are no o Reflected that key argument and schema node identifiers are no
more XPath (should be in yang-07). more XPath (should be in yang-07).
o Element patterns for implicit containers now must have @nma: o Element patterns for implicit containers now must have @nma:
implicit attribute. implicit attribute.
o Removed "float32" and "float64" types and added mapping of o Removed "float32" and "float64" types and added mapping of
"decimal64" with example. "decimal64" with example.
o Removed mapping of 'require-instance' for "leafref" type. o Removed mapping of 'require-instance' for "leafref" type.
o Updated RELAX NG schema for NETMOD-specific annotations. o Updated RELAX NG schema for NETMOD-specific annotations.
o Updated the DHCP example. o Updated the DHCP example.
o Many minor corrections and clarifications. D.3. Changes Between Versions -01 and -02
D.2. Changes Between Versions -01 and -02
o Moved Section 6 "NETCONF Content Validation" after Section 5. o Moved Section 7 "NETCONF Content Validation" after Section 6.
o New text about mapping defaults to DSRL, especially in Section 6 o New text about mapping defaults to DSRL, especially in Section 7
and Section 9.4. and Section 10.4.
o Finished the DHCP example by adding the DSRL schema to Appendix C. 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 o New @nma:presence annotation was added - it is needed for proper
handling of default content. handling of default content.
o Section 9.3 "Constraints on Mandatory Choice" was added because o Section 10.3 "Constraints on Mandatory Choice" was added because
these constraints require a combination of RELAX NG and these constraints require a combination of RELAX NG and
Schematron. Schematron.
o Fixed the schema for NETMOD-specific annotations by adding o Fixed the schema for NETMOD-specific annotations by adding
explicit prefix to all defined elements and attributes. explicit prefix to all defined elements and attributes.
Previously, the attributes had no namespace. Previously, the attributes had no namespace.
o Handling of 'feature', 'if-feature' and 'deviation' added. o Handling of 'feature', 'if-feature' and 'deviation' added.
o Handling of nma:instance-identifier via XSLT extension function. o Handling of nma:instance-identifier via XSLT extension function.
o Many other minor corrections and improvements. D.4. Changes Between Versions -00 and -01
D.3. Changes Between Versions -00 and -01
o Attributes @nma:min-elements and @nma:max-elements are attached to o Attributes @nma:min-elements and @nma:max-elements are attached to
<rng:element> (list entry) and not to <rng:zeroOrMore> or <rng: <rng:element> (list entry) and not to <rng:zeroOrMore> or <rng:
oneOrMore>. oneOrMore>.
o Keys and all node identifiers in 'key' and 'unique' statements are o Keys and all node identifiers in 'key' and 'unique' statements are
prefixed. prefixed.
o Fixed the mapping of 'rpc' and 'notification'. o Fixed the mapping of 'rpc' and 'notification'.
o Removed previous sec. 7.5 "RPC Signatures and Notifications" - the o Removed previous sec. 7.5 "RPC Signatures and Notifications" - the
same information is now contained in Section 10.50 and same information is now contained in Section 11.50 and
Section 10.37. Section 11.37.
o Added initial "_" to mangled names of groupings. o Added initial "_" to mangled names of groupings.
o Mandated the use of @xmlns:xxx as the only method for declaring o Mandated the use of @xmlns:xxx as the only method for declaring
the target namespace. the target namespace.
o Added section "Handling of XML Namespaces" to explain the previous o Added section "Handling of XML Namespaces" to explain the previous
item. item.
o Completed DHCP example in Appendix C. o Completed DHCP example in Appendix C.
 End of changes. 420 change blocks. 
872 lines changed or deleted 1360 lines changed or added

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