draft-ietf-netmod-dsdl-map-04.txt   draft-ietf-netmod-dsdl-map-05.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: April 22, 2010 Plantronics Expires: September 3, 2010 Plantronics
S. Chisholm S. Chisholm
Nortel Nortel
October 19, 2009 March 2, 2010
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-04 draft-ietf-netmod-dsdl-map-05
Abstract
This draft specifies the mapping rules for translating YANG data
models into Document Schema Definition Languages (DSDL), a
coordinated set of XML schema languages standardized as ISO 19757.
The following DSDL schema languages are used by the mapping: RELAX
NG, Schematron and DSRL. The mapping takes one or more YANG modules
and produces a set of DSDL schemas for a selected target document
type - datastore content, NETCONF PDU etc. Procedures for schema-
based validation of such documents are also discussed.
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 47
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 April 22, 2010. This Internet-Draft will expire on September 3, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 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
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
This draft specifies the mapping rules for translating YANG data described in the BSD License.
models into Document Schema Definition Languages (DSDL), a
coordinated set of XML schema languages standardized as ISO 19757.
The following DSDL schema languages are used by the mapping: RELAX
NG, Schematron and DSRL. The mapping takes one or more YANG modules
and produces a set of DSDL schemas for a selected target document
type - datastore content, NETCONF PDU etc. Procedures for schema-
based validation of such documents are also discussed.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6
2. Terminology and Notation . . . . . . . . . . . . . . . . . . 7 2. Terminology and Notation . . . . . . . . . . . . . . . . . . 7
2.1. Glossary of New Terms . . . . . . . . . . . . . . . . . 8 2.1. Glossary of New Terms . . . . . . . . . . . . . . . . . 8
3. Objectives and Motivation . . . . . . . . . . . . . . . . . . 10 3. Objectives and Motivation . . . . . . . . . . . . . . . . . . 10
4. DSDL Schema Languages . . . . . . . . . . . . . . . . . . . . 12 4. DSDL Schema Languages . . . . . . . . . . . . . . . . . . . . 12
4.1. RELAX NG . . . . . . . . . . . . . . . . . . . . . . . . 12 4.1. RELAX NG . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2. Schematron . . . . . . . . . . . . . . . . . . . . . . . 13 4.2. Schematron . . . . . . . . . . . . . . . . . . . . . . . 13
skipping to change at page 2, line 44 skipping to change at page 2, line 45
8.2. Modularity . . . . . . . . . . . . . . . . . . . . . . . 23 8.2. Modularity . . . . . . . . . . . . . . . . . . . . . . . 23
8.3. Granularity . . . . . . . . . . . . . . . . . . . . . . 24 8.3. Granularity . . . . . . . . . . . . . . . . . . . . . . 24
8.4. Handling of XML Namespaces . . . . . . . . . . . . . . . 24 8.4. Handling of XML Namespaces . . . . . . . . . . . . . . . 24
8.5. Features and Deviations . . . . . . . . . . . . . . . . 25 8.5. Features and Deviations . . . . . . . . . . . . . . . . 25
9. Mapping YANG Data Models to the Conceptual Tree Schema . . . 26 9. Mapping YANG Data Models to the Conceptual Tree Schema . . . 26
9.1. Occurrence Rules for Data Nodes . . . . . . . . . . . . 26 9.1. Occurrence Rules for Data Nodes . . . . . . . . . . . . 26
9.1.1. Optional and Mandatory Nodes . . . . . . . . . . . 27 9.1.1. Optional and Mandatory Nodes . . . . . . . . . . . 27
9.1.2. Implicit Nodes . . . . . . . . . . . . . . . . . . 28 9.1.2. Implicit Nodes . . . . . . . . . . . . . . . . . . 28
9.2. Mapping YANG Groupings and Typedefs . . . . . . . . . . 29 9.2. Mapping YANG Groupings and Typedefs . . . . . . . . . . 29
9.2.1. YANG Refinements and Augments . . . . . . . . . . . 31 9.2.1. YANG Refinements and Augments . . . . . . . . . . . 31
9.2.2. Type derivation chains . . . . . . . . . . . . . . 34 9.2.2. Type Derivation Chains . . . . . . . . . . . . . . 34
9.3. Translation of XPath Expressions . . . . . . . . . . . . 37 9.3. Translation of XPath Expressions . . . . . . . . . . . . 37
9.4. YANG Language Extensions . . . . . . . . . . . . . . . . 37 9.4. YANG Language Extensions . . . . . . . . . . . . . . . . 37
10. Mapping Conceptual Tree Schema to DSDL . . . . . . . . . . . 39 10. Mapping Conceptual Tree Schema to DSDL . . . . . . . . . . . 39
10.1. Generating RELAX NG Schemas for Various Document Types . 39 10.1. Generating RELAX NG Schemas for Various Document Types . 39
10.1.1. Reply to <get> or <get-config> . . . . . . . . . . 40 10.1.1. Reply to <get> or <get-config> . . . . . . . . . . 40
10.1.2. Remote Procedure Calls . . . . . . . . . . . . . . 40 10.1.2. Remote Procedure Calls . . . . . . . . . . . . . . 40
10.1.3. Notifications . . . . . . . . . . . . . . . . . . . 41 10.1.3. Notifications . . . . . . . . . . . . . . . . . . . 41
10.2. Mapping Semantic Constraints to Schematron . . . . . . . 42 10.2. Mapping Semantic Constraints to Schematron . . . . . . . 42
10.2.1. Validation Phases . . . . . . . . . . . . . . . . . 45 10.2.1. Validation Phases . . . . . . . . . . . . . . . . . 45
10.3. Constraints on Mandatory Choice . . . . . . . . . . . . 46 10.3. Constraints on Mandatory Choice . . . . . . . . . . . . 46
10.4. Mapping Default Values to DSRL . . . . . . . . . . . . . 48 10.4. Mapping Default Values to DSRL . . . . . . . . . . . . . 48
11. Mapping YANG Statements to Conceptual Tree Schema . . . . . . 53 11. Mapping YANG Statements to Conceptual Tree Schema . . . . . . 52
11.1. The anyxml Statement . . . . . . . . . . . . . . . . . . 53 11.1. The anyxml Statement . . . . . . . . . . . . . . . . . . 52
11.2. The argument Statement . . . . . . . . . . . . . . . . . 54 11.2. The argument Statement . . . . . . . . . . . . . . . . . 53
11.3. The augment Statement . . . . . . . . . . . . . . . . . 55 11.3. The augment Statement . . . . . . . . . . . . . . . . . 54
11.4. The base Statement . . . . . . . . . . . . . . . . . . . 55 11.4. The base Statement . . . . . . . . . . . . . . . . . . . 54
11.5. The belongs-to Statement . . . . . . . . . . . . . . . . 55 11.5. The belongs-to Statement . . . . . . . . . . . . . . . . 54
11.6. The bit Statement . . . . . . . . . . . . . . . . . . . 55 11.6. The bit Statement . . . . . . . . . . . . . . . . . . . 54
11.7. The case Statement . . . . . . . . . . . . . . . . . . . 55 11.7. The case Statement . . . . . . . . . . . . . . . . . . . 54
11.8. The choice Statement . . . . . . . . . . . . . . . . . . 55 11.8. The choice Statement . . . . . . . . . . . . . . . . . . 54
11.9. The config Statement . . . . . . . . . . . . . . . . . . 56 11.9. The config Statement . . . . . . . . . . . . . . . . . . 55
11.10. The contact Statement . . . . . . . . . . . . . . . . . 56 11.10. The contact Statement . . . . . . . . . . . . . . . . . 55
11.11. The container Statement . . . . . . . . . . . . . . . . 56 11.11. The container Statement . . . . . . . . . . . . . . . . 55
11.12. The default Statement . . . . . . . . . . . . . . . . . 56 11.12. The default Statement . . . . . . . . . . . . . . . . . 55
11.13. The description Statement . . . . . . . . . . . . . . . 57 11.13. The description Statement . . . . . . . . . . . . . . . 57
11.14. The deviation Statement . . . . . . . . . . . . . . . . 58 11.14. The deviation Statement . . . . . . . . . . . . . . . . 57
11.15. The enum Statement . . . . . . . . . . . . . . . . . . . 58 11.15. The enum Statement . . . . . . . . . . . . . . . . . . . 57
11.16. The error-app-tag Statement . . . . . . . . . . . . . . 58 11.16. The error-app-tag Statement . . . . . . . . . . . . . . 57
11.17. The error-message Statement . . . . . . . . . . . . . . 58 11.17. The error-message Statement . . . . . . . . . . . . . . 57
11.18. The extension Statement . . . . . . . . . . . . . . . . 58 11.18. The extension Statement . . . . . . . . . . . . . . . . 57
11.19. The feature Statement . . . . . . . . . . . . . . . . . 58 11.19. The feature Statement . . . . . . . . . . . . . . . . . 57
11.20. The grouping Statement . . . . . . . . . . . . . . . . . 58 11.20. The grouping Statement . . . . . . . . . . . . . . . . . 57
11.21. The identity Statement . . . . . . . . . . . . . . . . . 59 11.21. The identity Statement . . . . . . . . . . . . . . . . . 58
11.22. The if-feature Statement . . . . . . . . . . . . . . . . 59 11.22. The if-feature Statement . . . . . . . . . . . . . . . . 58
11.23. The import Statement . . . . . . . . . . . . . . . . . . 59 11.23. The import Statement . . . . . . . . . . . . . . . . . . 58
11.24. The include Statement . . . . . . . . . . . . . . . . . 59 11.24. The include Statement . . . . . . . . . . . . . . . . . 58
11.25. The input Statement . . . . . . . . . . . . . . . . . . 59 11.25. The input Statement . . . . . . . . . . . . . . . . . . 59
11.26. The key Statement . . . . . . . . . . . . . . . . . . . 59 11.26. The key Statement . . . . . . . . . . . . . . . . . . . 59
11.27. The leaf Statement . . . . . . . . . . . . . . . . . . . 60 11.27. The leaf Statement . . . . . . . . . . . . . . . . . . . 59
11.28. The leaf-list Statement . . . . . . . . . . . . . . . . 60 11.28. The leaf-list Statement . . . . . . . . . . . . . . . . 59
11.29. The length Statement . . . . . . . . . . . . . . . . . . 61 11.29. The length Statement . . . . . . . . . . . . . . . . . . 60
11.30. The list Statement . . . . . . . . . . . . . . . . . . . 61 11.30. The list Statement . . . . . . . . . . . . . . . . . . . 60
11.31. The mandatory Statement . . . . . . . . . . . . . . . . 62 11.31. The mandatory Statement . . . . . . . . . . . . . . . . 61
11.32. The max-elements Statement . . . . . . . . . . . . . . . 62 11.32. The max-elements Statement . . . . . . . . . . . . . . . 61
11.33. The min-elements Statement . . . . . . . . . . . . . . . 62 11.33. The min-elements Statement . . . . . . . . . . . . . . . 62
11.34. The module Statement . . . . . . . . . . . . . . . . . . 62 11.34. The module Statement . . . . . . . . . . . . . . . . . . 62
11.35. The must Statement . . . . . . . . . . . . . . . . . . . 63 11.35. The must Statement . . . . . . . . . . . . . . . . . . . 62
11.36. The namespace Statement . . . . . . . . . . . . . . . . 63 11.36. The namespace Statement . . . . . . . . . . . . . . . . 63
11.37. The notification Statement . . . . . . . . . . . . . . . 63 11.37. The notification Statement . . . . . . . . . . . . . . . 63
11.38. The ordered-by Statement . . . . . . . . . . . . . . . . 64 11.38. The ordered-by Statement . . . . . . . . . . . . . . . . 63
11.39. The organization Statement . . . . . . . . . . . . . . . 64 11.39. The organization Statement . . . . . . . . . . . . . . . 63
11.40. The output Statement . . . . . . . . . . . . . . . . . . 64 11.40. The output Statement . . . . . . . . . . . . . . . . . . 63
11.41. The path Statement . . . . . . . . . . . . . . . . . . . 64 11.41. The path Statement . . . . . . . . . . . . . . . . . . . 63
11.42. The pattern Statement . . . . . . . . . . . . . . . . . 64 11.42. The pattern Statement . . . . . . . . . . . . . . . . . 64
11.43. The position Statement . . . . . . . . . . . . . . . . . 64 11.43. The position Statement . . . . . . . . . . . . . . . . . 64
11.44. The prefix Statement . . . . . . . . . . . . . . . . . . 64 11.44. The prefix Statement . . . . . . . . . . . . . . . . . . 64
11.45. The presence Statement . . . . . . . . . . . . . . . . . 64 11.45. The presence Statement . . . . . . . . . . . . . . . . . 64
11.46. The range Statement . . . . . . . . . . . . . . . . . . 65 11.46. The range Statement . . . . . . . . . . . . . . . . . . 64
11.47. The reference Statement . . . . . . . . . . . . . . . . 65 11.47. The reference Statement . . . . . . . . . . . . . . . . 64
11.48. The require-instance Statement . . . . . . . . . . . . . 65 11.48. The require-instance Statement . . . . . . . . . . . . . 64
11.49. The revision Statement . . . . . . . . . . . . . . . . . 65 11.49. The revision Statement . . . . . . . . . . . . . . . . . 64
11.50. The rpc Statement . . . . . . . . . . . . . . . . . . . 65 11.50. The rpc Statement . . . . . . . . . . . . . . . . . . . 65
11.51. The status Statement . . . . . . . . . . . . . . . . . . 66 11.51. The status Statement . . . . . . . . . . . . . . . . . . 65
11.52. The submodule Statement . . . . . . . . . . . . . . . . 66 11.52. The submodule Statement . . . . . . . . . . . . . . . . 65
11.53. The type Statement . . . . . . . . . . . . . . . . . . . 66 11.53. The type Statement . . . . . . . . . . . . . . . . . . . 65
11.53.1. The empty Type . . . . . . . . . . . . . . . . . . 67 11.53.1. The empty Type . . . . . . . . . . . . . . . . . . 66
11.53.2. The boolean and binary Types . . . . . . . . . . . 67 11.53.2. The boolean and binary Types . . . . . . . . . . . 67
11.53.3. The bits Type . . . . . . . . . . . . . . . . . . . 67 11.53.3. The bits Type . . . . . . . . . . . . . . . . . . . 67
11.53.4. The enumeration and union Types . . . . . . . . . . 68 11.53.4. The enumeration and union Types . . . . . . . . . . 67
11.53.5. The identityref Type . . . . . . . . . . . . . . . 68 11.53.5. The identityref Type . . . . . . . . . . . . . . . 67
11.53.6. The instance-identifier Type . . . . . . . . . . . 70 11.53.6. The instance-identifier Type . . . . . . . . . . . 69
11.53.7. The leafref Type . . . . . . . . . . . . . . . . . 70 11.53.7. The leafref Type . . . . . . . . . . . . . . . . . 69
11.53.8. The numeric Types . . . . . . . . . . . . . . . . . 70 11.53.8. The numeric Types . . . . . . . . . . . . . . . . . 69
11.53.9. The string Type . . . . . . . . . . . . . . . . . . 72 11.53.9. The string Type . . . . . . . . . . . . . . . . . . 71
11.53.10. Derived Types . . . . . . . . . . . . . . . . . . . 73 11.53.10. Derived Types . . . . . . . . . . . . . . . . . . . 72
11.54. The typedef Statement . . . . . . . . . . . . . . . . . 74 11.54. The typedef Statement . . . . . . . . . . . . . . . . . 73
11.55. The unique Statement . . . . . . . . . . . . . . . . . . 74 11.55. The unique Statement . . . . . . . . . . . . . . . . . . 73
11.56. The units Statement . . . . . . . . . . . . . . . . . . 74 11.56. The units Statement . . . . . . . . . . . . . . . . . . 73
11.57. The uses Statement . . . . . . . . . . . . . . . . . . . 74 11.57. The uses Statement . . . . . . . . . . . . . . . . . . . 74
11.58. The value Statement . . . . . . . . . . . . . . . . . . 75 11.58. The value Statement . . . . . . . . . . . . . . . . . . 74
11.59. The when Statement . . . . . . . . . . . . . . . . . . . 75 11.59. The when Statement . . . . . . . . . . . . . . . . . . . 74
11.60. The yang-version Statement . . . . . . . . . . . . . . . 75 11.60. The yang-version Statement . . . . . . . . . . . . . . . 74
11.61. The yin-element Statement . . . . . . . . . . . . . . . 75 11.61. The yin-element Statement . . . . . . . . . . . . . . . 74
12. Mapping NETMOD-specific annotations to DSDL Schema 12. Mapping NETMOD-specific annotations to DSDL Schema
Languages . . . . . . . . . . . . . . . . . . . . . . . . . . 76 Languages . . . . . . . . . . . . . . . . . . . . . . . . . . 75
12.1. The @nma:config Annotation . . . . . . . . . . . . . . . 76 12.1. The @nma:config Annotation . . . . . . . . . . . . . . . 75
12.2. The @nma:default Annotation . . . . . . . . . . . . . . 76 12.2. The @nma:default Annotation . . . . . . . . . . . . . . 75
12.3. The @nma:implicit Annotation . . . . . . . . . . . . . . 76 12.3. The @nma:implicit Annotation . . . . . . . . . . . . . . 75
12.4. The <nma:error-app-tag> Annotation . . . . . . . . . . . 76 12.4. The <nma:error-app-tag> Annotation . . . . . . . . . . . 75
12.5. The <nma:error-message> Annotation . . . . . . . . . . . 76 12.5. The <nma:error-message> Annotation . . . . . . . . . . . 75
12.6. The <nma:instance-identifier> Annotation . . . . . . . . 76 12.6. The <nma:instance-identifier> Annotation . . . . . . . . 75
12.7. The @nma:key Annotation . . . . . . . . . . . . . . . . 77 12.7. The @nma:key Annotation . . . . . . . . . . . . . . . . 76
12.8. The @nma:leafref Annotation . . . . . . . . . . . . . . 77 12.8. The @nma:leafref Annotation . . . . . . . . . . . . . . 76
12.9. The @nma:min-elements Annotation . . . . . . . . . . . . 77 12.9. The @nma:min-elements Annotation . . . . . . . . . . . . 76
12.10. The @nma:max-elements Annotation . . . . . . . . . . . . 78 12.10. The @nma:max-elements Annotation . . . . . . . . . . . . 77
12.11. The <nma:must> Annotation . . . . . . . . . . . . . . . 78 12.11. The <nma:must> Annotation . . . . . . . . . . . . . . . 77
12.12. The <nma:ordered-by> Annotation . . . . . . . . . . . . 78 12.12. The <nma:ordered-by> Annotation . . . . . . . . . . . . 77
12.13. The <nma:status> Annotation . . . . . . . . . . . . . . 78 12.13. The <nma:status> Annotation . . . . . . . . . . . . . . 77
12.14. The @nma:unique Annotation . . . . . . . . . . . . . . . 78 12.14. The @nma:unique Annotation . . . . . . . . . . . . . . . 77
12.15. The @nma:when Annotation . . . . . . . . . . . . . . . . 79 12.15. The @nma:when Annotation . . . . . . . . . . . . . . . . 78
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 80 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 79
14. Security Considerations . . . . . . . . . . . . . . . . . . . 81 14. Security Considerations . . . . . . . . . . . . . . . . . . . 80
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 82 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 81
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 83 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 82
16.1. Normative References . . . . . . . . . . . . . . . . . . 83 16.1. Normative References . . . . . . . . . . . . . . . . . . 82
16.2. Informative References . . . . . . . . . . . . . . . . . 84 16.2. Informative References . . . . . . . . . . . . . . . . . 83
Appendix A. Schemas for NETMOD-Specific Annotations . . . . . . 87 Appendix A. Schemas for NETMOD-Specific Annotations . . . . . . 86
A.1. NVDL Schema . . . . . . . . . . . . . . . . . . . . . . 87 A.1. NVDL Schema . . . . . . . . . . . . . . . . . . . . . . 86
A.2. Annotation Attributes for define Pattern . . . . . . . . 89 A.2. Annotation Attributes for define Pattern . . . . . . . . 88
A.3. Annotation Elements for element Pattern . . . . . . . . 89 A.3. Annotation Elements for element Pattern . . . . . . . . 88
A.4. Annotation Attributes for element Pattern . . . . . . . 90 A.4. Annotation Attributes for element Pattern . . . . . . . 89
A.5. Annotation attributes for group Pattern . . . . . . . . 90 A.5. Annotation attributes for group Pattern . . . . . . . . 89
A.6. Annotation attributes for choice and ref Patterns . . . 91 A.6. Annotation attributes for choice and ref Patterns . . . 90
A.7. Annotation attributes for element Pattern in the List A.7. Annotation attributes for element Pattern in the List
Context . . . . . . . . . . . . . . . . . . . . . . . . 91 Context . . . . . . . . . . . . . . . . . . . . . . . . 90
A.8. Annotation attributes for value Pattern . . . . . . . . 92 A.8. Annotation attributes for value Pattern . . . . . . . . 91
A.9. Named Patterns for All NETMOD-Specific Annotations . . . 92 A.9. Named Patterns for All NETMOD-Specific Annotations . . . 91
Appendix B. Schema-Independent Library . . . . . . . . . . . . . 96 Appendix B. Schema-Independent Library . . . . . . . . . . . . . 95
Appendix C. Mapping DHCP Data Model - A Complete Example . . . . 97 Appendix C. Mapping DHCP Data Model - A Complete Example . . . . 96
C.1. Input YANG Module . . . . . . . . . . . . . . . . . . . 97 C.1. Input YANG Module . . . . . . . . . . . . . . . . . . . 96
C.2. Conceptual Tree Schema . . . . . . . . . . . . . . . . . 100 C.2. Conceptual Tree Schema . . . . . . . . . . . . . . . . . 99
C.2.1. XML Syntax . . . . . . . . . . . . . . . . . . . . 100 C.2.1. XML Syntax . . . . . . . . . . . . . . . . . . . . 99
C.2.2. Compact Syntax . . . . . . . . . . . . . . . . . . 105 C.2.2. Compact Syntax . . . . . . . . . . . . . . . . . . 104
C.3. Final DSDL Schemas . . . . . . . . . . . . . . . . . . . 107 C.3. Final DSDL Schemas . . . . . . . . . . . . . . . . . . . 106
C.3.1. RELAX NG Schema for <get> Reply - XML Syntax . . . 108 C.3.1. RELAX NG Schema for <get> Reply - XML Syntax . . . 107
C.3.2. RELAX NG Schema for <get> Reply - Compact Syntax . 112 C.3.2. RELAX NG Schema for <get> Reply - Compact Syntax . 111
C.4. Schematron Schema for <get> Reply . . . . . . . . . . . 114 C.4. Schematron Schema for <get> Reply . . . . . . . . . . . 113
C.5. DSRL Schema for <get> Reply . . . . . . . . . . . . . . 116 C.5. DSRL Schema for <get> Reply . . . . . . . . . . . . . . 115
Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 117 Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 116
D.1. Changes Between Versions -03 and -04 . . . . . . . . . . 117 D.1. Changes Between Versions -04 and -05 . . . . . . . . . . 116
D.2. Changes Between Versions -02 and -03 . . . . . . . . . . 117 D.2. Changes Between Versions -03 and -04 . . . . . . . . . . 116
D.3. Changes Between Versions -01 and -02 . . . . . . . . . . 118 D.3. Changes Between Versions -02 and -03 . . . . . . . . . . 117
D.4. Changes Between Versions -00 and -01 . . . . . . . . . . 119 D.4. Changes Between Versions -01 and -02 . . . . . . . . . . 117
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 120 D.5. Changes Between Versions -00 and -01 . . . . . . . . . . 118
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 119
1. Introduction 1. Introduction
The NETCONF Working Group has completed a base protocol used for The NETCONF Working Group has completed a base protocol used for
configuration management [RFC4741]. This base specification defines configuration management [RFC4741]. This base specification defines
protocol bindings and an XML container syntax for configuration and protocol bindings and an XML container syntax for configuration and
management operations, but does not include a 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) [RFC1157] using the SMI language [RFC2578] Information Bases (MIBs) [RFC1157] using the SMI language [RFC2578]
to model its data. While this specific modeling approach has a to model its data. While this specific modeling approach has a
number of well-understood problems, most of the data modeling number of well-understood problems, most of the data modeling
features provided by SMI are still considered extremely important. features provided by SMI are still considered extremely important.
Simply modeling the valid syntax rather than additional semantic Simply modeling the valid syntax without the additional semantic
relationships has caused significant interoperability problems in the relationships has caused significant interoperability problems in the
past. 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 [RFC3216] and called YANG [YANG]. 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 [DSDL]. 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
skipping to change at page 7, line 30 skipping to change at page 7, line 30
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 [RNG-DTD] "a" DTD compatibility annotations [RNG-DTD];
"dc" Dublin Core metadata elements [RFC5013] "dc" Dublin Core metadata elements [RFC5013];
"dsrl" Document Semantics Renaming Language [DSRL] "dsrl" Document Semantics Renaming Language [DSRL];
"en" NETCONF event notifications [RFC5277] "en" NETCONF event notifications [RFC5277];
"nc" NETCONF protocol [RFC4741] "nc" NETCONF protocol [RFC4741];
"nma" NETMOD-specific schema annotations (see Section 5.3) "nma" NETMOD-specific schema annotations (see Section 5.3);
"nmf" NETMOD-specific XPath extension functions "nmf" NETMOD-specific XPath extension functions (see Section 12.6);
"nmt" Conceptual tree (see Section 8.1) "nmt" Conceptual tree (see Section 8.1);
"rng" RELAX NG [RNG] "rng" RELAX NG [RNG];
"sch" ISO Schematron [Schematron] "sch" ISO Schematron [Schematron];
"xsd" W3C XML Schema [XSD] "xsd" W3C XML Schema [XSD].
The following table shows the mapping of these prefixes to namespace The following table shows the mapping of these prefixes to namespace
URIs. URIs.
+--------+-----------------------------------------------------+ +--------+-----------------------------------------------------+
| Prefix | Namespace URI | | Prefix | Namespace URI |
+--------+-----------------------------------------------------+ +--------+-----------------------------------------------------+
| a | http://relaxng.org/ns/compatibility/annotations/1.0 | | a | http://relaxng.org/ns/compatibility/annotations/1.0 |
| | | | | |
| dc | http://purl.org/dc/terms | | dc | http://purl.org/dc/terms |
skipping to change at page 9, line 8 skipping to change at page 9, line 8
o conceptual data tree: A virtual XML document integrating all o conceptual data tree: A virtual XML document integrating all
components of a YANG data model, i.e., configuration datastore, components of a YANG data model, i.e., configuration datastore,
RPC methods (both requests and replies) and notifications. The RPC methods (both requests and replies) and notifications. The
conceptual tree is normally not instantiated, it only serves as a conceptual tree is normally not instantiated, it only serves as a
conceptual target for its schema. See Section 8.1 for details. conceptual target for its schema. See Section 8.1 for details.
o implicit node: A node that, if missing, may be added to the o implicit node: A node that, if missing, may be added to the
information set of an XML document (configuration, RPC input or information set of an XML document (configuration, RPC input or
output, notification) without changing the meaning of that XML output, notification) without changing the meaning of that XML
document for the NETCONF server. document.
3. Objectives and Motivation 3. Objectives and Motivation
The main objective of this work is to complement YANG as a data The main objective of this work is to complement YANG as a data
modeling language by validation capabilities of DSDL schema modeling language by validation capabilities of DSDL schema
languages, primarily RELAX NG and Schematron. This document languages, namely RELAX NG, Schematron and DSRL. This document
describes the correspondence between grammatical, semantic and data describes the correspondence between grammatical, semantic and data
type constraints expressed in YANG and equivalent DSDL 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-based information models and XML-encoded data appear in several XML-based information models and XML-encoded data appear in several
different forms in various phases of YANG data modeling and NETCONF different forms in various phases of YANG data modeling and NETCONF
workflow - configuration datastore contents, RPC requests and workflow - configuration datastore contents, RPC requests and
replies, and notifications. Moreover, RPC methods are characterized replies, and notifications. Moreover, RPC methods are characterized
by an inherent diversity resulting from selective availability of by an inherent diversity resulting from selective availability of
capabilities and features. YANG modules can also define new RPC capabilities and features. YANG modules can also define new RPC
methods. The mapping should be able to accommodate this variability methods. The mapping should be able to accommodate this variability
and generate schemas that are specifically tailored to a particular and generate schemas that are specifically tailored to a particular
situation and thus considerably more effective for validation than 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 for a particular purpose from the
modules and their lifetime will be relatively short. In other words, available collection of YANG modules and their lifetime will be
we don't envision that any collection of DSDL schemas will be created relatively short. In other words, we don't envision that any
and maintained over an extended period of time in parallel to YANG collection of DSDL schemas will be created and maintained over an
modules. extended period of time in parallel to YANG modules.
The generated schemas are primarily intended as input to the existing The generated schemas are primarily intended as input to the existing
XML schema validators and other off-the-shelf tools. However, the XML schema validators and other off-the-shelf tools. However, the
schemas may also be perused by developers and users as a formal schemas may also be perused by developers and users as a formal
representation of constraints on a particular XML-encoded data representation of constraints on a particular XML-encoded data
object. Consequently, our secondary goal is to keep the schemas as object. Consequently, our secondary goal is to keep the schemas as
readable as possible. To this end, the complexity of the mapping is readable as possible. To this end, the complexity of the mapping is
distributed into two steps: distributed into two steps:
1. The first step maps one or more YANG modules to a single RELAX NG 1. The first step maps one or more YANG modules to a single RELAX NG
skipping to change at page 12, line 9 skipping to change at page 12, line 9
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.
4. DSDL Schema Languages 4. DSDL Schema Languages
Document Schema Definition Languages (DSDL) is a framework of schema Document Schema Definition Languages (DSDL) is a framework of schema
languages that is being developed as 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, most
notably W3C XML Schema (XSD) [XSD], 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 language 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.
4.1. RELAX NG 4.1. RELAX NG
skipping to change at page 12, line 49 skipping to change at page 12, line 49
RELAX NG schemas can be represented in two equivalent syntaxes: XML RELAX NG schemas can be represented in two equivalent syntaxes: XML
and compact. The compact syntax is described in Annex C of the RELAX and compact. The compact syntax is described in Annex C of the RELAX
NG specification [RNG-CS], which was added to the standard in 2006 NG specification [RNG-CS], which was added to the standard in 2006
(Amendment 1). Automatic bidirectional conversions between the two (Amendment 1). Automatic bidirectional conversions between the two
syntaxes can be accomplished using several tools, for example syntaxes can be accomplished using several tools, for example
Trang [1]. 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 usually work with 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 computer program, it is more difficult to generate compact o In a computer program, it is more difficult to generate the
syntax than XML syntax. While a number of software libraries compact syntax than the XML syntax. While a number of software
exist that make it easy to create an XML tree in memory and libraries exist that make it easy to create an XML tree in memory
serialize it, no such aid is available for compact syntax. and 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".
skipping to change at page 14, line 8 skipping to change at page 14, line 8
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 [XPath] and Schematron draws most of its expressive power from XPath [XPath] and
XSLT [XSLT]. ISO Schematron allows for dynamic query language XSLT [XSLT]. ISO Schematron allows for dynamic query language
binding so that the following XML query languages can be used: STX, binding so that the following XML query languages can be used: STX,
XSLT 1.0, XSLT 1.1, EXSLT, XSLT 2.0, XPath 1.0, XPath 2.0 and XQuery XSLT 1.0, XSLT 1.1, EXSLT, XSLT 2.0, XPath 1.0, XPath 2.0 and
1.0 (this list may be extended in future). XQuery 1.0 (this list may be extended in the 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 contents.
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".
4.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 [DSRL]. 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 contents consisting of leaf nodes with
default values and their ancestor non-presence containers.
DSRL elements are qualified with namespace URI DSRL elements are qualified with namespace URI
"http://purl.oclc.org/dsdl/dsrl". "http://purl.oclc.org/dsdl/dsrl".
5. Additional Annotations 5. Additional Annotations
Besides the DSDL schema languages, the mapping also uses three sets Besides the DSDL schema languages, the mapping also uses three sets
of annotations that are added as foreign-namespace attributes and of annotations that are added as foreign-namespace attributes and
elements to RELAX NG schemas. 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 directly
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.
5.1. Dublin Core Metadata Elements 5.1. Dublin Core Metadata Elements
Dublin Core [2] 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
skipping to change at page 16, line 10 skipping to change at page 16, line 10
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".
5.3. NETMOD-Specific Annotations 5.3. NETMOD-Specific Annotations
NETMOD-specific annotations are XML elements and attributes qualified NETMOD-specific annotations are XML elements and attributes 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 of the conceptual tree schema. YANG statements are
mapped to these annotations in a straightforward way. In most cases, mapped to these annotations in a straightforward way. In most cases,
the annotation attributes and elements always have the same name as the annotation attributes and elements have the same name as the
the corresponding YANG statement. corresponding YANG statement.
Table 2 lists alphabetically the names of NETMOD-specific annotation Table 2 lists alphabetically the names of NETMOD-specific 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 contains the formal specification of this annotation Appendix A contains the formal specification of this annotation
vocabulary. vocabulary.
+---------------------------+--------------------+------+ +---------------------------+--------------------+------+
| annotation | section | note | | annotation | section | note |
+---------------------------+--------------------+------+ +---------------------------+--------------------+------+
skipping to change at page 18, line 36 skipping to change at page 18, line 36
+---------+ +-----+ +-------+ +------+ +---------+ +-----+ +-------+ +------+
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 8.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
annotations belonging to special namespaces. foreign-namespace annotations.
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 simple 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 is supposed to accept one
YANG modules as its input. It is important to be able to process or more valid YANG modules as its input. It is important to be able
multiple YANG modules together since multiple modules may be to process multiple YANG modules together since multiple modules may
negotiated for a NETCONF session and the contents of the be negotiated for a NETCONF session and the contents of the
configuration datastore is then obtained as the union of data trees configuration datastore is then obtained as the union of data trees
specified by the individual modules, which may also lead to multiple specified by the individual modules, which may also lead to multiple
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 input modules import (perhaps
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 as 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 server,
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 annotated
the common starting point for subsequent transformations that may RELAX NG and the common starting point for subsequent transformations
produce practical validation schemas. The conceptual tree is further that may produce practical validation schemas. The conceptual tree
described in Section 8.1. is further 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 5.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 <a:documentation> elements belonging to the DTD
DTD compatibility vocabulary (Section 5.2). 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 the specification of default contents.
7. NETCONF Content Validation 7. NETCONF Content Validation
This section describes how the schemas generated by the YANG-to-DSDL This section describes how the schemas generated by the YANG-to-DSDL
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, default values for leaf nodes 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 add the implicit nodes before the next validation step because
YANG specification [YANG] 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 validated 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 |
| | ^ | defaults | | | ^ | defaults |
| | | | | | | | | |
+----------+ | +----------+ +----------+ | +----------+
skipping to change at page 21, line 27 skipping to change at page 21, line 27
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
scope of this document, the mapping procedure is designed to scope of this document, the mapping procedure is designed to
accommodate any foreseeable validation needs. accommodate any foreseeable validation needs.
An essential part of the YANG-to-DSDL mapping procedure is An essential part of the YANG-to-DSDL mapping procedure is
nonetheless common to all validation approaches: the grammar and nonetheless common to all validation needs: the grammar and datatype
datatype specifications for the datastore, RPCs and notifications specifications for the datastore, RPCs and notifications expressed by
expressed by one or more YANG modules have to be translated to RELAX one or more YANG modules have to be translated to RELAX NG. In order
NG. In order to be able to separate this common step, we introduce to be able to separate this common step, we introduce the notion of
the notion of _conceptual data tree_: it is a virtual XML tree that conceptual data tree: it is a virtual XML tree that contains full
contains full datastore, RPC requests with corresponding replies and datastore, RPC requests with corresponding replies and notifications.
notifications. The schema for the conceptual tree - a single RELAX The schema for the conceptual tree - a single RELAX NG schema with
NG schema with annotations - therefore has a quite similar logic as annotations - therefore has a quite similar logic as the input YANG
the input YANG module(s), the only major difference being the RELAX module(s), the only major difference being the RELAX NG schema
NG schema language. language.
For example, the conceptual data tree for a YANG module defining For example, the conceptual data tree for a YANG module defining
nodes in the namespace "http://example.com/ns/example" may be nodes in the namespace "http://example.com/ns/example" may be
schematically represented as follows: schematically represented as follows:
<nmt:netmod-tree <nmt:netmod-tree
xmlns:nmt="urn:ietf:params:xml:ns:netmod:conceptual-tree:1" xmlns:nmt="urn:ietf:params:xml:ns:netmod:conceptual-tree:1"
xmlns:ex="http://example.com/ns/example"> xmlns:ex="http://example.com/ns/example">
<nmt:top> <nmt:top>
... configuration and status data ... ... configuration and status data ...
skipping to change at page 22, line 52 skipping to change at page 22, line 52
transformations should be relatively simple - they will typically transformations should be relatively simple - they will typically
extract one or more subtrees from the conceptual tree schema, modify extract one or more subtrees from the conceptual tree schema, modify
them as necessary and add encapsulating elements such as those from them as necessary and add encapsulating elements such as those 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 typically 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.
8.2. Modularity 8.2. Modularity
skipping to change at page 24, line 47 skipping to change at page 24, line 49
counterparts in YANG groupings and definitions of derived types. counterparts in YANG groupings and definitions of derived types.
8.4. Handling of XML Namespaces 8.4. Handling of XML Namespaces
Most modern XML schema languages including RELAX NG, Schematron and Most modern XML schema languages including RELAX NG, Schematron and
DSRL support schemas for so-called compound XML documents, which DSRL support schemas for so-called compound XML documents, which
contain elements from multiple namespaces. This is useful for our contain elements from multiple namespaces. This is useful for our
purpose since 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.
In both cases these attributes are typically attached to the <rng: In both cases, these attributes are typically attached to the <rng:
grammar> element. grammar> element but may also appear elsewhere.
The design decision for the mapping is to use exclusively the The design decision for the mapping is to use exclusively the
alternative 1, since in this case all YANG modules are represented alternative 1, since in this case all YANG modules are represented
symmetrically, which makes further processing of the conceptual tree symmetrically, which makes further processing of the conceptual tree
schema considerably easier. Moreover, this way the namespace schema considerably easier. Moreover, this way the namespace
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 target namespaces to be defined
defined in the <sch:ns> subelements of the root <sch:schema> element. in the <sch:ns> subelements of the root <sch:schema> element.
8.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. Instead, it statements are not handled by the YANG-to-DSDL mapping. Instead, it
is assumed that all features and deviations are specified beforehand is assumed that all features and deviations are specified beforehand
and the corresponding changes in the input YANG modules are already and the corresponding changes in the input YANG modules are already
applied. applied.
skipping to change at page 26, line 24 skipping to change at page 26, line 24
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 11. is contained in Section 11.
9.1. Occurrence Rules for Data Nodes 9.1. Occurrence Rules for Data Nodes
In DSDL schema languages, occurrence constraints for a node are In DSDL schema languages, occurrence constraints for a node are
always localized together with that node. In RELAX NG, for example, always localized together with that node. In a RELAX NG schema, for
<rng:optional> pattern appears as the parent element of the pattern example, <rng:optional> pattern appears as the parent element of the
defining the node in the schema, be it a leaf or container node. pattern defining a leaf or non-leaf element. Similarly, DSRL
Similarly, DSRL specifies default content separately for every single specifies default content separately for every single node, be it a
node, be it a leaf or non-leaf element. leaf or non-leaf element.
For leaf nodes in YANG modules, the occurrence constraints are also For leaf nodes in YANG modules, the occurrence constraints are also
easily inferred from the substatements of 'leaf'. In contrast, for a easily inferred from the substatements of 'leaf'. In contrast, for a
YANG container it is often necessary to examine its entire subtree in YANG container it is often necessary to examine its entire subtree in
order to determine the container's occurrence constraints. 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 any transformation procedure 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.
First, it has to be decided whether a given container element must First, it has to be decided whether a given container element must
always be present in a valid configuration. If so, such a container always be present in a valid configuration. If so, such a container
element is called mandatory, otherwise it is called optional. This element is called mandatory, otherwise it is called optional. This
constraint is very closely related to the notion of mandatory nodes constraint is closely related to the notion of mandatory nodes in
in Section 3.1 in [YANG]. The only difference is that we also Section 3.1 in [YANG]. The only difference is that we also consider
consider list keys to be mandatory. list keys to be mandatory.
The other occurrence constraint has to do with the semantics of the The other occurrence constraint has to do with the semantics of the
'default' statement and the possibility of removing empty non- 'default' statement and the possibility of removing empty non-
presence containers. As a result, the information set of a valid presence containers. As a result, the information set of a valid
configuration may be modified by adding or removing certain leaf or configuration may be modified by adding or removing certain leaf or
container elements without changing the meaning of the configuration. container elements without changing the meaning of the configuration.
Such elements are called implicit. In this document, such elements are called implicit.
Note that both occurrence constraints apply to containers at the top Note that both occurrence constraints apply to containers at the top
level of the data tree, and then also to other containers under the level of the data tree, and then also to other containers under the
additional condition that their parent node exists in the instance additional condition that their parent node exists in the instance
document. For example, consider the following YANG fragment: document. For example, consider the following YANG fragment:
container outer { container outer {
presence 'Presence of "outer" means something.'; presence 'Presence of "outer" means something.';
container c1 { container c1 {
leaf foo { leaf foo {
skipping to change at page 27, line 45 skipping to change at page 27, line 45
that it is optional and not implicit. If "outer" is not present in a that it is optional and not implicit. If "outer" is not present in a
configuration, its child containers are not present as well. configuration, its child containers are not present as well.
However, if "outer" does exist, it makes sense to ask which of its However, if "outer" does exist, it makes sense to ask which of its
child containers are optional and which are implicit. In this case, child containers are optional and which are implicit. In this case,
"c1" is optional and implicit, "c2" is optional but not implicit and "c1" is optional and implicit, "c2" is optional but not implicit and
"c3" is mandatory (and therefore not implicit). "c3" is mandatory (and therefore not implicit).
The following subsections give precise rules for determining whether The following subsections give precise rules for determining whether
a container is optional or mandatory and whether it is implicit. In a container is optional or mandatory and whether it is implicit. In
order to simplify the recursive definition of these occurrence order to simplify the recursive definition of these occurrence
characteristics, it is useful to define them for other types of nodes characteristics, it is useful to define them also for other types of
as well, i.e., leaf, list, leaf-list and anyxml. data nodes, i.e., leaf, list, leaf-list and anyxml.
9.1.1. Optional and Mandatory Nodes 9.1.1. Optional and Mandatory Nodes
The decision whether a given node is mandatory or optional is The decision whether a given node is mandatory or optional is
governed by the following rules: governed by the following rules:
o Leaf, anyxml and choice nodes are mandatory if they contain the o Leaf, anyxml and choice nodes are mandatory if they contain the
substatement "mandatory true;". For a choice node this means that substatement "mandatory true;". For a choice node this means 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 iff it is not mandatory. A node is optional if and only if 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 MUST explicitly wrapped in the <rng:optional> element. The mapping MUST
use the above rules to determine whether a YANG node is optional and use the above rules to determine whether a YANG node is optional and
if so, insert the <rng:optional> element in the conceptual tree if so, insert the <rng:optional> element in the 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' (so-called shorthand cases) are always mapped to mandatory
patterns. If a choice in YANG is not mandatory, <rng:optional> is RELAX NG patterns. If a choice in YANG is not mandatory, <rng:
used to wrap the entire <rng:choice> pattern. optional> is used to wrap the entire <rng:choice> pattern.
9.1.2. Implicit Nodes 9.1.2. Implicit Nodes
The following rules are used to determine whether a given 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 In the conceptual tree schema, all implicit containers, as well as
appearing inside a case of a choice can be implicit only if that leafs that obtain their default value from a typedef and don't have
case is declared as default by using the 'default' statement, see the @nma:default attribute, MUST be marked with @nma:implicit
Section 7.9.3 in [YANG]. attribute having the value "true".
In the conceptual tree schema, all implicit containers MUST be marked Note that Section 7.9.3 in [YANG] specifies other rules that must be
with @nma:implicit attribute with the value "true". In addition, the taken into account when deciding whether a given container or leaf
default case in a choice (defined by the 'default' substatement of appearing inside a case of a choice is ultimately implicit or not.
'choice') MUST be also marked in the same way, i.e., by @nma:implicit Specifically, a leaf or container under a case can be implicit only
set to "true". if the case appears in the argument of the choice's 'default'
statement. However, this is not sufficient by itself but also
depends on the particular instance XML document, namely on the
presence or absence of nodes from other (non-default) cases. The
details are explained in Section 10.4.
9.2. Mapping YANG Groupings and Typedefs 9.2. Mapping YANG Groupings and Typedefs
YANG groupings and typedefs are generally mapped to RELAX NG named YANG groupings and typedefs are generally mapped to RELAX NG named
patterns. There are, however, several caveats that the mapping has patterns. There are, however, several caveats that the mapping has
to take into account. to take into account.
First of all, YANG typedefs and groupings may appear at all levels of First of all, YANG typedefs and groupings may appear at all levels of
the module hierarchy and are subject to lexical scoping, see Section the module hierarchy and are subject to lexical scoping, see Section
5.5 in [YANG]. Moreover, top-level symbols from external modules are 5.5 in [YANG]. Second, 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 31, line 46 skipping to change at page 31, line 46
<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="ietf-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>
Note that type definitions from the "ietf-inet-types" module are
mapped directly to the conceptual tree schema.
9.2.1. YANG Refinements and Augments 9.2.1. YANG Refinements and Augments
YANG groupings represent a similar concept as named pattern YANG groupings represent a similar concept as named pattern
definitions in RELAX NG and both languages also offer mechanisms for definitions in RELAX NG and both languages also offer mechanisms for
their subsequent modification. However, in RELAX NG the definitions their subsequent modification. However, in RELAX NG the definitions
themselves are modified whereas YANG allows for modifying themselves are modified whereas YANG allows for modifying expansions
_expansions_ of groupings. Specifically, YANG provides two of groupings. Specifically, YANG provides two statements for this
statements for this purpose that may appear as substatements of 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 their arguments,
nodes that are arbitrarily deep inside the grouping content. In schema nodes that are arbitrarily deep inside the grouping content.
contrast, modifications of named pattern definitions in RELAX NG are In contrast, modifications of named pattern definitions in RELAX NG
applied exclusively at the topmost level of the named pattern are applied exclusively at the topmost level of the named pattern
content. In order to achieve a modifiability of named patterns content. In order to achieve a modifiability of named patterns
comparable to YANG, the RELAX NG schema would have to be extremely comparable to YANG, the RELAX NG schema would have to be extremely
flat (cf. Section 8.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 replaced by the content of the and/or 'augment' substatements is replaced by the content of the
corresponding grouping, the changes specified in the 'refine' and corresponding grouping, the changes specified in the 'refine' and
skipping to change at page 34, line 4 skipping to change at page 34, line 4
<rng:element name="ex2:hoja"> <rng:element name="ex2:hoja">
<rng:data type="string"/> <rng:data type="string"/>
</rng:element> </rng:element>
</rng:optional> </rng:optional>
</rng:define> </rng:define>
and the configuration data part of the conceptual tree schema is a and the configuration data part of the conceptual tree schema is a
single named pattern reference: single named pattern reference:
<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 contains a 'refine'
substatement, for example:
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 - "_example2__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 schema
looks like this: now 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>
9.2.2. Type derivation chains 9.2.2. Type Derivation Chains
RELAX NG has no equivalent of the type derivation mechanism in YANG,
where a ancestor built-in type may be modified (perhaps in multiple
steps) by adding new restrictions. Therefore, when mapping YANG
derived types with restrictions, the derived types MUST be "unwound"
all the way back to the ancestor built-in type. At the same time,
all restrictions found along the type derivation chain MUST be
combined and their intersection used as facets restricting the
corresponding type in RELAX NG.
When a derived YANG type is used without restrictions - as a RELAX NG has no equivalent of the type derivation mechanism in YANG
substatement of either 'leaf' or another 'typedef' - the 'type' that allows to modify a built-in type (perhaps in multiple steps) by
statement is mapped simply to the <rng:ref> element, i.e., a named adding new restrictions. When a derived YANG type is used without
pattern reference. However, if restrictions are specified as restrictions - as a substatement of either 'leaf' or another
substatements of the 'type' statement, the type definition MUST be 'typedef' - the 'type' statement is mapped simply to the <rng:ref>
expanded at that point so that only the ancestor built-in type element, i.e., a named pattern reference, and the type definition is
appears in the output schema, restricted with facets that again mapped to a RELAX NG named pattern definition. However, if
correspond to the combination of all restrictions found along the restrictions are specified as substatements of the 'type' statement,
type derivation chain and also in the 'type' statement. the type definition MUST be expanded at that point so that only the
ancestor built-in type appears in the output schema, restricted with
facets that correspond to the combination of all restrictions found
along the type derivation chain and also in the 'type' statement.
EXAMPLE. Consider this YANG module: EXAMPLE. Consider this YANG module:
module example3 { module example3 {
namespace "http://example.com/ns/example3"; namespace "http://example.com/ns/example3";
prefix ex3; prefix ex3;
typedef dozen { typedef dozen {
type uint8 { type uint8 {
range 1..12; range 1..12;
} }
skipping to change at page 37, line 8 skipping to change at page 37, line 8
</rng:data> </rng:data>
</rng:element> </rng:element>
However, if the definition of leaf "month" itself contained the However, if the definition of leaf "month" itself contained the
'default' substatement, the default specified for the "dozen" type 'default' substatement, the default specified for the "dozen" type
will be ignored. will be ignored.
9.3. Translation of XPath Expressions 9.3. Translation of XPath Expressions
YANG uses full XPath 1.0 syntax [XPath] for the arguments of 'must', YANG uses full XPath 1.0 syntax [XPath] for the arguments of 'must',
'when' and 'path' statements. However, since the names of data nodes 'when' and 'path' statements. As the names of data nodes defined in
defined in a YANG module always belong to the namespace of that YANG a YANG module always belong to the namespace of that YANG module,
module, YANG adopted a simplification similar to the concept of YANG adopted a simplification similar to the concept of default
_default namespace_ in XPath 2.0: node names needn't carry a namespace in XPath 2.0: node names needn't carry a namespace prefix
namespace prefix inside the module where they are defined, in which inside the module where they are defined and the local module's
case the module's namespace is assumed. 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 [YANG], sections 7.5.3 and 7.19.5 in [YANG]. expressions, see [YANG], Sections 7.5.3 and 7.19.5.
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
[YANG]) 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.
9.4. YANG Language Extensions 9.4. YANG Language Extensions
YANG allows for extending its own language in-line by adding new YANG allows for extending its own language in-line by adding new
statements with keywords from special namespaces. Such extensions statements with keywords from special namespaces. Such extensions
first have to be declared using the 'extension' statement and then first have to be declared using the 'extension' statement and then
can be used as the native statements, only with a namespace prefix can be used as the standard YANG statements, from which they are
qualifying the extension keyword. RELAX NG has a similar extension distinguished by a namespace prefix qualifying the extension keyword.
mechanism - XML elements and attributes with names from foreign RELAX NG has a similar extension mechanism - XML elements and
namespaces may be inserted at almost every place of a RELAX NG attributes with names from foreign namespaces may be inserted at
schema. almost any place of a RELAX NG schema.
YANG language extensions may or may not have a meaning in the context YANG language extensions may or may not have a meaning in the context
of DSDL schemas. Therefore, an implementation MAY ignore any or all of DSDL schemas. Therefore, an implementation MAY ignore any or all
of the extensions. However, an extension that is not ignored MUST be of the extensions. However, an extension that is not ignored MUST be
mapped to XML element(s) and/or attribute(s) that exactly match the mapped to XML element(s) and/or attribute(s) that exactly match the
YIN form of the extension. YIN form of the extension, see Section 11.1 in [YANG].
EXAMPLE. Consider the following extension defined by the "acme" EXAMPLE. Consider the following extension defined by the "acme"
module: module:
extension documentation-flag { extension documentation-flag {
argument number; argument number;
} }
This extension can then be used in the same or another module, for This extension can then be used in the same or another module, for
instance like this: instance like this:
skipping to change at page 39, line 9 skipping to change at page 39, line 9
<acme:documentation-flag number="42"/> <acme:documentation-flag number="42"/>
<rng:data type="string"/> <rng:data type="string"/>
</rng:element> </rng:element>
Note that the 'extension' statement itself is not mapped in any way. Note that the 'extension' statement itself is not mapped in any way.
10. Mapping Conceptual Tree Schema to DSDL 10. Mapping Conceptual Tree Schema to DSDL
As explained in Section 6, 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 prepared for validating instance XML documents. As an
gets in the simplest case a specification of the NETCONF XML document input parameter, this step takes in the simplest case just a
type (or combination of multiple types) that is to be validated. specification of the NETCONF XML document type (or combination of
These document type can be, for example, the content of a datastore, multiple types) that is to be validated. These document type can be,
reply to <nc:get> or <nc:get-config>, other RPC requests or replies for example, the content of a datastore, reply to <nc:get> or <nc:
and notifications. get-config>, other RPC requests or replies 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:
1. Extract the part(s) of the conceptual tree schema that are 1. Extract the part(s) of the conceptual tree schema that are
appropriate for the requested document type. For example, if a appropriate for the requested document type. For example, if a
<get> reply is to be validated, the subtree under <nmt:top> must <get> reply is to be validated, the subtree under <nmt:top> must
be selected. be selected.
2. The schema must be adapted to the specific encapsulating XML 2. The schema must be adapted to the specific encapsulating XML
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 <get> reply 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 the
corresponding schema-language-specific rules. corresponding 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 and can be effectively implemented using XSL transformations
transformations [XSLT]. [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 12 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.
10.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 of 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.
Schemas for multiple alternative target document types can also be Schemas for multiple alternative target document types can also be
easily generated by enclosing the definitions for requested type in easily generated by enclosing the definitions for requested type in
<rng:choice> element. <rng:choice> element.
In order to avoid copying identical named pattern definitions to the In order to avoid copying common named pattern definitions to every
output RELAX NG file, these schema-independent definitions SHOULD be single output RELAX NG file, these schema-independent definitions
collected in a library file which is then included by the validating SHOULD be collected in a library file which is then included by the
RELAX NG schemas. Appendix B has the listing of this library file. validating 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 12.1 for more details. its descendants. See Section 12.1 for more details.
10.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
skipping to change at page 40, line 43 skipping to change at page 40, line 44
</rng:element> </rng:element>
</rng:element> </rng:element>
</rng:start> </rng:start>
... named pattern definitions ... ... named pattern definitions ...
</rng:grammar> </rng:grammar>
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 literally from the
conceptual tree schema without any changes to the resulting grammar. conceptual tree schema to the resulting grammar. However, an
However, an implementation MAY choose to copy only those definitions implementation MAY choose to copy only those definitions that are
that are really used in the particular output grammar. really used in the particular output grammar.
10.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:
<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"> <rng:element name="nc:rpc">
<rng:ref name="message-id-attribute"/> <rng:ref name="message-id-attribute"/>
<rng:element name="yam:myrpc"> <rng:element name="yam:myrpc">
... patterns defining contents of subtree ... ... patterns defining contents of the subtree ...
... "nmt:rpc-method/nmt:input/yam:myrpc" ... ... "nmt:rpc-method/nmt:input/yam:myrpc" ...
</rng:element> </rng:element>
</rng:element> </rng:element>
</rng:start> </rng:start>
... named pattern definitions ... ... named pattern definitions ...
</rng:grammar> </rng:grammar>
For "myrpc" reply, the output grammar is For "yam:myrpc" reply, the output grammar is
<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"/>
... patterns defining contents of corresponding ... ... patterns defining contents of the corresponding ...
... "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.
skipping to change at page 42, line 33 skipping to change at page 42, line 33
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.
10.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:
<sch:rule context="XELEM"> <sch:rule context="XELEM">
... ...
</sch:rule> </sch:rule>
The value of the mandatory @context attribute of <sch:rule> is set to The value of the mandatory @context attribute of <sch:rule> (denoted
the absolute path of the context element in the data tree. The <sch: as XELEM) MUST be set to the absolute path of the context element in
rule> element contains the mappings of one or more of the following the data tree. The <sch:rule> element contains the mappings of one
NETMOD-specific annotations, if they are attached to the context or more of the following NETMOD-specific annotations, if they are
element: <nma:instance-identifier>, @nma:key, @nma:leafref, @nma:min- attached to the context element: <nma:instance-identifier>, @nma:key,
elements, @nma:max-elements, <nma:must>, @nma:unique and <nma:when>. @nma:leafref, @nma:min-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
by the <sch:pattern> element. The mapping uses patterns only for 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 10.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 places. The mapping uses Schematron abstract
Schematron _abstract rules_ to handle this case: An element rules to handle this case: An element definition inside a named
definition inside a named pattern is mapped to an abstract rule and pattern is mapped to an abstract rule and every use of the named
every use of the named pattern then extends (uses) this abstract rule pattern then extends (uses) this abstract rule in the concrete
in the concrete context. context.
EXAMPLE. Consider this element pattern 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>
skipping to change at page 45, line 11 skipping to change at page 45, line 11
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 10.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. As explained above, the rule is abstract if the element
inside a named pattern, see above. definition appears inside a named pattern.
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 12. 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.
10.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
constraints. constraints.
o Validation phase "noref" is the same as "full" except it doesn't o Validation phase "noref" is the same as "full" except it doesn't
check referential integrity constraints. check referential integrity constraints.
A parameter identifying the validation phase to use has to be passed A parameter identifying the validation phase to use has to be passed
to the Schematron processor or otherwise both patterns are used by to the Schematron processor or otherwise "full" phase is assumed by
default. How this is exactly done depends on the concrete Schematron default. How this is exactly done depends on the concrete Schematron
processor and is outside the scope of this document. processor and is outside the scope of this document.
The validation phases are defined in Schematron by listing the The validation phases are defined in Schematron by listing the
patterns that are to be applied for each phase. Therefore, the patterns that are to be applied for each phase. Therefore, the
mapping puts the rules for referential integrity checking to a mapping puts the rules for referential integrity checking to a
special <sch:pattern> with @id attribute set to "ref-integrity". The special <sch:pattern> with @id attribute set to "ref-integrity". The
rules mapped from the remaining semantic constraints are put to rules mapped from the remaining semantic constraints are put to
another <sch:pattern> with @id attributes set to "standard". another <sch:pattern> with @id attributes set to "standard".
skipping to change at page 48, line 8 skipping to change at page 48, line 8
<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>
10.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 also has
functions, the YANG-to-DSDL mapping uses it only for specifying other functions, YANG-to-DSDL mapping uses it only for specifying and
default content. For XML instance documents based on YANG data applying default content. For XML instance documents based on YANG
models, insertion of default content may potentially take place for data models, insertion of default content may potentially take place
all implicit nodes, see Section 9.1. for all implicit nodes defined by the rules in Section 9.1.2.
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 [DSRL]: 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.
skipping to change at page 48, line 34 skipping to change at page 48, line 34
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 9.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 having NETMOD-specific annotation
@nma:default or @nma:implicit, i.e., either attributes @nma:default or @nma:implicit, i.e., either
<rng:element name="ELEM" nma:default="DEFVALUE"> <rng:element name="ELEM" nma:default="DEFVALUE">
... ...
</rng:element> </rng:element>
or or
<rng:element name="ELEM" nma:implicit="true"> <rng:element name="ELEM" nma:implicit="true">
... ...
</rng:element> </rng:element>
In the simple case, these element patterns are mapped to the The former case applies to leaf nodes having the 'default'
substatement, but also to leaf nodes that obtain their default value
from a typedef, if this typedef is expanded according to the rules in
Section 9.2.2 so that the @nma:default annotation is attached
directly to the leaf's element pattern.
The latter case is used for all implicit containers (see Section 9.1)
and for leafs that obtain the default value from a typedef and don't
have the @nma:default annotation.
In the simplest case, both element patterns are mapped to the
following DSRL element map: following DSRL element map:
<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:
o If the element pattern defining ELEM is annotated with @nma: o If the implicit node ELEM is a leaf and has the @nma:default
default, DEFCONT is equal to the value of this attribute (denoted attribute, DEFCONT is set to the value of this attribute (denoted
above as DEFVALUE). above as DEFVALUE).
o Otherwise, if the element pattern defining ELEM is annotated with o If the implicit node ELEM is a leaf and has the @nma:implicit
@nma:implicit, DEFCONT is an XML fragment containing all attribute with the value "true", the default value has to be
descendant elements of ELEM that have either @nma:implicit or determined from the @nma:default attribute of the definition of
@nma:default attribute. ELEM's type (perhaps recursively) and used in place of DEFCONT in
the above DSRL element map. See also Section 9.2.2.
Inside the subtree of <rng:choice>, the @nma:default and @nma: o Otherwise, the implicit node ELEM is a container and DEFCONT is
implicit annotations MUST be ignored unless they are descendants of a constructed as an XML fragment containing all descendant elements
<rng:group> or <rng:interleave> pattern with @nma:implicit attribute of ELEM that have either @nma:implicit or @nma:default attribute.
set to "true" - this corresponds to the default case of a YANG choice
(see Section 11.12).
When mapping such a default case, it has to be guaranteed that the The <rng:element>, <rng:group> or <rng:interleave>patterns appearing
default content is be applied if any of the nodes from any non- directly under <rng:choice> MUST NOT have either @nma:default or
default case are present. This is accomplished by setting <dsrl: @nma:implicit annotation unless they belong to the default case of a
parent> in a special way: YANG choice (see Section 11.12).
In addition, when mapping the default case of a choice, it has to be
guaranteed that the default content is not applied if any node from
any non-default case is present. This is accomplished by setting
<dsrl:parent> in a special way:
<dsrl:parent>XPARENT[not (ELEM1|ELEM2|...|ELEMn)]</dsrl:parent> <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 all top-level nodes
all non-default cases. The rest of the element map is exactly as from all non-default cases. The rest of the element map is exactly
above. as before.
EXAMPLE. Consider the following YANG module: EXAMPLE. Consider the following YANG module:
module example5 { module example5 {
namespace "http://example.com/ns/example5"; namespace "http://example.com/ns/example5";
prefix ex5; prefix ex5;
container outer { container outer {
leaf leaf1 { leaf leaf1 {
type uint8; type uint8;
default 1; default 1;
skipping to change at page 51, line 45 skipping to change at page 51, line 45
</dsrl:default-content> </dsrl:default-content>
</dsrl:element-map> </dsrl:element-map>
<dsrl:element-map> <dsrl:element-map>
<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 never becomes an implicit element.
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 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 6. The subsections are step of the mapping procedure as explained in Section 6. The
sorted alphabetically by the statement keyword. subsections are 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 procedure is inherently recursive, which means that after mapping procedure is inherently recursive, which means that after
finishing a statement the mapping continues with its substatements, finishing a statement the mapping continues with its substatements,
if there are any, and a certain element of the resulting fragment if there are any, and a certain element of the resulting fragment
becomes the parent of other fragments resulting from the mapping of becomes the parent of other fragments resulting from the mapping of
substatements. Any changes to this default recursive procedure are substatements. Any changes to this default recursive procedure are
explicitly specified. explicitly specified.
skipping to change at page 53, line 40 skipping to change at page 52, line 40
2. When mapping the 'list' statement, all keys MUST come before any 2. When mapping the 'list' statement, all keys MUST come before any
other subelements and in the same order as they are declared in other subelements and in the same order as they are declared in
the 'key' statement. The order of the remaining (non-key) the 'key' statement. The order of the remaining (non-key)
subelements is not specified, so their definitions in the subelements is not specified, so their definitions in the
conceptual tree schema MUST be enclosed in the <rng:interleave> conceptual tree schema MUST be enclosed in the <rng:interleave>
element. element.
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 conventions:
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.
11.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. [Vli04], RELAX NG schema as a child of the <rng:grammar> element (cf. [Vli04],
p. 172): p. 172):
<rng:define name="__anyxml__"> <rng:define name="__anyxml__">
<rng:zeroOrMore> <rng:zeroOrMore>
<rng:choice> <rng:choice>
skipping to change at page 55, line 40 skipping to change at page 54, line 40
This statement is handled within the "bits" type, see This statement is handled within the "bits" type, see
Section 11.53.3. Section 11.53.3.
11.7. The case Statement 11.7. The case Statement
This statement is mapped to <rng:group> or <rng:interleave> element, This statement is mapped to <rng:group> or <rng:interleave> element,
depending on whether the statement belongs to an RPC definition or depending on whether the statement belongs to an RPC definition or
not. If the argument of a sibling 'default' statement equals to not. If the argument of a sibling 'default' statement equals to
ARGUMENT, @nma:implicit attribute with the value "true" MUST be added ARGUMENT, @nma:implicit attribute with the value "true" MUST be added
to that <rng:group> or <rng:interleave> element. The @nma:implicit to that <rng:group> or <rng:interleave> element. The @nma:implicit
attribute MUST NOT be used for nodes that belong to non-default cases attribute MUST NOT be used for nodes at the top-level of a non-
of a choice (see Section 7.9.3 in [YANG]). default case (see Section 7.9.3 in [YANG]).
11.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;" may require additional
handling, see Section 10.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.
11.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.
11.10. The contact Statement 11.10. The contact Statement
This statement is not used by the mapping since the output RELAX NG This statement SHOULD NOT be used by the mapping since the output
schema may result from multiple YANG modules created by different RELAX NG schema may result from multiple YANG modules created by
authors. The schema contains references to all input modules in the different authors. The schema contains references to all input
Dublin Core elements <dc:source>, see Section 11.34. The original modules in the Dublin Core elements <dc:source>, see Section 11.34.
YANG modules are the authoritative sources of the authorship The original YANG modules are the authoritative sources of the
information. authorship information.
11.11. The container Statement 11.11. The container Statement
Using the rules specified in Section 9.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
skipping to change at page 57, line 13 skipping to change at page 56, line 13
'typedef' mapping. 'typedef' mapping.
o Otherwise, @nma:default becomes an attribute of the ancestor RELAX o Otherwise, @nma:default becomes an attribute of the ancestor RELAX
NG pattern inside which the expansion takes place. NG pattern inside which the expansion takes place.
Details and an example are given in Section 9.2.2. Details and an example are given in Section 9.2.2.
Finally, as a substatement of 'choice', the 'default' statement Finally, as a substatement of 'choice', the 'default' statement
identifies the default case and is handled within the 'case' identifies the default case and is handled within the 'case'
statement, see Section 11.7. If the default case uses the shorthand statement, see Section 11.7. If the default case uses the shorthand
notation where the 'case' statement is omitted, an extra <rng:group> notation where the 'case' statement is omitted, the @nma:implicit
or <rng:interleave> element MUST be inserted with @nma:implicit attribute with the value "true" is either attached to the node
attribute set to "true" and the default case node is mapped inside representing the default case in the shorthand notation or,
this element. The net result is then the same as if the 'case' alternatively, an extra <rng:group> element MAY be inserted and the
statement wasn't omitted for the default case. @nma:implicit attribute attached to it. In the latter case, the net
result is the same as if the 'case' statement wasn't omitted for the
default case.
EXAMPLE. The following 'choice' statement in a module with namespace 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 either mapped directly to
<rng:choice> <rng:choice>
<rng:interleave nma:implicit="true"> <rng:element name="yam:feuille" nma:implicit="true">
<rng:empty/>
</rng:element>
<rng:element name="yam:hoja">
<rng:empty/>
</rng:element/>
</rng:choice>
or the default case may be wrapped in an extra <rng:group>:
<rng:choice>
<rng:group nma:implicit="true">
<rng:element name="yam:feuille"> <rng:element name="yam:feuille">
<rng:empty/> <rng:empty/>
</rng:element> </rng:element>
</rng:interleave> </rng:group>
<rng:element name="yam:hoja"> <rng:element name="yam:hoja">
<rng:empty/> <rng:empty/>
</rng:element/> </rng:element/>
</rng:choice> </rng:choice>
11.13. The description Statement 11.13. The description Statement
This statement MAY be ignored. Otherwise, it is mapped to the DTD This statement MAY be ignored. Otherwise, it is mapped to the DTD
compatibility element <a:documentation> and ARGUMENT becomes its compatibility element <a:documentation> and ARGUMENT becomes its
text. text.
skipping to change at page 58, line 41 skipping to change at page 57, line 50
MAY be mapped as described in Section 9.4. MAY be mapped as described in Section 9.4.
11.19. The feature Statement 11.19. The feature Statement
This statement is ignored, see Section 8.5. This statement is ignored, see Section 8.5.
11.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 9.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 in place to the prescribed schema nodes. See
Section 9.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.
11.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, or is derived from this base,
one of the <rng:value> elements in the mapping of that "identityref" ARGUMENT will appear as the text of one of the <rng:value> elements
type. See Section 11.53.5 for more details and an example. in the mapping of that "identityref" type. See Section 11.53.5 for
more details and an example.
11.22. The if-feature Statement 11.22. The if-feature Statement
This statement is ignored, see Section 8.5. This statement is ignored, see Section 8.5.
11.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
skipping to change at page 59, line 48 skipping to change at page 59, line 11
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.
11.25. The input Statement 11.25. The input Statement
This statement is handled within 'rpc' statement, see Section 11.50. This statement is handled within 'rpc' statement, see Section 11.50.
11.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 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.
11.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.
skipping to change at page 61, line 18 skipping to change at page 60, line 31
This statement is handled within the "string" type, see This statement is handled within the "string" type, see
Section 11.53.9. Section 11.53.9.
11.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 11.28. Section 11.28.
When mapping the substatements of 'list', the order of children of 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 list element MUST be specified so that list keys, if there are
the same order as they are defined in the input YANG module and any, always appear in the same order as they are defined in the input
before other children, see [YANG], Section 7.8.5. In particular, if YANG module and before other children, see [YANG], Section 7.8.5. In
any list key is defined in a grouping but the list itself is not particular, if any list key is defined in a grouping but the list
defined in the same grouping, and the position of the 'uses' node itself is not a part of the same grouping, and the position of
statement would violate the above ordering requirement, the grouping the 'uses' statement would violate the above ordering requirement,
MUST be expanded, i.e., the 'uses' statement replaced by the grouping the grouping MUST be expanded, i.e., the 'uses' statement replaced by
contents. the grouping contents.
For example, consider the following YANG fragment of a module with For example, consider the following YANG fragment of a module with
prefix "yam": prefix "yam":
grouping keygrp { grouping keygrp {
leaf clef { leaf clef {
type uint8; type uint8;
} }
} }
skipping to change at page 62, line 50 skipping to change at page 62, line 20
11.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 11.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 descendants 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 descendants 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. descendants of the <nmt:notifications> element.
11.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 9.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.
skipping to change at page 64, line 18 skipping to change at page 63, line 36
<rng:element name="nmt:notifications">. <rng:element name="nmt:notifications">.
11.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 11.28 for an becomes the value of this attribute. See Section 11.28 for an
example. example.
11.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 conceptual
schema may result from multiple YANG modules authored by different tree schema may result from multiple YANG modules authored by
parties. The schema contains references to all input modules in the different parties. The schema contains references to all input
Dublin Core elements <dc:source>, see Section 11.34. The original modules in the Dublin Core elements <dc:source>, see Section 11.34.
modules are the authoritative sources of the authorship information. The original modules are the authoritative sources of the authorship
information.
11.40. The output Statement 11.40. The output Statement
This statement is handled within 'rpc' statement, see Section 11.50. This statement is handled within 'rpc' statement, see Section 11.50.
11.41. The path Statement 11.41. The path Statement
This statement is handled within "leafref" type, see Section 11.53.7. This statement is handled within "leafref" type, see Section 11.53.7.
11.42. The pattern Statement 11.42. The pattern Statement
skipping to change at page 65, line 31 skipping to change at page 64, line 52
11.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 [YANG]. 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 11.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 2010-03-02</dc:source>
The 'description' substatement of 'revision' is ignored.
The 'description' substatement of 'revision' is not used.
11.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>
<rng:element name="nmt:output"> <rng:element name="nmt:output">
<!-- mapped content of 'output' --> ... mapped content of 'output' ...
</rng:element> </rng:element>
</rng:element> </rng:element>
As indicated by the comments, contents of the 'input' substatement As indicated in the schema fragment, contents of the 'input'
(if any) are mapped under <rng:element name="yam:ARGUMENT">. substatement (if any) are mapped under <rng:element name="yam:
Similarly, contents of the 'output' substatement are mapped under ARGUMENT">. Similarly, contents of the 'output' substatement are
<rng:element name="nmt:output">. If there is no 'output' mapped under <rng:element name="nmt:output">. If there is no
substatement, the <rng:element name="nmt:output"> MUST NOT be 'output' substatement, the <rng:element name="nmt:output"> MUST NOT
present. be 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">.
11.51. The status Statement 11.51. The status Statement
This statement MAY be ignored. Otherwise, it is mapped to @nma: This statement MAY be ignored. Otherwise, it is mapped to @nma:
status attribute and ARGUMENT becomes its value. status attribute and ARGUMENT becomes its value.
11.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.
11.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 datatypes have an equivalent in the XSD datatype
library [XSD-D] 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 67, line 31 skipping to change at page 66, line 31
| | | | | | | |
| uint64 | unsignedLong | 64-bit unsigned integer value | | uint64 | unsignedLong | 64-bit unsigned integer value |
| | | | | | | |
| string | string | character string | | string | string | character string |
| | | | | | | |
| 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: YANG built-in datatypes with equivalents in the W3C XML
Schema Type Library
Two important datatypes of the XSD datatype library - "dateTime" and
"anyURI" - are not built-in in YANG but defined as derived types in
the standard modules [Ytypes]: "date-and-time" in the "ietf-yang-
types" module and "uri" in the "ietf-inet-types" module. However,
the formal restrictions in the YANG type definitions are rather weak.
Therefore, implementations of the YANG-to-DSDL mapping SHOULD detect
these derived types in source YANG modules and map them to "dateType"
and "anyURI", respectively.
Details about the mapping of individual YANG built-in types are given Details about the mapping of individual YANG built-in types are given
in the following subsections. in the following subsections.
11.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/>.
11.53.2. The boolean and binary Types 11.53.2. The boolean and binary Types
skipping to change at page 70, line 4 skipping to change at page 69, line 4
is mapped to is mapped to
<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 typically be defined via
attributes of the <rng:grammar> element. attributes of the <rng:grammar> element.
11.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 argument of the 'require-instance' substatement, if it exists,
@require-instance attribute of <nma:instance-identifier>. becomes the value of the @require-instance attribute of <nma:
instance-identifier>.
11.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 9.3, is set as the value of this translated according to Section 9.3, is set as the value of this
attribute. attribute.
11.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. translated according to Table 3 above.
An exception is the "decimal64" type, which is mapped to the An exception is the "decimal64" type, which is mapped to the
"decimal" type of the XSD datatype library. Its precision and number "decimal" type of the XSD 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:
o "totalDigits" facet set to the value of 19. o "totalDigits" facet set to the value of 19.
o "fractionDigits" facet set to the argument of the 'fraction- o "fractionDigits" facet set to the argument of the 'fraction-
digits' substatement. digits' substatement.
The fixed value of the "totalDigits" facet corresponds to the maximum The fixed value of "totalDigits" corresponds to the maximum of 19
of 19 decimal digits for 64-bit integers. decimal digits for 64-bit integers.
For example, the statement For example, the statement
type decimal64 { type decimal64 {
fraction-digits 2; fraction-digits 2;
} }
is mapped to the following RELAX NG datatype: is mapped to the following RELAX NG datatype:
<rng:data type="decimal"> <rng:data type="decimal">
skipping to change at page 71, line 33 skipping to change at page 70, line 33
and and
<rng:param name="maxInclusive">...</rng:param> <rng:param name="maxInclusive">...</rng:param>
Their contents are the lower and upper bound, respectively. If Their contents are the lower and upper bound, respectively. If
the lower bound is "min", the "minInclusive" facet is omitted and the lower bound is "min", the "minInclusive" facet is omitted and
if the upper bound is "max", the "maxInclusive" facet is omitted. if the upper bound is "max", the "maxInclusive" facet is omitted.
If the range expression has multiple parts separated by "|", then the If the range expression has multiple parts separated by "|", then the
parent <rng:data> element must be repeated once for every range part parent <rng:data> element must be repeated once for every range part
and all the <rng:data> elements are wrapped in <rng:choice> element. and all such <rng:data> elements are wrapped in <rng:choice> element.
Each <rng:data> element contains the <rng:value> pattern or the Each <rng:data> element contains the <rng:value> pattern or the
"minInclusive" and "maxInclusive" facets for the corresponding part "minInclusive" and "maxInclusive" facets for one part of the range
of the range expression as described in the previous paragraph. For expression as described in the previous paragraph. For the
the "decimal64" type, the "totalDigits" and "fractionDigits" must be "decimal64" type, the "totalDigits" and "fractionDigits" must be
repeated inside each of the <rng:data> elements. repeated inside each of the <rng:data> elements.
For example, For example,
type int32 { type int32 {
range "-6378..0|42|100..max"; range "-6378..0|42|100..max";
} }
is mapped to the following RELAX NG fragment: is mapped to the following RELAX NG fragment:
skipping to change at page 72, line 49 skipping to change at page 71, line 49
<rng:param name="maxLength">...</rng:param> <rng:param name="maxLength">...</rng:param>
Their contents are the lower and upper bound of the length range, Their contents are the lower and upper bound of the length range,
respectively. If the lower bound is "min", the "minLength" facet respectively. If the lower bound is "min", the "minLength" facet
is omitted and if the upper bound is "max", the "maxLength" facet is omitted and if the upper bound is "max", the "maxLength" facet
is omitted. is omitted.
If the length expression has of multiple parts separated by "|", then If the length expression has of multiple parts separated by "|", then
the parent <rng:data> element must be repeated once for every range the parent <rng:data> element must be repeated once for every range
part and all the <rng:data> elements are wrapped in <rng:choice> part and all such <rng:data> elements are wrapped in <rng:choice>
element. Each <rng:data> element contains the "length" or element. Each <rng:data> element contains the "length" or
"minLength" and "maxLength" facets for the corresponding part of the "minLength" and "maxLength" facets for one part of the length
length expression as described in the previous paragraph. expression as described in the previous paragraph.
Every 'pattern' restriction of the "string" datatype is mapped to the Every 'pattern' restriction of the "string" datatype is mapped to the
"pattern" facet "pattern" facet
<rng:param name="pattern">...</rng:param> <rng:param name="pattern">...</rng:param>
with content equal to the argument of the 'pattern' statement. All with content equal to the argument of the 'pattern' statement. All
such "pattern" facets must be repeated inside each copy of the <rng: such "pattern" facets must be repeated inside each copy of the <rng:
data> element, i.e., once for each length range. data> element, i.e., once for each length range.
skipping to change at page 73, line 44 skipping to change at page 72, line 44
11.53.10. Derived Types 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 type definition MUST
found and its mapping installed as a subelement of <rng:grammar>, be found and its mapping installed as a subelement of <rng:
see Section 11.54. Even if a given derived type is used more grammar>, see Section 11.54. Even if a given derived type is
than once in the input YANG modules, the mapping of the used more 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 ancestor built-in type for 2. If any restrictions are present, the ancestor built-in type for
the given derived type must be determined and the mapping of this the given derived type must be determined and the mapping of this
base type is used. Restrictions appearing at all stages of the base type MUST be used. Restrictions appearing at all stages of
derivation chain must be taken into account and their conjunction the type derivation chain MUST be taken into account and their
added to the <rng:data> element which defines the basic type. conjunction added to the <rng:data> element which defines the
basic type.
See Section 9.2.2 for more details and an example. See Section 9.2.2 for more details and an example.
11.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 9.2. rules specified in Section 9.2.
Whenever a derived type is used with additional restrictions, the Whenever a derived type is used with additional restrictions, the
ancestor built-in type for the derived type is used instead with ancestor built-in type for the derived type is used instead with
restrictions (facets) that are a combination of all restrictions restrictions (facets) that are a combination of all restrictions
specified along the type derivation chain. See Section 11.53.10 for specified along the type derivation chain. See Section 11.53.10 for
further details and an example. further details and an example.
skipping to change at page 74, line 38 skipping to change at page 73, line 39
11.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"
11.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. Implementations MAY ignore this statement.
11.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, i.e., a reference to a named
attribute is set to ARGUMENT mangled according to Section 9.2 pattern, and the value of its @name attribute is set to ARGUMENT
mangled according to Section 9.2. If the RELAX NG definition of the
referenced named pattern has not been added to the output schema yet,
the corresponding grouping MUST be found and its mapping installed as
a subelement of <rng:grammar>, see Section 11.20.
If there are any 'refine' or 'augment' substatements, the Otherwise, if the 'uses' statement has any 'refine' or 'augment'
corresponding grouping must be looked up and its contents is inserted substatements, the corresponding grouping must be looked up and its
under PARENT. See Section 9.2.1 for further details and an example. contents is inserted under PARENT. See Section 9.2.1 for further
details and an example.
11.58. The value Statement 11.58. The value Statement
This statement is ignored. This statement is ignored.
11.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 9.3, becomes it value. translated according to Section 9.3, becomes it value.
skipping to change at page 76, line 20 skipping to change at page 75, line 20
described in Section 10. 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.
12.1. The @nma:config Annotation 12.1. The @nma:config Annotation
If this annotation is present with the value "true", the following If this annotation is present with the value "false", the following
rules apply for DSDL schemas of <nc:get-config> reply. In rules MUST be observed for DSDL schemas of <nc:get-config> reply:
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.
12.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
skipping to change at page 77, line 16 skipping to change at page 76, line 16
The element pointed to by "CONTELEM" must exist. The element pointed to by "CONTELEM" must exist.
</sch:assert> </sch:assert>
The nmf:evaluate() function is an XSLT extension function (see The nmf:evaluate() function is an XSLT extension function (see
Extension Functions in [XSLT]) that evaluates an XPath expression at Extension Functions in [XSLT]) that evaluates an XPath expression at
runtime. Such an extension function is provided by some XSLT runtime. Such an extension function is provided by some XSLT
processors, for example Saxon [3]. processors, for example Saxon [3].
12.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 attribute has the value "k_1 k_2 ... k_n",
specifies n child leaves as keys. The annotation is then mapped to i.e., specifies n children of CONTELEM as list keys. The annotation
the following Schematron report: is then mapped to 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 sub-expression C_i, for i=1,2,...,n, specifies the condition for
uniqueness of key k_i, namely violation of uniqueness of key k_i, namely
k_i=current()/k_i k_i=current()/k_i
12.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>
skipping to change at page 79, line 10 skipping to change at page 78, line 10
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".
12.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 when "EXPRESSION" is true.
</sch:assert> </sch:assert>
where EXPRESSION is the value of @nma:when. where EXPRESSION is the value of @nma:when.
13. IANA Considerations 13. IANA Considerations
This document registers three namespace URIs in the IETF XML registry This document registers three namespace URIs in the IETF XML registry
[RFC3688]: [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 URI: urn:ietf:params:xml:ns:netmod:xpath-extensions:1
14. Security Considerations 14. Security Considerations
This document defines a procedure that maps data models expressed in This document defines a procedure that maps data models expressed in
the YANG language to a coordinated set of DSDL schemas. The the YANG language to a coordinated set of DSDL schemas. The
procedure itself has no security impact on the Internet. procedure itself has no security impact on the Internet.
DSDL schemas obtained by the mapping procedure may be used for DSDL schemas obtained by the mapping procedure may be used for
validating the content of NETCONF protocol data units or entire data validating the content of NETCONF protocol data units or entire
stores and thus provide additional validity checks above those datastores and thus provide additional validity checks above those
performed by NETCONF server and client implementations supporting performed by NETCONF server and client implementations supporting
YANG data models. The strictness of this validation is directly YANG data models. The strictness of this validation is directly
derived from the source YANG modules that the validated XML data derived from the source YANG modules that the validated XML data
adhere to. adhere to.
15. Acknowledgements 15. Acknowledgments
The authors wish to thank the following individuals who provided The authors wish to thank the following individuals who provided
helpful suggestions and/or comments on various versions of this helpful suggestions and/or comments on various versions of this
document: Andy Bierman, Martin Bjorklund, Jirka Kosek and Phil document: Andy Bierman, Martin Bjorklund, Jirka Kosek and Phil
Shafer. Shafer.
16. References 16. References
16.1. Normative References 16.1. Normative References
skipping to change at page 84, line 6 skipping to change at page 83, line 6
[RNG-DTD] Clark, J., Ed. and M. Murata, Ed., "RELAX NG DTD [RNG-DTD] Clark, J., Ed. and M. Murata, Ed., "RELAX NG DTD
Compatibility", OASIS Committee Specification 3 December Compatibility", OASIS Committee Specification 3 December
2001, December 2001. 2001, December 2001.
[Schematron] [Schematron]
ISO/IEC, "Information Technology - Document Schema ISO/IEC, "Information Technology - Document Schema
Definition Languages (DSDL) - Part 3: Rule-Based Definition Languages (DSDL) - Part 3: Rule-Based
Validation - Schematron", ISO/IEC 19757-3:2006(E), 6 2006. Validation - Schematron", ISO/IEC 19757-3:2006(E), 6 2006.
[XML] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and [XML] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and
F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fourth F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth
Edition)", World Wide Web Consortium Recommendation REC- Edition)", World Wide Web Consortium Recommendation REC-
xml-20060816, August 2006, xml-20081126, November 2008,
<http://www.w3.org/TR/2006/REC-xml-20060816>. <http://www.w3.org/TR/2006/REC-xml-20060816>.
[XPath] Clark, J. and S. DeRose, "XML Path Language (XPath) [XPath] Clark, J. and S. DeRose, "XML Path Language (XPath)
Version 1.0", World Wide Web Consortium Version 1.0", World Wide Web Consortium
Recommendation REC-xpath-19991116, November 1999, Recommendation REC-xpath-19991116, November 1999,
<http://www.w3.org/TR/1999/REC-xpath-19991116>. <http://www.w3.org/TR/1999/REC-xpath-19991116>.
[XSD-D] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes [XSD-D] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes
Second Edition", World Wide Web Consortium Second Edition", World Wide Web Consortium
Recommendation REC-xmlschema-2-20041028, October 2004, Recommendation REC-xmlschema-2-20041028, October 2004,
<http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>. <http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.
[XSLT] Clark, J., "XSL Transformations (XSLT) Version 1.0", World [XSLT] Clark, J., "XSL Transformations (XSLT) Version 1.0", World
Wide Web Consortium Recommendation REC-xslt-19991116, Wide Web Consortium Recommendation REC-xslt-19991116,
November 1999. November 1999.
[YANG] Bjorklund, M., Ed., "YANG - A data modeling language for [YANG] Bjorklund, M., Ed., "YANG - A data modeling language for
NETCONF", draft-ietf-netmod-yang-04 (work in progress), NETCONF", draft-ietf-netmod-yang-11 (work in progress),
March 2009. Febuary 2010.
[Ytypes] Schoenwaelder, J., Ed., "Common YANG Data Types",
draft-ietf-netmod-yang-types-07 (work in progress),
February 2010.
16.2. Informative References 16.2. Informative References
[RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin,
"Simple Network Management Protocol (SNMP)", STD 15, "Simple Network Management Protocol (SNMP)", STD 15,
RFC 1157, May 1990. RFC 1157, May 1990.
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Structure of Management Information Schoenwaelder, Ed., "Structure of Management Information
Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
skipping to change at page 85, line 5 skipping to change at page 85, line 5
Notifications", RFC 5277, July 2008. Notifications", RFC 5277, July 2008.
[Vli04] van der Vlist, E., "RELAX NG", O'Reilly , 2004. [Vli04] van der Vlist, E., "RELAX NG", O'Reilly , 2004.
[XSD] Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, [XSD] Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn,
"XML Schema Part 1: Structures Second Edition", World Wide "XML Schema Part 1: Structures Second Edition", World Wide
Web Consortium Recommendation REC-xmlschema-1-20041028, Web Consortium Recommendation REC-xmlschema-1-20041028,
October 2004, October 2004,
<http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>. <http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>.
[Ytypes] Schoenwaelder, J., Ed., "Common YANG Data Types",
draft-ietf-netmod-yang-types-03 (work in progress),
May 2009.
URIs URIs
[1] <http://www.thaiopensource.com/relaxng/trang.html> [1] <http://www.thaiopensource.com/relaxng/trang.html>
[2] <http://dublincore.org/> [2] <http://dublincore.org/>
[3] <http://www.saxonica.com/> [3] <http://www.saxonica.com/>
[4] <http://www.yang-central.org/twiki/bin/view/Main/DhcpTutorial> [4] <http://www.yang-central.org/twiki/bin/view/Main/DhcpTutorial>
skipping to change at page 87, line 30 skipping to change at page 86, line 30
URI "urn:ietf:params:xml:ns:netmod:dsdl-annotations:1" are URI "urn:ietf:params:xml:ns:netmod:dsdl-annotations:1" are
validated by several context-dependent RELAX NG schemas given validated by several context-dependent RELAX NG schemas given
below. below.
3. Other sections such as Dublin Core metadata or <a:documentation> 3. Other sections such as Dublin Core metadata or <a:documentation>
annotation are attached to and validated together with the parent annotation are attached to and validated together with the parent
RELAX NG section. RELAX NG section.
A.1. NVDL Schema A.1. NVDL Schema
== CODE BEGINS: file "nmannot.nvdl" <CODE BEGINS> file "nmannot.nvdl"
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE nvdl:rules [<!ENTITY nmannot-uri <!DOCTYPE nvdl:rules [<!ENTITY nmannot-uri
"urn:ietf:params:xml:ns:netmod:dsdl-annotations:1"> "urn:ietf:params:xml:ns:netmod:dsdl-annotations:1">
]> ]>
<rules xmlns="http://purl.oclc.org/dsdl/nvdl/ns/structure/1.0" <rules xmlns="http://purl.oclc.org/dsdl/nvdl/ns/structure/1.0"
startMode="rng"> startMode="rng">
<mode name="rng"> <mode name="rng">
<namespace ns="http://relaxng.org/ns/structure/1.0"> <namespace ns="http://relaxng.org/ns/structure/1.0">
<validate schema="http://relaxng.org/relaxng.rng" <validate schema="http://relaxng.org/relaxng.rng"
skipping to change at page 88, line 46 skipping to change at page 87, line 46
<mode name="other"> <mode name="other">
<namespace ns="&nmannot-uri;" match="elements attributes"> <namespace ns="&nmannot-uri;" match="elements attributes">
<reject/> <reject/>
</namespace> </namespace>
<anyNamespace match="elements attributes"> <anyNamespace match="elements attributes">
<attach/> <attach/>
</anyNamespace> </anyNamespace>
</mode> </mode>
</rules> </rules>
== CODE ENDS <CODE ENDS>
A.2. Annotation Attributes for define Pattern A.2. Annotation Attributes for define Pattern
== CODE BEGINS: file "define.rng" <CODE BEGINS> file "define.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">
<include href="nmannotdefs.rng"/> <include href="nmannotdefs.rng"/>
<start> <start>
<group> <group>
<ref name="default-attribute"/> <ref name="default-attribute"/>
<ref name="status-attribute"/> <ref name="status-attribute"/>
<ref name="units-attribute"/> <ref name="units-attribute"/>
</group> </group>
</start> </start>
</grammar> </grammar>
== CODE ENDS <CODE ENDS>
A.3. Annotation Elements for element Pattern A.3. Annotation Elements for element Pattern
== CODE BEGINS: file "element-el.rng" <CODE BEGINS> file "element-el.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">
<include href="nmannotdefs.rng"/> <include href="nmannotdefs.rng"/>
<start> <start>
<choice> <choice>
<ref name="must-element"/> <ref name="must-element"/>
<ref name="instance-identifier-element"/> <ref name="instance-identifier-element"/>
</choice> </choice>
</start> </start>
</grammar> </grammar>
== CODE ENDS <CODE ENDS>
A.4. Annotation Attributes for element Pattern A.4. Annotation Attributes for element Pattern
== CODE BEGINS: file "element-att.rng" <CODE BEGINS> file "element-att.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">
<include href="nmannotdefs.rng"/> <include href="nmannotdefs.rng"/>
<start> <start>
<group> <group>
<ref name="config-attribute"/> <ref name="config-attribute"/>
<ref name="default-attribute"/> <ref name="default-attribute"/>
<ref name="implicit-attribute"/> <ref name="implicit-attribute"/>
<ref name="leafref-attribute"/> <ref name="leafref-attribute"/>
<ref name="presence-attribute"/> <ref name="presence-attribute"/>
<ref name="status-attribute"/> <ref name="status-attribute"/>
<ref name="units-attribute"/> <ref name="units-attribute"/>
<ref name="when-attribute"/> <ref name="when-attribute"/>
</group> </group>
</start> </start>
</grammar> </grammar>
== CODE ENDS <CODE ENDS>
A.5. Annotation attributes for group Pattern A.5. Annotation attributes for group Pattern
== CODE BEGINS: file "group-interleave.rng" <CODE BEGINS> file "group-interleave.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">
<include href="nmannotdefs.rng"/> <include href="nmannotdefs.rng"/>
<start> <start>
<group> <group>
<ref name="implicit-attribute"/> <ref name="implicit-attribute"/>
<ref name="status-attribute"/> <ref name="status-attribute"/>
<ref name="when-attribute"/> <ref name="when-attribute"/>
</group> </group>
</start> </start>
</grammar> </grammar>
== CODE ENDS <CODE ENDS>
A.6. Annotation attributes for choice and ref Patterns A.6. Annotation attributes for choice and ref Patterns
== CODE BEGINS: file "choice-ref.rng" <CODE BEGINS> file "choice-ref.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">
<include href="nmannotdefs.rng"/> <include href="nmannotdefs.rng"/>
<start> <start>
<group> <group>
<ref name="status-attribute"/> <ref name="status-attribute"/>
<ref name="when-attribute"/> <ref name="when-attribute"/>
</group> </group>
</start> </start>
</grammar> </grammar>
== CODE ENDS <CODE ENDS>
A.7. Annotation attributes for element Pattern in the List Context A.7. Annotation attributes for element Pattern in the List Context
== CODE BEGINS: file "list.rng" <CODE BEGINS> file "list.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">
<include href="nmannotdefs.rng"/> <include href="nmannotdefs.rng"/>
<start> <start>
<group> <group>
<ref name="key-attribute"/> <ref name="key-attribute"/>
<ref name="min-elements-attribute"/> <ref name="min-elements-attribute"/>
<ref name="max-elements-attribute"/> <ref name="max-elements-attribute"/>
<ref name="ordered-by-attribute"/> <ref name="ordered-by-attribute"/>
<ref name="unique-attribute"/> <ref name="unique-attribute"/>
</group> </group>
</start> </start>
</grammar> </grammar>
== CODE ENDS <CODE ENDS>
A.8. Annotation attributes for value Pattern A.8. Annotation attributes for value Pattern
== CODE BEGINS: file "value.rng" <CODE BEGINS> file "value.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">
<include href="nmannotdefs.rng"/> <include href="nmannotdefs.rng"/>
<start> <start>
<ref name="status-attribute"/> <ref name="status-attribute"/>
</start> </start>
</grammar> </grammar>
== CODE ENDS <CODE ENDS>
A.9. Named Patterns for All NETMOD-Specific Annotations A.9. Named Patterns for All NETMOD-Specific Annotations
== CODE BEGINS: file "nmannotdefs.rng" <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">
<optional> <optional>
<attribute name="nma:config"> <attribute name="nma:config">
<data type="boolean"/> <data type="boolean"/>
skipping to change at page 95, line 36 skipping to change at page 94, line 36
<define name="when-attribute"> <define name="when-attribute">
<optional> <optional>
<attribute name="nma:when"> <attribute name="nma:when">
<data type="string"/> <data type="string"/>
</attribute> </attribute>
</optional> </optional>
</define> </define>
</grammar> </grammar>
== CODE ENDS <CODE ENDS>
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 common named pattern definitions to
RELAX NG schemas generated in the second mapping step, we collected every RELAX NG schema generated in the second mapping step, the
these definitions to a library file - schema-independent library - definitions are collected in a library file - schema-independent
which is included by the validating schemas under the file name library - which is included by the validating schemas under the file
"relaxng-lib.rng" (XML syntax) and "relaxng-lib.rnc" (compact name "relaxng-lib.rng" (XML syntax) and "relaxng-lib.rnc" (compact
syntax). The included definitions cover patterns for common elements syntax). The included definitions cover patterns for common elements
from base NETCONF [RFC4741] and event notifications [RFC5277]. from base NETCONF [RFC4741] and event notifications [RFC5277].
== CODE BEGINS: file "relaxng-lib.rng" <CODE BEGINS> file "relaxng-lib.rng"
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<grammar xmlns="http://relaxng.org/ns/structure/1.0" <grammar xmlns="http://relaxng.org/ns/structure/1.0"
xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"
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">
skipping to change at page 96, line 45 skipping to change at page 95, 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>
== CODE ENDS <CODE ENDS>
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 [4] data model. The input applied to the "canonical" DHCP tutorial [4] data model. The single
(single) YANG module is shown in Appendix C.1 and the output schemas input YANG module is shown in Appendix C.1 and the output schemas in
in the following two subsections. 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 [5] 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 [6] 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
skipping to change at page 117, line 7 skipping to change at page 116, 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 -03 and -04 D.1. Changes Between Versions -04 and -05
o Leafs that take their default value from a typedef and are not
annotated with @nma:default must have @nma:implicit="true".
o Changed code markers CODE BEGINS/ENDS to the form agreed by the
WG.
o Derived types "date-and-time" and "uri" SHOULD be mapped to XSD
"dateTime" and "anyURI" types, respectively.
o Clarified the notion of implicit nodes under under 'case' in
Section 9.1.2.
o Moved draft-ietf-netmod-yang-types-06 to normative references.
o An extra <rng:group> is no more required for the default case of a
choice in the shorthand notation.
D.2. Changes Between Versions -03 and -04
o Implemented ordering rules for list children - keys must go first o Implemented ordering rules for list children - keys must go first
and appear in the same order as in the input YANG module. and appear in the same order as in the input YANG module.
o The 'case' statement is now mapped to either <rng:group> (inside o The 'case' statement is now mapped to either <rng:group> (inside
RPCs) or <rng:interleave> (otherwise). RPCs) or <rng:interleave> (otherwise).
o A nma:default annotation coming from a datatype which the mapping o A nma:default annotation coming from a datatype which the mapping
expands is attached to the <rng:element> pattern where the expands is attached to the <rng:element> pattern where the
expansion occurs. Added an example. expansion occurs. Added an example.
skipping to change at page 117, line 39 skipping to change at page 117, line 11
o Added CODE BEGINS/ENDS markers. o Added CODE BEGINS/ENDS markers.
o Separated normative and informative references. o Separated normative and informative references.
o Added URL for XPath extensions namespace. o Added URL for XPath extensions namespace.
o Added Section 2 (Terminology and Notation). o Added Section 2 (Terminology and Notation).
o Added Section 14 (Security Considerations). o Added Section 14 (Security Considerations).
o Added Section 15 (Acknowledgements). o Added Section 15 (Acknowledgments).
o Removed compact syntax schema from Appendix B. o Removed compact syntax schema from Appendix B.
o Editorial changes: symbolic citation labels. o Editorial changes: symbolic citation labels.
D.2. Changes Between Versions -02 and -03 D.3. 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 10.2. o Added skeleton rule to Section 10.2.
o Reworked Section 10.4, added skeleton element maps,corrected the o Reworked Section 10.4, added skeleton element maps,corrected the
example. example.
skipping to change at page 118, line 28 skipping to change at page 117, line 48
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.
D.3. Changes Between Versions -01 and -02 D.4. Changes Between Versions -01 and -02
o Moved Section 7 "NETCONF Content Validation" after Section 6. o Moved Section 7 "NETCONF Content Validation" after Section 6.
o New text about mapping defaults to DSRL, especially in Section 7 o New text about mapping defaults to DSRL, especially in Section 7
and Section 10.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.
skipping to change at page 119, line 5 skipping to change at page 118, line 25
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.
D.4. Changes Between Versions -00 and -01 D.5. 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'.
 End of changes. 183 change blocks. 
483 lines changed or deleted 545 lines changed or added

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