draft-ietf-netmod-dsdl-map-02.txt   draft-ietf-netmod-dsdl-map-03.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: October 31, 2009 Plantronics Expires: January 14, 2010 Plantronics
S. Chisholm S. Chisholm
Nortel Nortel
April 29, 2009 July 13, 2009
Mapping YANG to Document Schema Definition Languages and Validating Mapping YANG to Document Schema Definition Languages and Validating
NETCONF Content NETCONF Content
draft-ietf-netmod-dsdl-map-02 draft-ietf-netmod-dsdl-map-03
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 31, 2009. This Internet-Draft will expire on January 14, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. and restrictions with respect to this document.
Abstract Abstract
This draft describes the mapping rules for translating YANG data This draft specifies the mapping rules for translating YANG data
models into XML schemas using Document Schema Definition Languages models into Document Schema Definition Languages (DSDL), a
(DSDL) and outlines the procedure for validating various types of coordinated set of XML schema languages standardized as ISO 19757.
NETCONF protocol data units using these schemas. 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. Objectives and Motivation . . . . . . . . . . . . . . . . . . 9 2. Objectives and Motivation . . . . . . . . . . . . . . . . . . 9
3. DSDL Schema Languages . . . . . . . . . . . . . . . . . . . . 11 3. DSDL Schema Languages . . . . . . . . . . . . . . . . . . . . 11
3.1. RELAX NG . . . . . . . . . . . . . . . . . . . . . . . . 11 3.1. RELAX NG . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2. Schematron . . . . . . . . . . . . . . . . . . . . . . . 12 3.2. Schematron . . . . . . . . . . . . . . . . . . . . . . . 12
3.3. Document Semantics Renaming Language (DSRL) . . . . . . 13 3.3. Document Semantics Renaming Language (DSRL) . . . . . . 13
4. Additional Annotations . . . . . . . . . . . . . . . . . . . 14 4. Additional Annotations . . . . . . . . . . . . . . . . . . . 14
4.1. Dublin Core Metadata Elements . . . . . . . . . . . . . 14 4.1. Dublin Core Metadata Elements . . . . . . . . . . . . . 14
4.2. RELAX NG DTD Compatibility Annotations . . . . . . . . . 14 4.2. RELAX NG DTD Compatibility Annotations . . . . . . . . . 14
4.3. NETMOD-specific Annotations . . . . . . . . . . . . . . 15 4.3. NETMOD-Specific Annotations . . . . . . . . . . . . . . 15
5. Overview of the Mapping . . . . . . . . . . . . . . . . . . . 17 5. Overview of the Mapping . . . . . . . . . . . . . . . . . . . 17
6. NETCONF Content Validation . . . . . . . . . . . . . . . . . 19 6. NETCONF Content Validation . . . . . . . . . . . . . . . . . 19
7. Design Considerations . . . . . . . . . . . . . . . . . . . . 20 7. Design Considerations . . . . . . . . . . . . . . . . . . . . 20
7.1. Conceptual Data Tree . . . . . . . . . . . . . . . . . . 20 7.1. Conceptual Data Tree . . . . . . . . . . . . . . . . . . 20
7.2. Modularity . . . . . . . . . . . . . . . . . . . . . . . 22 7.2. Modularity . . . . . . . . . . . . . . . . . . . . . . . 22
7.3. Granularity . . . . . . . . . . . . . . . . . . . . . . 23 7.3. Granularity . . . . . . . . . . . . . . . . . . . . . . 23
7.4. Handling of XML Namespaces . . . . . . . . . . . . . . . 23 7.4. Handling of XML Namespaces . . . . . . . . . . . . . . . 23
7.5. Features and Deviations . . . . . . . . . . . . . . . . 24
8. Mapping YANG Data Models to the Conceptual Tree Schema . . . 25 8. Mapping YANG Data Models to the Conceptual Tree Schema . . . 25
8.1. Optional and Mandatory Content . . . . . . . . . . . . . 25 8.1. Occurrence Rules for Data Nodes . . . . . . . . . . . . 25
8.2. Mapping YANG Groupings and Typedefs . . . . . . . . . . 26 8.1.1. Optional and Mandatory Nodes . . . . . . . . . . . 26
8.2.1. YANG Refinements and Augments . . . . . . . . . . . 28 8.1.2. Implicit Nodes . . . . . . . . . . . . . . . . . . 27
8.2.2. Type derivation chains . . . . . . . . . . . . . . 31 8.2. Mapping YANG Groupings and Typedefs . . . . . . . . . . 28
8.3. Translation of XPath Expressions . . . . . . . . . . . . 32 8.2.1. YANG Refinements and Augments . . . . . . . . . . . 30
8.4. YANG Language Extensions . . . . . . . . . . . . . . . . 33 8.2.2. Type derivation chains . . . . . . . . . . . . . . 33
9. Mapping Conceptual Tree Schema to DSDL . . . . . . . . . . . 35 8.3. Translation of XPath Expressions . . . . . . . . . . . . 34
9.1. Generating RELAX NG Schemas for Various Document Types . 35 8.4. YANG Language Extensions . . . . . . . . . . . . . . . . 35
9.1.1. Reply to <get> or <get-config> . . . . . . . . . . 36 9. Mapping Conceptual Tree Schema to DSDL . . . . . . . . . . . 37
9.1.2. Remote Procedure Calls . . . . . . . . . . . . . . 36 9.1. Generating RELAX NG Schemas for Various Document Types . 37
9.1.3. Notifications . . . . . . . . . . . . . . . . . . . 37 9.1.1. Reply to <get> or <get-config> . . . . . . . . . . 38
9.2. Mapping Semantic Constraints to Schematron . . . . . . . 38 9.1.2. Remote Procedure Calls . . . . . . . . . . . . . . 38
9.2.1. Validation Phases . . . . . . . . . . . . . . . . . 41 9.1.3. Notifications . . . . . . . . . . . . . . . . . . . 39
9.3. Constraints on Mandatory Choice . . . . . . . . . . . . 42 9.2. Mapping Semantic Constraints to Schematron . . . . . . . 40
9.4. Mapping Default Values to DSRL . . . . . . . . . . . . . 44 9.2.1. Validation Phases . . . . . . . . . . . . . . . . . 43
10. Mapping YANG Statements to Annotated RELAX NG . . . . . . . . 47 9.3. Constraints on Mandatory Choice . . . . . . . . . . . . 44
10.1. The anyxml Statement . . . . . . . . . . . . . . . . . . 47 9.4. Mapping Default Values to DSRL . . . . . . . . . . . . . 46
10.2. The argument Statement . . . . . . . . . . . . . . . . . 48 10. Mapping YANG Statements to Conceptual Tree Schema . . . . . . 50
10.3. The augment Statement . . . . . . . . . . . . . . . . . 48 10.1. The anyxml Statement . . . . . . . . . . . . . . . . . . 50
10.4. The base Statement . . . . . . . . . . . . . . . . . . . 49 10.2. The argument Statement . . . . . . . . . . . . . . . . . 51
10.5. The belongs-to Statement . . . . . . . . . . . . . . . . 49 10.3. The augment Statement . . . . . . . . . . . . . . . . . 52
10.6. The bit Statement . . . . . . . . . . . . . . . . . . . 49 10.4. The base Statement . . . . . . . . . . . . . . . . . . . 52
10.7. The case Statement . . . . . . . . . . . . . . . . . . . 49 10.5. The belongs-to Statement . . . . . . . . . . . . . . . . 52
10.8. The choice Statement . . . . . . . . . . . . . . . . . . 49 10.6. The bit Statement . . . . . . . . . . . . . . . . . . . 52
10.9. The config Statement . . . . . . . . . . . . . . . . . . 49 10.7. The case Statement . . . . . . . . . . . . . . . . . . . 52
10.10. The contact Statement . . . . . . . . . . . . . . . . . 49 10.8. The choice Statement . . . . . . . . . . . . . . . . . . 52
10.11. The container Statement . . . . . . . . . . . . . . . . 50 10.9. The config Statement . . . . . . . . . . . . . . . . . . 53
10.12. The default Statement . . . . . . . . . . . . . . . . . 50 10.10. The contact Statement . . . . . . . . . . . . . . . . . 53
10.13. The description Statement . . . . . . . . . . . . . . . 51 10.11. The container Statement . . . . . . . . . . . . . . . . 53
10.14. The deviation Statement . . . . . . . . . . . . . . . . 51 10.12. The default Statement . . . . . . . . . . . . . . . . . 53
10.15. The enum Statement . . . . . . . . . . . . . . . . . . . 51 10.13. The description Statement . . . . . . . . . . . . . . . 54
10.16. The error-app-tag Statement . . . . . . . . . . . . . . 51 10.14. The deviation Statement . . . . . . . . . . . . . . . . 54
10.17. The error-message Statement . . . . . . . . . . . . . . 51 10.15. The enum Statement . . . . . . . . . . . . . . . . . . . 54
10.18. The extension Statement . . . . . . . . . . . . . . . . 51 10.16. The error-app-tag Statement . . . . . . . . . . . . . . 55
10.19. The feature Statement . . . . . . . . . . . . . . . . . 51 10.17. The error-message Statement . . . . . . . . . . . . . . 55
10.20. The grouping Statement . . . . . . . . . . . . . . . . . 52 10.18. The extension Statement . . . . . . . . . . . . . . . . 55
10.21. The identity Statement . . . . . . . . . . . . . . . . . 52 10.19. The feature Statement . . . . . . . . . . . . . . . . . 55
10.22. The if-feature Statement . . . . . . . . . . . . . . . . 52 10.20. The grouping Statement . . . . . . . . . . . . . . . . . 55
10.23. The import Statement . . . . . . . . . . . . . . . . . . 52 10.21. The identity Statement . . . . . . . . . . . . . . . . . 55
10.24. The include Statement . . . . . . . . . . . . . . . . . 53 10.22. The if-feature Statement . . . . . . . . . . . . . . . . 56
10.25. The input Statement . . . . . . . . . . . . . . . . . . 53 10.23. The import Statement . . . . . . . . . . . . . . . . . . 56
10.26. The key Statement . . . . . . . . . . . . . . . . . . . 53 10.24. The include Statement . . . . . . . . . . . . . . . . . 56
10.27. The leaf Statement . . . . . . . . . . . . . . . . . . . 53 10.25. The input Statement . . . . . . . . . . . . . . . . . . 56
10.28. The leaf-list Statement . . . . . . . . . . . . . . . . 53 10.26. The key Statement . . . . . . . . . . . . . . . . . . . 56
10.29. The length Statement . . . . . . . . . . . . . . . . . . 54 10.27. The leaf Statement . . . . . . . . . . . . . . . . . . . 56
10.30. The list Statement . . . . . . . . . . . . . . . . . . . 54 10.28. The leaf-list Statement . . . . . . . . . . . . . . . . 57
10.31. The mandatory Statement . . . . . . . . . . . . . . . . 54 10.29. The length Statement . . . . . . . . . . . . . . . . . . 57
10.32. The max-elements Statement . . . . . . . . . . . . . . . 54 10.30. The list Statement . . . . . . . . . . . . . . . . . . . 58
10.33. The min-elements Statement . . . . . . . . . . . . . . . 54 10.31. The mandatory Statement . . . . . . . . . . . . . . . . 58
10.34. The module Statement . . . . . . . . . . . . . . . . . . 55 10.32. The max-elements Statement . . . . . . . . . . . . . . . 58
10.35. The must Statement . . . . . . . . . . . . . . . . . . . 55 10.33. The min-elements Statement . . . . . . . . . . . . . . . 58
10.36. The namespace Statement . . . . . . . . . . . . . . . . 55 10.34. The module Statement . . . . . . . . . . . . . . . . . . 58
10.37. The notification Statement . . . . . . . . . . . . . . . 56 10.35. The must Statement . . . . . . . . . . . . . . . . . . . 58
10.38. The ordered-by Statement . . . . . . . . . . . . . . . . 56 10.36. The namespace Statement . . . . . . . . . . . . . . . . 59
10.39. The organization Statement . . . . . . . . . . . . . . . 56 10.37. The notification Statement . . . . . . . . . . . . . . . 59
10.40. The output Statement . . . . . . . . . . . . . . . . . . 56 10.38. The ordered-by Statement . . . . . . . . . . . . . . . . 59
10.41. The path Statement . . . . . . . . . . . . . . . . . . . 56 10.39. The organization Statement . . . . . . . . . . . . . . . 60
10.42. The pattern Statement . . . . . . . . . . . . . . . . . 56 10.40. The output Statement . . . . . . . . . . . . . . . . . . 60
10.43. The position Statement . . . . . . . . . . . . . . . . . 57 10.41. The path Statement . . . . . . . . . . . . . . . . . . . 60
10.44. The prefix Statement . . . . . . . . . . . . . . . . . . 57 10.42. The pattern Statement . . . . . . . . . . . . . . . . . 60
10.45. The presence Statement . . . . . . . . . . . . . . . . . 57 10.43. The position Statement . . . . . . . . . . . . . . . . . 60
10.46. The range Statement . . . . . . . . . . . . . . . . . . 57 10.44. The prefix Statement . . . . . . . . . . . . . . . . . . 60
10.47. The reference Statement . . . . . . . . . . . . . . . . 57 10.45. The presence Statement . . . . . . . . . . . . . . . . . 60
10.48. The require-instance Statement . . . . . . . . . . . . . 57 10.46. The range Statement . . . . . . . . . . . . . . . . . . 60
10.49. The revision Statement . . . . . . . . . . . . . . . . . 57 10.47. The reference Statement . . . . . . . . . . . . . . . . 60
10.50. The rpc Statement . . . . . . . . . . . . . . . . . . . 58 10.48. The require-instance Statement . . . . . . . . . . . . . 61
10.51. The status Statement . . . . . . . . . . . . . . . . . . 58 10.49. The revision Statement . . . . . . . . . . . . . . . . . 61
10.52. The submodule Statement . . . . . . . . . . . . . . . . 58 10.50. The rpc Statement . . . . . . . . . . . . . . . . . . . 61
10.53. The type Statement . . . . . . . . . . . . . . . . . . . 58 10.51. The status Statement . . . . . . . . . . . . . . . . . . 62
10.53.1. The empty Type . . . . . . . . . . . . . . . . . . 59 10.52. The submodule Statement . . . . . . . . . . . . . . . . 62
10.53.2. The boolean and binary Types . . . . . . . . . . . 59 10.53. The type Statement . . . . . . . . . . . . . . . . . . . 62
10.53.3. The bits Type . . . . . . . . . . . . . . . . . . . 60 10.53.1. The empty Type . . . . . . . . . . . . . . . . . . 63
10.53.4. The enumeration and union Types . . . . . . . . . . 60 10.53.2. The boolean and binary Types . . . . . . . . . . . 63
10.53.5. The identityref Type . . . . . . . . . . . . . . . 60 10.53.3. The bits Type . . . . . . . . . . . . . . . . . . . 63
10.53.6. The instance-identifier Type . . . . . . . . . . . 62 10.53.4. The enumeration and union Types . . . . . . . . . . 63
10.53.7. The leafref Type . . . . . . . . . . . . . . . . . 62 10.53.5. The identityref Type . . . . . . . . . . . . . . . 63
10.53.8. The numeric Types . . . . . . . . . . . . . . . . . 62 10.53.6. The instance-identifier Type . . . . . . . . . . . 65
10.53.9. The string Type . . . . . . . . . . . . . . . . . . 63 10.53.7. The leafref Type . . . . . . . . . . . . . . . . . 65
10.53.10. Derived Types . . . . . . . . . . . . . . . . . . . 64 10.53.8. The numeric Types . . . . . . . . . . . . . . . . . 65
10.54. The typedef Statement . . . . . . . . . . . . . . . . . 64 10.53.9. The string Type . . . . . . . . . . . . . . . . . . 67
10.55. The unique Statement . . . . . . . . . . . . . . . . . . 65 10.53.10. Derived Types . . . . . . . . . . . . . . . . . . . 67
10.56. The units Statement . . . . . . . . . . . . . . . . . . 65 10.54. The typedef Statement . . . . . . . . . . . . . . . . . 68
10.57. The uses Statement . . . . . . . . . . . . . . . . . . . 65 10.55. The unique Statement . . . . . . . . . . . . . . . . . . 68
10.58. The value Statement . . . . . . . . . . . . . . . . . . 65 10.56. The units Statement . . . . . . . . . . . . . . . . . . 68
10.59. The when Statement . . . . . . . . . . . . . . . . . . . 65 10.57. The uses Statement . . . . . . . . . . . . . . . . . . . 69
10.60. The yang-version Statement . . . . . . . . . . . . . . . 65 10.58. The value Statement . . . . . . . . . . . . . . . . . . 69
10.61. The yin-element Statement . . . . . . . . . . . . . . . 66 10.59. The when Statement . . . . . . . . . . . . . . . . . . . 69
10.60. The yang-version Statement . . . . . . . . . . . . . . . 69
10.61. The yin-element Statement . . . . . . . . . . . . . . . 69
11. Mapping NETMOD-specific annotations to DSDL Schema 11. Mapping NETMOD-specific annotations to DSDL Schema
Languages . . . . . . . . . . . . . . . . . . . . . . . . . . 67 Languages . . . . . . . . . . . . . . . . . . . . . . . . . . 70
11.1. The @nma:config Annotation . . . . . . . . . . . . . . . 67 11.1. The @nma:config Annotation . . . . . . . . . . . . . . . 70
11.2. The @nma:default Annotation . . . . . . . . . . . . . . 67 11.2. The @nma:default Annotation . . . . . . . . . . . . . . 70
11.3. The @nma:default-case Annotation . . . . . . . . . . . . 67 11.3. The @nma:implicit Annotation . . . . . . . . . . . . . . 70
11.4. The <nma:error-app-tag> Annotation . . . . . . . . . . . 67 11.4. The <nma:error-app-tag> Annotation . . . . . . . . . . . 70
11.5. The <nma:error-message> Annotation . . . . . . . . . . . 67 11.5. The <nma:error-message> Annotation . . . . . . . . . . . 70
11.6. The <nma:instance-identifier> Annotation . . . . . . . . 67 11.6. The <nma:instance-identifier> Annotation . . . . . . . . 70
11.7. The @nma:key Annotation . . . . . . . . . . . . . . . . 68 11.7. The @nma:key Annotation . . . . . . . . . . . . . . . . 71
11.8. The <nma:leafref> Annotation . . . . . . . . . . . . . . 68 11.8. The @nma:leafref Annotation . . . . . . . . . . . . . . 71
11.9. The @nma:min-elements Annotation . . . . . . . . . . . . 69 11.9. The @nma:min-elements Annotation . . . . . . . . . . . . 71
11.10. The @nma:max-elements Annotation . . . . . . . . . . . . 69 11.10. The @nma:max-elements Annotation . . . . . . . . . . . . 72
11.11. The <nma:must> Annotation . . . . . . . . . . . . . . . 69 11.11. The <nma:must> Annotation . . . . . . . . . . . . . . . 72
11.12. The <nma:ordered-by> Annotation . . . . . . . . . . . . 69 11.12. The <nma:ordered-by> Annotation . . . . . . . . . . . . 72
11.13. The <nma:status> Annotation . . . . . . . . . . . . . . 69 11.13. The <nma:status> Annotation . . . . . . . . . . . . . . 72
11.14. The @nma:unique Annotation . . . . . . . . . . . . . . . 70 11.14. The @nma:unique Annotation . . . . . . . . . . . . . . . 72
11.15. The @nma:when Annotation . . . . . . . . . . . . . . . . 70 11.15. The @nma:when Annotation . . . . . . . . . . . . . . . . 73
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 71 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 74
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 72 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 75
Appendix A. RELAX NG Schema for NETMOD-specific Annotations . . 74 Appendix A. RELAX NG Schema for NETMOD-specific Annotations . . 77
A.1. XML Syntax . . . . . . . . . . . . . . . . . . . . . . . 74 A.1. XML Syntax . . . . . . . . . . . . . . . . . . . . . . . 77
A.2. Compact Syntax . . . . . . . . . . . . . . . . . . . . . 77 A.2. Compact Syntax . . . . . . . . . . . . . . . . . . . . . 80
Appendix B. Schema-Independent Library . . . . . . . . . . . . . 78 Appendix B. Schema-Independent Library . . . . . . . . . . . . . 81
B.1. XML Syntax . . . . . . . . . . . . . . . . . . . . . . . 78 B.1. XML Syntax . . . . . . . . . . . . . . . . . . . . . . . 81
B.2. Compact Syntax . . . . . . . . . . . . . . . . . . . . . 79 B.2. Compact Syntax . . . . . . . . . . . . . . . . . . . . . 82
Appendix C. Mapping DHCP Data Model - A Complete Example . . . . 80 Appendix C. Mapping DHCP Data Model - A Complete Example . . . . 83
C.1. Input YANG Module . . . . . . . . . . . . . . . . . . . 80 C.1. Input YANG Module . . . . . . . . . . . . . . . . . . . 83
C.2. Conceptual Tree Schema . . . . . . . . . . . . . . . . . 83 C.2. Conceptual Tree Schema . . . . . . . . . . . . . . . . . 86
C.2.1. XML Syntax . . . . . . . . . . . . . . . . . . . . 83 C.2.1. XML Syntax . . . . . . . . . . . . . . . . . . . . 86
C.2.2. Compact Syntax . . . . . . . . . . . . . . . . . . 87 C.2.2. Compact Syntax . . . . . . . . . . . . . . . . . . 91
C.3. Final DSDL Schemas . . . . . . . . . . . . . . . . . . . 90 C.3. Final DSDL Schemas . . . . . . . . . . . . . . . . . . . 93
C.3.1. RELAX NG Schema for <get> Reply - XML Syntax . . . 90 C.3.1. RELAX NG Schema for <get> Reply - XML Syntax . . . 94
C.3.2. RELAX NG Schema for <get> Reply - Compact Syntax . 94 C.3.2. RELAX NG Schema for <get> Reply - Compact Syntax . 98
C.4. Schematron Schema for <get> Reply . . . . . . . . . . . 97 C.4. Schematron Schema for <get> Reply . . . . . . . . . . . 100
C.5. DSRL Schema for <get> Reply . . . . . . . . . . . . . . 98 C.5. DSRL Schema for <get> Reply . . . . . . . . . . . . . . 102
Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 99 Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 103
D.1. Changes Between Versions -01 and -02 . . . . . . . . . . 99 D.1. Changes Between Versions -02 and -03 . . . . . . . . . . 103
D.2. Changes Between Versions -00 and -01 . . . . . . . . . . 99 D.2. Changes Between Versions -01 and -02 . . . . . . . . . . 103
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 101 D.3. Changes Between Versions -00 and -01 . . . . . . . . . . 104
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 105
1. Introduction 1. Introduction
The NETCONF Working Group has completed a base protocol used for The NETCONF Working Group has completed a base protocol used for
configuration management [1]. This base specification defines configuration management [1]. 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
skipping to change at page 6, line 41 skipping to change at page 6, line 41
being standardized as ISO/IEC 19757 [6]. The DSDL framework being standardized as ISO/IEC 19757 [6]. The DSDL framework
comprises a set of XML schema languages that address grammar rules, comprises a set of XML schema languages that address grammar rules,
semantic constraints and other data modeling aspects but also, and semantic constraints and other data modeling aspects but also, and
more importantly, do it in a coordinated and consistent way. While more importantly, do it in a coordinated and consistent way. While
it is true that some DSDL parts have not been standardized yet and it is true that some DSDL parts have not been standardized yet and
are still work in progress, the three parts that the YANG-to-DSDL are still work in progress, the three parts that the YANG-to-DSDL
mapping relies upon - RELAX NG, Schematron and DSRL - already have mapping relies upon - RELAX NG, Schematron and DSRL - already have
the status of an ISO/IEC International Standard and are supported in the status of an ISO/IEC International Standard and are supported in
a number of software tools. a number of software tools.
This document contains the specification of a mapping that translates This document contains specification of a mapping that translates
YANG data models to XML schemas utilizing a subset of the DSDL schema YANG data models to XML schemas utilizing a subset of the DSDL schema
languages. The mapping procedure is divided into two steps: In the languages. The mapping procedure is divided into two steps: In the
first step, the structure of the data tree, RPC signatures and first step, the structure of the data tree, RPC signatures and
notifications is expressed as a single RELAX NG grammar with simple notifications is expressed as a single RELAX NG grammar with simple
annotations representing additional data model information (metadata, annotations representing additional data model information (metadata,
documentation, semantic constraints, default values etc.). The documentation, semantic constraints, default values etc.). The
second step then generates a coordinated set of DSDL schemas that can second step then generates a coordinated set of DSDL schemas that can
validate specific XML documents such as client requests, server validate specific XML documents such as client requests, server
responses or notifications, perhaps also taking into account responses or notifications, perhaps also taking into account
additional context such as active capabilities. additional context such as active capabilities.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [7]. document are to be interpreted as described in [7].
In the text, we also use the following typographic conventions: In the text, we also use the following typographic conventions:
o YANG statement keywords are delimited by single quotes. o YANG statement keywords are delimited by single quotes.
o Literal values are delimited by double quotes.
o XML element names are delimited by "<" and ">" characters. o XML element names are delimited by "<" and ">" characters.
o Names of XML attributes are prefixed by the "@" character. o Names of XML attributes are prefixed by the "@" character.
o Other literal values are delimited by double quotes.
XML elements names are always written with explicit namespace XML elements names are always written with explicit namespace
prefixes corresponding to the following XML vocabularies: prefixes corresponding to the following XML vocabularies:
"a" DTD compatibility annotations [8] "a" DTD compatibility annotations [8]
"dc" Dublin Core metadata elements [9] "dc" Dublin Core metadata elements [9]
"nc" NETCONF protocol [1] "nc" NETCONF protocol [1]
"en" NETCONF event notifications [10] "en" NETCONF event notifications [10]
skipping to change at page 9, line 32 skipping to change at page 9, line 32
availability of capabilities and features. YANG modules can also availability of capabilities and features. YANG modules can also
define new RPC methods. The mapping should be able to accommodate define new RPC methods. The mapping should be able to accommodate
this variability and generate schemas that are specifically tailored this variability and generate schemas that are specifically tailored
to a particular situation and thus considerably more efficient than to a particular situation and thus considerably more efficient than
generic all-encompassing schemas. generic all-encompassing schemas.
In order to cope with this variability, we assume that the schemas In order to cope with this variability, we assume that the schemas
can be generated on demand from the available collection of YANG can be generated on demand from the available collection of YANG
modules and their lifetime will be relatively short. In other words, modules and their lifetime will be relatively short. In other words,
we don't envision that any collection of DSDL schemas will be created we don't envision that any collection of DSDL schemas will be created
and maintained over extended periods of time in parallel to YANG and maintained over an extended period of time in parallel to YANG
modules. modules.
The generated schemas are primarily intended as input to the existing The generated schemas are primarily intended as input to the existing
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
schema of the so-called "conceptual tree", which contains schema of the so-called "conceptual tree", which contains
grammatical constraints for the main data tree as well as RPCs grammatical constraints for the main data tree as well as RPCs
and notifications. In order to record additional constraints and notifications. In order to record additional constraints
that appear in the YANG modules but cannot be expressed in RELAX that appear in the YANG modules but cannot be expressed in RELAX
NG, the schema is augmented by simple annotations. The resulting NG, the schema is augmented by simple annotations. The output of
schema should thus be considered a reasonably readable equivalent the first step can thus be considered a reasonably readable
of the input YANG modules. equivalent of the input YANG modules.
2. In the second step, the annotated RELAX NG schema from step 1 is 2. In the second step, the annotated RELAX NG schema from step 1 is
transformed further to a coordinated set of DSDL schemas transformed further to a coordinated set of fully conformant DSDL
containing constraints for a particular data object and a schemas containing constraints for a particular data object and a
specific situation. The DSDL schemas are intended mainly for specific situation. The DSDL schemas are intended mainly for
machine validation using off-the-shelf tools. machine validation using off-the-shelf tools.
3. DSDL Schema Languages 3. DSDL Schema Languages
Document Schema Definition Languages (DSDL) is a framework of schema
languages that is being developed as an international standard ISO/
IEC 19757. Unlike other approaches to XML document validation,
notably W3C XML Schema (XSD) [14], the DSDL framework adheres to the
principle of "small languages": Each of the DSDL constituents is a
stand-alone schema languages with a relatively narrow purpose and
focus. Together, these schema languages may be used in a coordinated
way to accomplish various validation tasks.
The mapping described in this document uses three of the DSDL schema The mapping described in this document uses three of the DSDL schema
languages, namely RELAX NG, Schematron and DSRL. languages, namely RELAX NG, Schematron and DSRL.
3.1. RELAX NG 3.1. RELAX NG
RELAX NG (pronounced "relaxing") is an XML schema language for RELAX NG (pronounced "relaxing") is an XML schema language for
grammar-based validation and Part 2 of the ISO/IEC DSDL family of grammar-based validation and Part 2 of the ISO/IEC DSDL family of
standards [12]. Like the W3C XML Schema language [14], it is able to standards [12]. Like the W3C XML Schema language [14], it is able to
describe constraints on the structure and contents of XML documents. describe constraints on the structure and content of XML documents.
However, unlike the DTD [15] and XSD schema languages, RELAX NG However, unlike the DTD [15] and XSD schema languages, RELAX NG
intentionally avoids any infoset augmentation such as defining intentionally avoids any infoset augmentation such as defining
default values. In the DSDL architecture, the particular task of default values. In the DSDL architecture, the particular task of
defining and applying default values is delegated to another schema defining and applying default values is delegated to another schema
language, DSRL (see Section 3.3). language, DSRL (see Section 3.3).
As its base datatype library, RELAX NG uses the W3C XML Schema As its base datatype library, RELAX NG uses the W3C XML Schema
Datatype Library [16], but unlike XSD, other datatype libraries may Datatype Library [16], but unlike XSD, other datatype libraries may
be used along with it or even replace it if necessary. be used along with it or even replace it if necessary.
RELAX NG is very liberal in accepting annotations from other RELAX NG is very liberal in accepting annotations from other
namespaces. With few exceptions, such annotations may be placed namespaces. With few exceptions, such annotations may be placed
anywhere in the schema and need no encapsulating element such as anywhere in the schema and need no encapsulating elements such as
<xsd:annotation> in XSD. <xsd:annotation> in XSD.
RELAX NG schema can be represented using two equivalent syntaxes: XML RELAX NG schemas can be represented n two equivalent syntaxes: XML
and compact. The compact syntax is described in Annex C of the RELAX and compact. The compact syntax is described in Annex C of the RELAX
NG specification [17], which was added to the standard in 2006 NG specification [17], 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 for example Trang [23]. syntaxes can be accomplished using several tools, for example
Trang [23].
For its terseness and readability, the compact syntax is often the For its terseness and readability, the compact syntax is often the
preferred form for publishing RELAX NG schemas whereas validators and preferred form for publishing RELAX NG schemas whereas validators and
other software tools generally require the XML syntax. However, the other software tools generally require the XML syntax. However, the
compact syntax has two drawbacks: compact syntax has two drawbacks:
o External annotations make the compact syntax schema considerably o External annotations make the compact syntax schema considerably
less readable. While in the XML syntax the annotating elements less readable. While in the XML syntax the annotating elements
and attributes are represented in a simple and uniform way (XML and attributes are represented in a simple and uniform way (XML
elements and attributes from foreign namespaces), the compact elements and attributes from foreign namespaces), the compact
syntax uses four different syntactic constructs: documentation, syntax uses four different syntactic constructs: documentation,
grammar, initial and following annotations. Therefore, the impact grammar, initial and following annotations. Therefore, the impact
on readability that results from adding annotations is often much of annotations on readability is often much stronger for the
stronger for the compact syntax than for the XML syntax. compact syntax than for the XML syntax.
o In a program, it is more difficult to generate compact syntax than o In a program, it is more difficult to generate compact syntax than
XML syntax. While a number of software libraries exist that make XML syntax. While a number of software libraries exist that make
it easy to create an XML tree in memory and serialize it, no such it easy to create an XML tree in memory and serialize it, no such
aid is available for compact syntax. aid is available for compact syntax.
For these reasons, the mapping specification in this document use For these reasons, the mapping specification in this document uses
exclusively the XML syntax. Where appropriate, though, the schemas exclusively the XML syntax. Where appropriate, though, the schemas
resulting from the translation may be presented in the equivalent resulting from the translation may be presented in the equivalent
compact syntax. compact syntax.
RELAX NG elements are qualified with the namespace URI RELAX NG elements are qualified with the namespace URI
"http://relaxng.org/ns/structure/1.0". The namespace of the W3C "http://relaxng.org/ns/structure/1.0". The namespace of the W3C
Schema Datatype Library is Schema Datatype Library is
"http://www.w3.org/2001/XMLSchema-datatypes". "http://www.w3.org/2001/XMLSchema-datatypes".
3.2. Schematron 3.2. Schematron
Schematron is Part 3 of DSDL that reached the status of a full ISO/ Schematron is Part 3 of DSDL that reached the status of a full ISO/
IEC standard in 2006 [13]. In contrast to the traditional schema IEC standard in 2006 [13]. In contrast to the traditional schema
languages such as DTD, XSD or RELAX NG, which are based on the languages such as DTD, XSD or RELAX NG, which are based on the
concept of a formal grammar, Schematron utilizes a rule-based concept of a formal grammar, Schematron utilizes a rule-based
approach. Its rules may specify arbitrary conditions involving data approach. Its rules may specify arbitrary conditions involving data
from different parts of an XML document. Each rule consists of three from different parts of an XML document. Each rule consists of three
essential parts: essential components:
o Context - an XPath expression that defines the set of locations o context - an XPath expression that defines the set of locations
where the rule is to be applied, where the rule is to be applied;
o Assert or report condition - another XPath expression that is o assert or report condition - another XPath expression that is
evaluated relative to the location matched by the context evaluated relative to the location matched by the context
expression. expression;
o Human-readable message that is displayed when the assert condition o human-readable message that is displayed when the assert condition
is false or report condition is true. is false or report condition is true.
The difference between the assert and report condition is that the The difference between the assert and report condition is that the
former is positive in that it states a condition that a valid former is positive in that it states a condition that a valid
document has to satisfy, whereas the latter specifies an error document has to satisfy, whereas the latter specifies an error
condition. condition.
Schematron draws most of its expressive power from XPath [18] and Schematron draws most of its expressive power from XPath [18] and
XSLT [19]. ISO Schematron allows for dynamic query language binding XSLT [19]. ISO Schematron allows for dynamic query language binding
so that the following XML query languages can be used: STX, XSLT 1.0, so that the following XML query languages can be used: STX, XSLT 1.0,
XSLT 1.1, EXSLT, XSLT 2.0, XPath 1.0, XPath 2.0 and XQuery 1.0 (this XSLT 1.1, EXSLT, XSLT 2.0, XPath 1.0, XPath 2.0 and XQuery 1.0 (this
list may be extended in future). list may be extended in future).
The human-readable error messages are another feature that The human-readable error messages are another feature that
distinguishes Schematron from other schema languages such as RELAX NG distinguishes Schematron from other common schema languages. The
or XSD. The messages may even contain XPath expressions that are messages may even contain XPath expressions that are evaluated in the
evaluated in the actual context and thus refer to existing XML actual context and thus refer to existing XML document nodes and
document nodes and their content. their content.
ISO Schematron introduced the concept of _abstract patterns_ whose
purpose is similar to functions in programming languages. The
mapping described in this document uses a library of abstract
patterns for specifying generic constraints such as uniqueness of
certain leaf values in list items.
The rules defined by a Schematron schema may be divided into several The rules defined by a Schematron schema may be divided into several
subsets known as _phases_. Validations may then be set up to include subsets known as _phases_. Validations may then be set up to include
only selected phases. In the context of NETCONF data validation, only selected phases. In the context of NETCONF data validation,
this is useful for relaxing constraints that may not always apply. this is useful for relaxing constraints that may not always apply.
For example, the reference integrity may not be enforced for a For example, the reference integrity may not be enforced for a
candidate configuration. candidate configuration.
Schematron elements are qualified with namespace URI Schematron elements are qualified with namespace URI
"http://purl.oclc.org/dsdl/schematron". "http://purl.oclc.org/dsdl/schematron".
3.3. Document Semantics Renaming Language (DSRL) 3.3. Document Semantics Renaming Language (DSRL)
DSRL (pronounced "disrule") is Part 8 of DSDL that reached the status DSRL (pronounced "disrule") is Part 8 of DSDL that reached the status
of a full ISO/IEC standard in 2008 [11]. Unlike RELAX NG and of a full ISO/IEC standard in 2008 [11]. 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. The primary application for DSRL is of the validated document. While DSRL is primarily intended for
renaming XML elements and attributes. DSRL can also define default renaming XML elements and attributes, it can also define default
values for XML attributes and elements so that elements or attributes values for XML attributes and default content for XML elements so
with these default values are inserted if they are missing in the that elements or attributes with these default values are inserted if
validated documents. The latter feature is used by the YANG-to-DSDL they are missing (or present and empty) in the validated documents.
mapping for representing YANG defaults for leaf nodes. The latter feature is used by the YANG-to-DSDL mapping for
representing YANG default values for leaf nodes.
DSRL elements are qualified with namespace URI DSRL elements are qualified with namespace URI
"http://purl.oclc.org/dsdl/dsrl". "http://purl.oclc.org/dsdl/dsrl".
4. Additional Annotations 4. Additional Annotations
In addition to the DSDL schema languages, the mapping uses three sets Besides the DSDL schema languages, the mapping also uses three sets
of annotations that are added as foreign-namespace elements and of annotations that are added as foreign-namespace attributes and
attributes 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. While these data model items may not be used for respectively. Although these data model items are not used for
formal validation, they quite often carry important information. formal validation, they quite often carry important information for
Therefore, they SHOULD be included in the conceptual tree schema and data model implementers. Therefore, they SHOULD be included in the
MAY also appear in the final validation schemas. conceptual tree schema and MAY also appear in the final validation
schemas.
The third set are NETMOD-specific annotations conveying semantic The third set are NETMOD-specific annotations conveying YANG semantic
constraints and other information that cannot be expressed natively constraints and other information that cannot be expressed natively
in RELAX NG. These annotations are only used in the first step of in RELAX NG. These annotations are only used in the first step of
the mapping, i.e., in the conceptual tree schema. In the second the mapping, i.e., in the conceptual tree schema. In the second
mapping step, these annotations are converted to Schematron and DSRL mapping step, these annotations are converted to Schematron and DSRL
rules. rules.
4.1. Dublin Core Metadata Elements 4.1. Dublin Core Metadata Elements
Dublin Core [24] is a system of metadata elements that was originally Dublin Core [24] is a system of metadata elements that was originally
created for describing metadata of World Wide Web resources in order created for describing metadata of World Wide Web resources in order
to facilitate their automated lookup. Later it was accepted as a to facilitate their automated lookup. Later it was accepted as a
standard for describing metadata of arbitrary resources. This standard for describing metadata of arbitrary resources. This
specification uses the definition found in [9]. specification uses the definition from [9].
Dublin Core elements are qualified with namespace URI Dublin Core elements are qualified with namespace URI
"http://purl.org/dc/terms". "http://purl.org/dc/terms".
4.2. RELAX NG DTD Compatibility Annotations 4.2. RELAX NG DTD Compatibility Annotations
DTD compatibility annotations are part of the RELAX NG DTD DTD compatibility annotations are part of the RELAX NG DTD
Compatibility specification [8]. The YANG-to-DSDL mapping uses only Compatibility specification [8]. YANG-to-DSDL mapping uses only the
the <a:documentation> annotation for representing YANG 'description' <a:documentation> annotation for representing YANG 'description' and
and 'reference' texts. 'reference' texts.
Note that there is no intention to make the resulting schemas DTD- Note that there is no intention to make the resulting schemas DTD-
compatible, the main reason for using these annotations is technical: compatible, the main reason for using these annotations is technical:
they are well supported and adequately interpreted by several RELAX they are well supported and adequately interpreted by several RELAX
NG tools. NG tools.
DTD compatibility annotations are qualified with namespace URI DTD compatibility annotations are qualified with namespace URI
"http://relaxng.org/ns/compatibility/annotations/1.0". "http://relaxng.org/ns/compatibility/annotations/1.0".
4.3. NETMOD-specific Annotations 4.3. NETMOD-Specific Annotations
NETMOD-specific annotations are XML elements and attributes qualified NETMOD-specific annotations are XML elements and attributes qualified
with the namespace URI with the namespace URI
"urn:ietf:params:xml:ns:netmod:dsdl-annotations:1" that appear in "urn:ietf:params:xml:ns:netmod:dsdl-annotations:1" that appear in
various locations in the conceptual tree schema. YANG statements are various locations in the conceptual tree schema. YANG statements are
mapped to these annotations in a very straightforward way. With one mapped to these annotations in a very straightforward way. In most
exception - @nma:default-case - the annotation attributes and cases, the annotation attributes and elements always have the same
elements always have the same name as the corresponding YANG name as the corresponding YANG statement.
statement.
Table 2 lists alphabetically the names of NETMOD-specific annotation Table 2 lists alphabetically the names of NETMOD-specific annotation
elements (in angle brackets) and attributes (prefixed with "@") along attributes (prefixed with "@") and elements (in angle brackets) along
with a reference to the section where their use is described. with a reference to the section where their use is described.
Appendix A then contains the RELAX NG schema of this annotation Appendix A then contains the RELAX NG schema of this annotation
vocabulary. vocabulary.
+---------------------------+---------+------+ +---------------------------+--------------------+------+
| annotation | section | note | | annotation | section | note |
+---------------------------+---------+------+ +---------------------------+--------------------+------+
| @nma:config | 10.9 | | | @nma:config | 10.9 | |
| | | | | | | |
| @nma:default | 10.12 | | | @nma:default | 10.12 | |
| | | | | | | |
| @nma:default-case | 10.7 | | | @nma:implicit | 10.11, 10.7, 10.12 | |
| | | | | | | |
| <nma:error-app-tag> | 10.16 | 1 | | <nma:error-app-tag> | 10.16 | 1 |
| | | | | | | |
| <nma:error-message> | 10.17 | 1 | | <nma:error-message> | 10.17 | 1 |
| | | | | | | |
| <nma:instance-identifier> | 10.53.6 | 2 | | <nma:instance-identifier> | 10.53.6 | 2 |
| | | | | | | |
| @nma:key | 10.26 | | | @nma:key | 10.26 | |
| | | | | | | |
| <nma:leafref> | 10.53.7 | 2 | | @nma:leafref | 10.53.7 | |
| | | | | | | |
| @nma:min-elements | 10.28 | | | @nma:min-elements | 10.28 | |
| | | | | | | |
| @nma:max-elements | 10.28 | | | @nma:max-elements | 10.28 | |
| | | | | | | |
| <nma:must> | 10.35 | 3 | | <nma:must> | 10.35 | 3 |
| | | | | | | |
| @nma:ordered-by | 10.38 | | | @nma:ordered-by | 10.38 | |
| | | | | | | |
| @nma:presence | 10.45 | | | @nma:presence | 10.45 | |
| | | | | | | |
| @nma:status | 10.51 | | | @nma:status | 10.51 | |
| | | | | | | |
| @nma:unique | 10.55 | | | @nma:unique | 10.55 | |
| | | | | | | |
| @nma:units | 10.56 | | | @nma:units | 10.56 | |
| | | | | | | |
| @nma:when | 10.59 | | | @nma:when | 10.59 | |
+---------------------------+---------+------+ +---------------------------+--------------------+------+
Table 2: NETMOD-specific annotations Table 2: NETMOD-specific annotations
Notes: Notes:
1. Appears only as subelement of <nma:must>. 1. Appears only as subelement of <nma:must>.
2. Has an optional attribute @require-instance. 2. Has an optional attribute @require-instance.
3. Has a mandatory attribute @assert and two optional subelements 3. Has a mandatory attribute @assert and two optional subelements
skipping to change at page 17, line 45 skipping to change at page 17, line 45
RELAX NG (list key definitions, 'must' statements etc.) and RELAX NG (list key definitions, 'must' statements etc.) and
various documentation texts are recorded in the schema as simple various documentation texts are recorded in the schema as simple
annotations belonging to special namespaces. annotations belonging to special namespaces.
2. In the second step, the conceptual tree schema is transformed in 2. In the second step, the conceptual tree schema is transformed in
multiple ways to a coordinated set of DSDL schemas that can be multiple ways to a coordinated set of DSDL schemas that can be
used for validating a particular data object in a specific used for validating a particular data object in a specific
context. Figure 1 shows just three simplest possibilities as context. Figure 1 shows just three simplest 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
default-content> elements etc. element maps etc.
3. As indicated in Figure 1, the second step of the mapping also 3. As indicated in Figure 1, the second step of the mapping also
uses a schema-independent library that contains common schema uses a schema-independent library that contains common schema
objects such as RELAX NG named pattern definitions. objects such as RELAX NG named pattern definitions.
An implementation of the mapping algorithm accepts one or more valid An implementation of the mapping algorithm accepts one or more valid
YANG modules as its input. It is important to be able to process YANG modules as its input. It is important to be able to process
multiple YANG modules together since multiple modules may be multiple YANG modules together since multiple modules may be
negotiated for a NETCONF session and the contents of the negotiated for a NETCONF session and the contents of the
configuration datastore is then obtained as the union of data trees configuration datastore is then obtained as the union of data trees
specified by the individual modules, which may also lead to multiple specified by the individual modules, which may also lead to multiple
roots. In addition, the input modules may be further coupled by the roots. In addition, the input modules may be further coupled by the
'augment' statement in which one module augments the data tree of 'augment' statement in which one module augments the data tree of
another module. another module.
It is also assumed that the algorithm has access, perhaps on demand, It is also assumed that the algorithm has access, perhaps on demand,
to all YANG modules that the module(s) imports (transitively). to all YANG modules that the module(s) imports (transitively).
The output of the first mapping step is an annotated RELAX NG schema The output of the first mapping step is an annotated RELAX NG schema
for the conceptual tree, which represents a virtual XML document for the conceptual tree - a virtual XML document containing, in its
containing, in its different subtrees, the entire datastore, all RPC different subtrees, the entire datastore, all RPC requests and
requests and replies, and notifications defined by the input YANG replies, and notifications defined by the input YANG modules. By
modules. By "virtual" we mean that such an XML document need not "virtual" we mean that such an XML document need not correspond to
correspond to the actual layout of the configuration database in a the actual layout of the configuration database in a NETCONF agent,
NETCONF agent, and will certainly never appear on the wire as the and will certainly never appear on the wire as the content of a
content of a NETCONF PDU. Hence, the RELAX NG schema for the NETCONF PDU. Hence, the RELAX NG schema for the conceptual tree is
conceptual tree is not intended for any direct validations but rather not intended for any direct validations but rather as a
as a representation of a particular data model expressed in RELAX NG representation of a particular data model expressed in RELAX NG and
and the common starting point for subsequent transformations that the common starting point for subsequent transformations that may
will typically produce validation schemas. The conceptual tree is produce practical validation schemas. The conceptual tree is further
further described in Section 7.1. described in Section 7.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 as annotations - XML constraints or default values, are recorded in the conceptual tree
elements or attributes qualified with namespace URI schema as annotations - XML attributes or elements qualified with
"urn:ietf:params:xml:ns:netmod:dsdl-annotations:1". Metadata namespace URI "urn:ietf:params:xml:ns:netmod:dsdl-annotations:1".
describing the YANG modules are mapped to annotations utilizing Metadata describing the YANG modules are mapped to annotations
Dublin Core elements (Section 4.1). Finally, documentation strings utilizing Dublin Core elements (Section 4.1). Finally, documentation
are mapped to the <a:documentation> elements belonging to the DTD strings are mapped to the <a:documentation> elements belonging to the
compatibility vocabulary (Section 4.2). DTD compatibility vocabulary (Section 4.2).
The output from the second step is 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 values. o DSRL schema containing a specification of default content.
6. NETCONF Content Validation 6. 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 corresponding to various NETCONF PDUs. documents such as the content of a datastore or various NETCONF PDUs.
The validation proceeds in the following steps, which are also The validation proceeds in the following steps, which are also
illustrated in Figure 2: illustrated in Figure 2:
1. The XML instance document can be immediately checked for 1. The XML instance document can be immediately checked for
grammatical and data type validity using the RELAX NG schema. grammatical and data type validity using the RELAX NG schema.
2. Second, the default values for leaves have to be applied and 2. Second, the default values for leaves have to be applied and
their ancestor containers added where necessary. It is important their ancestor containers added where necessary. It is important
to apply the defaults before the next validation step because to apply the defaults before the next validation step because
skipping to change at page 19, line 45 skipping to change at page 20, line 5
| grammar, | defaults | semantic | grammar, | defaults | semantic
| datatypes | | constraints | datatypes | | constraints
| | | | | |
+----------+ +--------+ +------------+ +----------+ +--------+ +------------+
| RELAX NG | | DSRL | | Schematron | | RELAX NG | | DSRL | | Schematron |
| schema | | schema | | schema | | schema | | schema | | schema |
+----------+ +--------+ +------------+ +----------+ +--------+ +------------+
Figure 2: Outline of the validation procedure Figure 2: Outline of the validation procedure
The process of substituting default values is complicated by the
rules for non-presence containers and choices in YANG, which may lead
to insertion of entire subtrees in the NETCONF instance document.
Section 9.4 describes how this procedure is represented in DSRL and
how the DSRL schema is obtained from the conceptual tree schema.
7. Design Considerations 7. Design Considerations
YANG modules could be mapped to DSDL schemas in a number of ways. YANG modules could be mapped to DSDL schemas in a number of ways.
The mapping procedure described in this document uses several The mapping procedure described in this document uses several
specific design decisions that are discussed in the following specific design decisions that are discussed in the following
subsections. subsections.
7.1. Conceptual Data Tree 7.1. Conceptual Data Tree
DSDL schemas generated from YANG modules using the procedure DSDL schemas generated from YANG modules using the procedure
described in this document are intended to be used for validating described in this document are intended to be used for validating
XML-encoded NETCONF data in various forms (full datastore and several XML-encoded NETCONF data in various forms: every YANG-based model
types of PDUs): every YANG-based model represents the contents of a represents the contents of a datastore but also implies an array of
full datastore but also implies an array of schemas for all types of schemas for all types of NETCONF PDUs. For a reasonably strict
NETCONF PDUs. For a reasonably strict validation of a given data validation of a given data object, the schemas have to be quite
object, the schemas have to be quite specific. To begin with, specific. To begin with, effective validation of NETCONF PDU content
effective validation of NETCONF PDU content requires separation of requires separation of client and server schemas. While the decision
client and server schemas. While the decision about proper about proper structuring of all PDU-validating schemas is beyond the
structuring of all PDU-validating schemas is beyond the scope of this scope of this document, the mapping procedure is designed to
document, the mapping procedure is designed to accommodate any accommodate any foreseeable validation needs.
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 approaches: the grammar and
datatype specifications for the datastore, RPCs and notifications datatype specifications for the datastore, RPCs and notifications
expressed by one or more YANG modules have to be translated to RELAX expressed by one or more YANG modules have to be translated to RELAX
NG. In order to be able to separate this common step, we introduce NG. In order to be able to separate this common step, we introduce
the notion of _conceptual data tree_: it is a virtual XML tree that the notion of _conceptual data tree_: it is a virtual XML tree that
contains full datastore, RPC requests with corresponding replies and contains full datastore, RPC requests with corresponding replies and
notifications. The schema for the conceptual tree - a single RELAX notifications. The schema for the conceptual tree - a single RELAX
NG schema with annotations - therefore has a quite similar logic as NG schema with annotations - therefore has a quite similar logic as
the input YANG module(s), the only major difference being the RELAX the input YANG module(s), the only major difference being the RELAX
NG schema language. NG schema language.
The conceptual data tree for a YANG module defining nodes in the For example, the conceptual data tree for a YANG module defining
namespace "http://example.com/ns/example" may be schematically nodes in the namespace "http://example.com/ns/example" may be
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 ...
</nmt:top> </nmt:top>
<nmt:rpc-methods> <nmt:rpc-methods>
<nmt:rpc-method> <nmt:rpc-method>
<nmt:input> <nmt:input>
<ex:myrpc ...> <ex:myrpc ...>
... ...
</myrpc> </myrpc>
</nmt:input> </nmt:input>
<nmt:output> <nmt:output>
... ...
</nmt:output> </nmt:output>
</nmt:rpc-method> </nmt:rpc-method>
... ...
</nmt:rpcs> </nmt:rpc-methods>
<nmt:notifications> <nmt:notifications>
<nmt:notification> <nmt:notification>
<ex:mynotif> <ex:mynotif>
... ...
</mynotif> </mynotif>
</nmt:notification> </nmt:notification>
... ...
</nmt:notifications> </nmt:notifications>
</nmt:netmod> </nmt:netmod>
skipping to change at page 22, line 7 skipping to change at page 22, line 7
Additional information contained in the source YANG module(s), such Additional information contained in the source YANG module(s), such
as semantic constraints and default values, is represented in the as semantic constraints and default values, is represented in the
form of interim NETMOD-specific annotations that are included as form of interim NETMOD-specific annotations that are included as
foreign-namespace elements or attributes in the RELAX NG schema for foreign-namespace elements or attributes in the RELAX NG schema for
the conceptual tree. In the second phase of the mapping, these the conceptual tree. In the second phase of the mapping, these
annotations are translated to equivalent Schematron and DSRL rules. annotations are translated to equivalent Schematron and DSRL rules.
As a useful side effect, by introducing the conceptual data tree we As a useful side effect, by introducing the conceptual data tree we
are also able to resolve the difficulties arising from the fact that are also able to resolve the difficulties arising from the fact that
a single configuration repository may consist of multiple parallel a single datastore may consist of multiple parallel data hierarchies
data hierarchies defined in one or more YANG modules, which cannot be defined in one or more YANG modules, which cannot be mapped to a
mapped to a valid XML document. In the conceptual data tree, such valid XML document. In the conceptual data tree, such multiple
multiple hierarchies appear under the single <nmt:top> element. hierarchies appear under the single <nmt:top> element.
7.2. Modularity 7.2. Modularity
Both YANG and RELAX NG offer means for modularity, i.e., for Both YANG and RELAX NG offer means for modularity, i.e., for
splitting the contents into separate modules (schemas) and combining splitting the contents of a full schema into separate modules and
or reusing them in various ways. However, the approaches taken by combining or reusing them in various ways. However, the approaches
YANG and RELAX NG differ. Modularity in RELAX NG is suitable for ad taken by YANG and RELAX NG differ. Modularity in RELAX NG is
hoc combinations of a small number of schemas whereas YANG assumes a suitable for ad hoc combinations of a small number of schemas whereas
large set of modules similar to SNMP MIBs. The following differences YANG assumes a large set of modules similar to SNMP MIBs. The
are important: following differences are important:
o In YANG, whenever module A imports module B, it gets access to the o In YANG, whenever module A imports module B, it gets access to the
definitions (groupings and typedefs) appearing at the top level of definitions (groupings and typedefs) appearing at the top level of
module B. However, no part of module B's data tree is imported module B. However, no part of data tree from module B is imported
along with it. In contrast, the <rng:include> pattern in RELAX NG along with it. In contrast, the <rng:include> pattern in RELAX NG
imports both definitions of named patterns and the entire schema imports both definitions of named patterns and the entire schema
tree from the included schema. tree from the included schema.
o The names of imported YANG groupings and typedefs are qualified o The names of imported YANG groupings and typedefs are qualified
with the namespace of the imported module. On the other hand, the with the namespace of the imported module. On the other hand, the
data nodes contained inside the imported groupings, when used names of data nodes contained inside the imported groupings, when
within the importing module, become part of the importing used within the importing module, become part of the importing
namespace. In RELAX NG, the names of patterns are unqualified and namespace. In RELAX NG, the names of patterns are unqualified and
so named patterns defined in both the importing and imported so named patterns defined in both the importing and imported
module share the same flat namespace. The contents of RELAX NG module share the same flat namespace. The contents of RELAX NG
named patterns may either keep the namespace of the schema where named patterns may either keep the namespace of the schema where
they are defined or inherit the namespace of the importing module, they are defined or inherit the namespace of the importing module,
analogically to YANG. However, in order to achieve the latter analogically to YANG. However, in order to achieve the latter
behavior, the imported module must be prepared in a special way as behavior, the imported module must be prepared in a special way as
a library module that cannot be used as a stand-alone schema. a library module that cannot be used as a stand-alone schema.
So the conclusion is that the modularity mechanisms of YANG and RELAX So the conclusion is that the modularity mechanisms of YANG and RELAX
skipping to change at page 23, line 43 skipping to change at page 23, line 43
of RELAX NG. For this reason, the mapping essentially keeps the of RELAX NG. For this reason, the mapping essentially keeps the
granularity of the original YANG data model: definitions of named granularity of the original YANG data model: definitions of named
patterns in the resulting RELAX NG schema usually have direct patterns in the resulting RELAX NG schema usually have direct
counterparts in YANG groupings and definitions of derived types. counterparts in YANG groupings and definitions of derived types.
7.4. Handling of XML Namespaces 7.4. Handling of XML Namespaces
Most modern XML schema languages including RELAX NG, Schematron and Most modern XML schema languages including RELAX NG, Schematron and
DSRL support schemas for so-called compound XML documents, which DSRL support schemas for so-called compound XML documents, which
contain elements from multiple namespaces. This is useful for our contain elements from multiple namespaces. This is useful for our
purpose since the YANG-to-DSDL mapping algorithm allows for multiple purpose since the YANG-to-DSDL mapping allows for multiple input YANG
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.
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 all YANG modules are represented symmetrically, alternative 1, since in this case all YANG modules are represented
which makes further processing of the conceptual tree schema symmetrically, which makes further processing of the conceptual tree
considerably easier. Moreover, this way the namespace prefixes schema considerably easier. Moreover, this way the namespace
declared in all input modules are recorded in the resulting schema - prefixes declared in the input modules are recorded in the resulting
the prefix for the namespace declared using @ns would be lost. schema - the prefix for the namespace declared using @ns would be
lost.
Analogically, DSRL schemas may declare the default target namespace DSRL schemas can declare any number of target namespaces via the
using the @targetNamespace attribute and any number of additional standard XML attributes xmlns:xxx.
target namespaces via the standard XML attributes xmlns:xxx.
In contrast, Schematron requires all the target namespaces to be In contrast, Schematron requires all the target namespaces to be
defined in the <sch:ns> subelements of the root <sch:schema> element. defined in the <sch:ns> subelements of the root <sch:schema> element.
7.5. Features and Deviations
YANG provides statements that allow for marking parts of the schema
as conditional ('feature' and 'if-feature' statements) or declaring
deviations from a data model ('deviation' statement). These
statements are not handled by the YANG-to-DSDL mapping. It is
assumed that all features and deviations are specified beforehand and
the corresponding changes in the input YANG modules are already
applied.
8. Mapping YANG Data Models to the Conceptual Tree Schema 8. Mapping YANG Data Models to the Conceptual Tree Schema
This section explains the main principles underlying the first step This section explains the main principles underlying the first step
of the mapping. Its result is an annotated RELAX NG schema of the of the mapping. Its result is an annotated RELAX NG schema of the
conceptual tree, which is described in Section 7.1. conceptual tree, which is described in Section 7.1.
As a special case, if the input YANG modules contain no data nodes As a special case, if the input YANG modules contain no data nodes
(this is typical e.g., for datatype library modules), an (this is typical, e.g., for datatype library modules), an
implementation MAY entirely remove the schema of the (empty) implementation MAY entirely remove the schema of the (empty)
conceptual tree - the <rng:start> element with all its contents. The conceptual tree - the <rng:start> element with all its contents. The
output RELAX NG schema will then contain only named pattern output RELAX NG schema will then contain only named pattern
definitions translated from YANG groupings and typedefs. definitions translated from YANG groupings and typedefs.
Detailed specification of the mapping of individual YANG statements Detailed specification of the mapping of individual YANG statements
is contained in Section 10. is contained in Section 10.
8.1. Optional and Mandatory Content 8.1. Occurrence Rules for Data Nodes
In YANG, the decision whether a given data node is mandatory or In DSDL schema languages, occurrence constraints for a node are
optional is driven by the following rules, see Section 3.1 in [5]: always localized together with that node. In RELAX NG, for example,
<rng:optional> pattern always appears as the parent element of the
pattern defining the node in the schema. Similarly, DSRL specifies
default content separately for every single node, be it a leaf or
non-leaf element.
Leaf and choice nodes are mandatory if they contain the substatement In contrast, for a YANG container it is often necessary to examine
the entire subtree under that container in order to determine the
container's occurrence constraints.
Therefore, one of the goals of the first mapping step is to infer the
occurrence constraints for all containers and mark accordingly the
corresponding <rng:element> patterns in the conceptual tree schema so
that all transformation procedures in the second mapping step can
simply use this information and need not examine the subtree again.
The following two occurrence characteristics have to be determined
for every container:
1. optional/mandatory - mandatory containers must exist in a valid
instance document while optional ones may be omitted;
2. implicit - an implicit container is added to the instance
document in the process of substituting defaults for missing leaf
values.
Both characteristics apply to containers at the top level of the data
tree, and then also to other containers under the additional
condition that their parent node exists in the instance document.
For example, consider the following YANG fragment:
container outer {
presence 'Presence of "outer" means something.';
container c1 {
leaf foo {
type uint8;
default 1;
}
}
container c2 {
leaf-list bar {
type uint8;
min-elements 0;
}
}
container c3 {
leaf baz {
type uint8;
mandatory true; mandatory true;
}
}
}
For a choice node this means that at least one node from exactly one Here, container "outer" has the 'presence' substatement, which means
case branch must exist. that it is optional and not implicit. If "outer" is not present in a
configuration, its child containers are not present as well.
However, if "outer" does exist, it makes sense to ask which of its
child containers are optional and which are implicit. In this case,
"c1" is optional and implicit, "c2" is optional but not implicit and
"c3" is mandatory (and therefore not implicit).
In addition, leaf nodes are mandatory if they are declared as list The following subsections give precise rules for determining whether
a container is optional or mandatory and whether it is implicit. In
order to simplify their description, it is useful to define these
occurrence characteristics for other types of nodes - leaf, list,
leaf-list and anyxml.
8.1.1. Optional and Mandatory Nodes
The decision whether a given node is mandatory or optional is
governed by the following rules, see Section 3.1 in [5]:
o Leaf, anyxml and choice nodes are mandatory if they contain the
substatement "mandatory true;". For a choice node this means that
at least one node from exactly one case branch must exist.
o In addition, leaf nodes are mandatory if they are declared as list
keys. keys.
Lists or leaf-lists are mandatory if they contain 'min-elements' o List or leaf-list nodes are mandatory if they contain 'min-
substatement with argument value greater than zero. elements' substatement with argument value greater than zero.
A slightly more complicated situation arises for YANG containers. o A container node is mandatory if its definition does not contain
First, containers with the 'presence' substatement are always the 'presence' substatement and at least one of its child nodes is
optional since their presence or absence carries specific mandatory.
information. On the other hand, non-presence containers may be
omitted if they are empty. This leads to the following recursive
rule:
A container node is optional if its definition contains the A node is optional if it is not mandatory.
'presence' substatement or none of its child nodes is mandatory.
In RELAX NG, all elements that are optional must be explicitly In RELAX NG, definitions of nodes that are optional must be
wrapped in the <rng:optional> element. The mapping algorithm thus explicitly wrapped in the <rng:optional> element. The mapping
uses the above rules to determine whether a YANG node is optional and algorithm thus uses the above rules to determine whether a YANG node
if so, insert the <rng:optional> element in the RELAX NG schema. is optional and if so, inserts the <rng:optional> element in the
conceptual tree schema.
However, alternatives in <rng:choice> are never defined as optional
in the conceptual tree schema. Therefore, 'anyxml', 'container',
'leaf', 'list' and 'leaf-list' statements appearing as children of
'choice' (shorthand cases) are always mapped to mandatory RELAX NG
patterns. If a choice in YANG is not mandatory, <rng:optional> is
used to wrap the entire <rng:choice> pattern.
8.1.2. Implicit Nodes
The following rules are used to determine whether a given node is
implicit:
o List, leaf-list and anyxml nodes are never implicit.
o A leaf node is implicit if and only if it has a specified default
value (either directly or via its datatype).
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
least one child is implicit.
o As an exception to the above two rules, a leaf or container node
appearing inside a case of a choice can be implicit only if that
case is declared as default by using the 'default' statement, see
Section 7.9.3 in [5].
In the conceptual tree schema, all implicit containers MUST be marked
with @nma:implicit attribute with the value "true". In addition, the
default case in a choice (if defined by the 'default' substatement of
'choice') MUST be also marked in the same way, i.e., by @nma:implicit
set to "true".
8.2. Mapping YANG Groupings and Typedefs 8.2. Mapping YANG Groupings and Typedefs
YANG groupings and typedefs are generally mapped to RELAX NG named YANG groupings and typedefs are generally mapped to RELAX NG named
patterns. There are, however, several caveats that the mapping has patterns. There are, however, several caveats that the mapping has
to take into account. to take into account.
First of all, YANG typedefs and groupings may appear at all levels of First of all, YANG typedefs and groupings may appear at all levels of
the module hierarchy and are subject to lexical scoping, see Section the module hierarchy and are subject to lexical scoping, see Section
5.5 in [5]. Moreover, top-level symbols from external modules are 5.5 in [5]. Moreover, top-level symbols from external modules are
skipping to change at page 26, line 25 skipping to change at page 28, line 26
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:
o Names of groupings and typedefs appearing at the _top level_ of o Names of groupings and typedefs appearing at the top level of the
the YANG module hierarchy are prefixed with the module name and YANG module hierarchy are prefixed with the module name and two
two underscore characters ("__"). underscore characters ("__").
o Names of other groupings and typedefs, i.e., those that do not o Names of other groupings and typedefs, i.e., those that do not
appear at the top level of a YANG module, are prefixed with the appear at the top level of a YANG module, are prefixed with the
module name, double underscore, and then the names of all ancestor module name, double underscore, and then the names of all ancestor
data nodes separated by double underscore. data nodes separated by double underscore.
o Since the names of groupings and typedefs in YANG have different o Since the names of groupings and typedefs in YANG have different
namespaces, an additional underline character is added to the namespaces, an additional underline character is added to the
front of the mangled names of all groupings. beginning of the mangled names of all groupings.
For example, consider the following YANG module which imports the For example, consider the following YANG module which imports the
standard module "inet-types" [20]: standard module "inet-types" [20]:
module example1 { module example1 {
namespace "http://example.com/ns/example1"; namespace "http://example.com/ns/example1";
prefix ex1; prefix ex1;
import "inet-types" { import "inet-types" {
prefix "inet"; prefix "inet";
} }
skipping to change at page 28, line 13 skipping to change at page 30, line 13
IPv6 addresses are not shown): IPv6 addresses are not shown):
<rng:define name="example1__vowels"> <rng:define name="example1__vowels">
<rng:data type="string"> <rng:data type="string">
<rng:param name="pattern">[aeiouy]*</param> <rng:param name="pattern">[aeiouy]*</param>
</rng:data> </rng:data>
</rng:define> </rng:define>
<rng:define name="_example1__grp1"> <rng:define name="_example1__grp1">
<rng:optional> <rng:optional>
<rng:element name="t:void"> <rng:element name="ex1:void">
<rng:empty/> <rng:empty/>
</rng:element> </rng:element>
</rng:optional> </rng:optional>
</rng:define> </rng:define>
<rng:define name="_example1__cont__grp2"> <rng:define name="_example1__cont__grp2">
<rng:optional> <rng:optional>
<rng:element name="t:address"> <rng:element name="ex1:address">
<rng:ref name="inet-types__ip-address"/> <rng:ref name="inet-types__ip-address"/>
</rng:element> </rng:element>
</rng:optional> </rng:optional>
</rng:define> </rng:define>
<rng:define name="inet-types__ip-address"> <rng:define name="inet-types__ip-address">
<rng:choice> <rng:choice>
<rng:ref name="inet-types__ipv4-address"/> <rng:ref name="inet-types__ipv4-address"/>
<rng:ref name="inet-types__ipv6-address"/> <rng:ref name="inet-types__ipv6-address"/>
</rng:choice> </rng:choice>
skipping to change at page 29, line 14 skipping to change at page 31, line 14
statements for this purpose that may appear as substatements of statements for this purpose that may appear as substatements of
'uses': 'uses':
o 'refine' statement allows for changing parameters of a schema node o 'refine' statement allows for changing parameters of a schema node
inside the grouping referenced by the parent 'uses' statement; inside the grouping referenced by the parent 'uses' statement;
o 'augment' statement can be used for adding new schema nodes to the o 'augment' statement can be used for adding new schema nodes to the
grouping content. grouping content.
Both 'refine' and 'augment' statements are quite powerful in that Both 'refine' and 'augment' statements are quite powerful in that
they can address, using a subset of XPath 1.0 expressions as they can address, using XPath-like expressions as arguments, schema
arguments, schema nodes that are arbitrarily deep inside the grouping nodes that are arbitrarily deep inside the grouping content. In
content. In contrast, definitions of named patterns in RELAX NG contrast, definitions of named patterns in RELAX NG operate
operate exclusively at the topmost level of the named pattern exclusively at the topmost level of the named pattern content. In
content. In order to achieve a modifiability of named patterns order to achieve a modifiability of named patterns comparable to
comparable to YANG, the RELAX NG schema would have to be extremely YANG, the RELAX NG schema would have to be extremely flat (cf.
flat (cf. Section 7.3) and very difficult to read. Section 7.3) and very difficult to read.
Since the goal of the mapping described in this document is to Since the goal of the mapping described in this document is to
generate ad hoc DSDL schemas, we decided to avoid these complications generate ad hoc DSDL schemas, we decided to avoid these complications
and instead expand the grouping and refine and/or augment it "in and instead expand the grouping and refine and/or augment it "in
place". In other words, every 'uses' statement which has 'refine' place". In other words, every 'uses' statement which has 'refine'
and/or 'augment' substatements is virtually replaced by the content and/or 'augment' substatements is virtually replaced by the content
of the corresponding grouping, the changes specified in the 'refine' of the corresponding grouping, the changes specified in the 'refine'
and 'augment' statements are applied and the resulting YANG schema and 'augment' statements are applied and the resulting YANG schema
fragment is mapped as if the 'uses'/'grouping' indirection wasn't fragment is mapped as if the 'uses'/'grouping' indirection wasn't
there. there.
skipping to change at page 30, line 35 skipping to change at page 32, line 35
The resulting conceptual tree schema contains three named pattern The resulting conceptual tree schema contains three named pattern
definitions corresponding to the three groupings, namely definitions corresponding to the three groupings, namely
<rng:define name="_example2__leaves"> <rng:define name="_example2__leaves">
<rng:ref name="_example2__fr"/> <rng:ref name="_example2__fr"/>
<rng:ref name="_example2__es"/> <rng:ref name="_example2__es"/>
</rng:define> </rng:define>
<rng:define name="_example2__fr"> <rng:define name="_example2__fr">
<rng:optional> <rng:optional>
<rng:element name="feuille"> <rng:element name="ex2:feuille">
<rng:data type="string"/> <rng:data type="string"/>
</rng:element> </rng:element>
</rng:optional> </rng:optional>
</rng:define> </rng:define>
<rng:define name="_example2__es"> <rng:define name="_example2__es">
<rng:optional> <rng:optional>
<rng:element name="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 is refined:
skipping to change at page 31, line 21 skipping to change at page 33, line 21
The resulting conceptual tree schema now contains just one named The resulting conceptual tree schema now contains just one named
pattern definition - "_example__fr". The other two groupings pattern definition - "_example__fr". The other two groupings
"leaves" and "es" have to be expanded because they both lie on the "leaves" and "es" have to be expanded because they both lie on the
"modification path", i.e., contain the leaf "hoja" that is being "modification path", i.e., contain the leaf "hoja" that is being
refined. The configuration data part of the conceptual tree now refined. The configuration data part of the conceptual tree now
looks like this: looks like this:
<rng:ref name="_example2__fr"/> <rng:ref name="_example2__fr"/>
<rng:optional> <rng:optional>
<rng:element name="hoja" nma:default="alamo"> <rng:element name="ex2:hoja" nma:default="alamo">
<rng:data type="string"/> <rng:data type="string"/>
</rng:element> </rng:element>
</rng:optional> </rng:optional>
8.2.2. Type derivation chains 8.2.2. Type derivation chains
RELAX NG has no equivalent of the type derivation mechanism in YANG, RELAX NG has no equivalent of the type derivation mechanism in YANG,
where a base built-in type may be modified (in multiple steps) by where a base built-in type may be modified (in multiple steps) by
adding new restrictions. Therefore, when mapping YANG derived types adding new restrictions. Therefore, when mapping YANG derived types
with restrictions, the derived types MUST be "unwound" all the way with restrictions, the derived types MUST be "unwound" all the way
skipping to change at page 32, line 39 skipping to change at page 34, line 39
leaf month { leaf month {
type dozen { type dozen {
range 7..max; range 7..max;
} }
} }
The output RELAX NG schema then won't contain any named pattern The output RELAX NG schema then won't contain any named pattern
definition and leaf "month" will be mapped directly to definition and leaf "month" will be mapped directly to
<rng:element name="month"> <rng:element name="ex3:month">
<rng:data type="unsignedByte"> <rng:data type="unsignedByte">
<rng:param name="minInclusive">7</param> <rng:param name="minInclusive">7</param>
<rng:param name="maxInclusive">12</param> <rng:param name="maxInclusive">12</param>
</rng:data> </rng:data>
</rng:element> </rng:element>
8.3. Translation of XPath Expressions 8.3. Translation of XPath Expressions
YANG uses full XPath 1.0 syntax [18] for the arguments of 'must' and YANG uses full XPath 1.0 syntax [18] for the arguments of 'must',
'when' statements and a subset thereof in several other statements. 'when' and 'path' statements. However, since the names of data nodes
However, since the name of a data node always belongs to the defined in a YANG module always belong to the namespace of that YANG
namespace of the YANG Module where the data node is defined, YANG module, YANG adopted a simplification similar to the concept of
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, in which case the 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 first mapping step, it MUST be translated into a annotation in the conceptual tree schema, it MUST be translated into
fully conformant XPath 1.0 expression that also reflects the a fully conformant XPath 1.0 expression that also reflects the
hierarchy of the conceptual data tree: hierarchy of the conceptual data tree:
1. Each unprefixed node name MUST be prepended with the local 1. Each unprefixed node name MUST be prepended with the local
module's namespace prefix declared by the 'prefix' statement. module's namespace prefix declared by the 'prefix' statement.
2. Absolute XPath expressions, i.e., those starting with a slash, 2. Absolute XPath expressions, i.e., those starting with a slash,
MUST be prepended with appropriate path in the conceptual tree, MUST be prepended with appropriate path in the conceptual tree,
according to the YANG specification of context for XPath according to the YANG specification of context for XPath
expressions, see [5], sections 7.5.3 and 7.19.5. expressions, see [5], sections 7.5.3 and 7.19.5 in [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".
[Editor's note: We may want to introduce "$root" variable that always
contains the appropriate partial path in conceptual tree. The
translated XPath in the example would then become "$root/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 "descendant-schema-nodeid" in Section 12 of [5]) ABNF production for and "descendant-schema-nodeid" in Section 12 of
that appear as items in the arguments of 'key' and 'unique' [5]) are not XPath expressions but SHOULD be translated by adding
statements, respectively, are special XPath expressions and MUST be local module prefixes as well.
translated in the same way, i.e., after the translation each key and
every component of a node identifier must have the namespace prefix
of the local module.
8.4. YANG Language Extensions 8.4. YANG Language Extensions
YANG allows for extending its own language in-line by adding new YANG allows for extending its own language in-line by adding new
statements with keywords from special namespaces. Such extensions statements with keywords from special namespaces. Such extensions
first have to be declared using the 'extension' statement and then first have to be declared using the 'extension' statement and then
can be used as the native statements, only with a namespace prefix can be used as the native statements, only with a namespace prefix
qualifying the extension keyword. RELAX NG has a similar extension qualifying the extension keyword. RELAX NG has a similar extension
mechanism - XML elements and attributes with names from foreign mechanism - XML elements and attributes with names from foreign
namespaces may be inserted at almost every place of a RELAX NG namespaces may be inserted at almost every place of a RELAX NG
skipping to change at page 34, line 29 skipping to change at page 36, line 20
This extension can then be used in the same or another module, for This extension can then be used in the same or another module, for
instance like this: instance like this:
leaf folio { leaf folio {
acme:documentation-flag 42; acme:documentation-flag 42;
type string; type string;
} }
If this extension is honored by the mapping, it will be mapped to If this extension is honored by the mapping, it will be mapped to
<rng:element name="folio"> <rng:element name="acme:folio">
<acme:documentation-flag number="42"/> <acme:documentation-flag number="42"/>
<rng:data type="string"/> <rng:data type="string"/>
</rng:element> </rng:element>
Note that the 'extension' statement itself is not mapped in any way. Note that the 'extension' statement itself is not mapped in any way.
9. Mapping Conceptual Tree Schema to DSDL 9. Mapping Conceptual Tree Schema to DSDL
As explained in Section 5, the second step of the YANG-to-DSDL As explained in Section 5, the second step of the YANG-to-DSDL
mapping takes the conceptual tree schema and transforms it to various mapping takes the conceptual tree schema and transforms it to various
DSDL schemas ready for validation. As an input parameter, this step DSDL schemas ready for validation. As an input parameter, this step
gets in the simplest case a specification of the NETCONF XML document gets in the simplest case a specification of the NETCONF XML document
type (or combination of multiple types) that is to be validated. type (or combination of multiple types) that is to be validated.
These document type can be for example reply to <nc:get> or <nc:get- These document type can be, for example, the content of a datastore,
config>, RPC requests or replies and notification. Other parameters reply to <nc:get> or <nc:get-config>, other RPC requests or replies
further describing the context may also be provided, such as the list and notifications.
of active capabilities, features etc.
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 or 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 accommodated 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 datastore or <en:
notification> for a notification. notification> for a notification.
3. Finally, NETMOD-specific annotations that are relevant for the 3. Finally, NETMOD-specific annotations that are relevant for the
schema language of the generated schema must be mapped to schema language of the generated schema must be mapped to
corresponding schema-language-specific rules. corresponding schema-language-specific rules.
These three tasks are together much simpler than the first mapping These three tasks are together much simpler than the first mapping
step. Presumably, they can be effectively realized using XSL step. Presumably, they can be effectively realized using XSL
skipping to change at page 36, line 10 skipping to change at page 38, line 10
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 identical named pattern definitions to the
output RELAX NG file, these schema-independent definition are output RELAX NG file, these schema-independent definitions SHOULD be
collected in a library file "relang-lib.rng" which is then included collected in a library file which is then included by the validating
by the validating RELAX NG schemas. Appendix B has the listing of RELAX NG schemas. Appendix B has the listing of this library file.
this library file.
The minor exception mentioned above is the annotation @nma:config, The minor exception mentioned above is the annotation @nma:config,
which must be observed if the target document type is <get-config> which must be observed if the target document type is <get-config>
reply. In this case, each element definition that has this attribute reply. In this case, each element definition that has this attribute
with the value "false" MUST be removed from the schema together with with the value "false" MUST be removed from the schema together with
its descendants. See Section 11.1 for more details. its descendants. See Section 11.1 for more details.
9.1.1. Reply to <get> or <get-config> 9.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 37, line 8 skipping to change at page 39, line 7
that are really used in the particular output grammar. that are really used in the particular output grammar.
9.1.2. Remote Procedure Calls 9.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 in 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 subtree ...
... "nmt:rpc-method/nmt:input/yam:myrpc" ... ... "nmt:rpc-method/nmt:input/yam:myrpc" ...
skipping to change at page 38, line 22 skipping to change at page 40, line 22
"nmt:rpc-notification/yam:mynotif" subtree --> "nmt:rpc-notification/yam:mynotif" subtree -->
</rng:element> </rng:element>
</rng:element> </rng:element>
</rng:start> </rng:start>
<!-- named pattern definitions --> <!-- named pattern definitions -->
</rng:grammar> </rng:grammar>
The definition of the named pattern "eventTime-element" is found in The definition of the named pattern "eventTime-element" is found in
the "relaxng-lib.rng" library file. the "relaxng-lib.rng" library file.
And again, exact copies of named pattern definitions from the Again, exact copies of named pattern definitions from the conceptual
conceptual tree schema MUST be inserted, but an implementation MAY tree schema MUST be inserted, but an implementation MAY choose to
choose to include only those used for the given notification. include only those used for the given notification.
9.2. Mapping Semantic Constraints to Schematron 9.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 with exactly four levels of XML hierarchy: <sch:schema>, to RELAX NG. They have exactly four levels of XML hierarchy: <sch:
<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 in element. Every rule corresponds to exactly one element definition
the conceptual tree schema. The mandatory @context attribute of pattern in the conceptual tree schema:
<sch:rule> is set to the absolute path of the corresponding element
in the data tree.
In the opposite direction, however, not every element definition has <sch:rule context="XELEM">
a corresponding rule in the Schematron schema: only those definitions ...
are taken into account that are annotated with at least one of the </sch:rule>
following NETMOD-specific annotations: <nma:instance-identifier>,
@nma:key, <nma:leafref>, @nma:min-elements, @nma:max-elements, <nma: The value of the mandatory @context attribute of <sch:rule> is set to
must>, @nma:unique and <nma:when>. the absolute path of the context element in the data tree. The <sch:
rule> element contains the mappings of one or more of the following
NETMOD-specific annotations, if they are attached to the context
element: <nma:instance-identifier>, @nma:key, @nma:leafref, @nma:min-
elements, @nma:max-elements, <nma:must>, @nma:unique and <nma:when>.
In the opposite direction, however, not every element definition
pattern in the conceptual tree schema has a corresponding rule in the
Schematron schema: definitions of elements the carry none of the
above annotations are omitted.
Schematron rules may be further grouped into _patterns_ represented Schematron rules may be further grouped into _patterns_ represented
by the <sch:pattern> element. The mapping uses patterns only for by the <sch:pattern> element. The mapping uses patterns only for
discriminating between subsets of rules that belong to different discriminating between subsets of rules that belong to different
validation phases, see Section 9.2.1. Therefore, the <sch:schema> validation phases, see Section 9.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 _abstract referred to in multiple different places. The mapping uses
rules_ to handle this case: An element definition inside a named Schematron _abstract rules_ to handle this case: An element
pattern is mapped to an abstract rule and every use of the named definition inside a named pattern is mapped to an abstract rule and
pattern then extends this abstract pattern in the concrete context. every use of the named pattern then extends (uses) this abstract rule
in the concrete context.
EXAMPLE. Consider this element definition annotated with <nma:must>: EXAMPLE. Consider this element definition 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 41, line 14 skipping to change at page 43, line 22
5. All annotations attached to the given element definition are then 5. All annotations attached to the given element definition are then
mapped using the mapping rules specified in Section 11. The mapped using the mapping rules specified in Section 11. The
resulting <sch:assert> or <sch:report> elements are the installed resulting <sch:assert> or <sch:report> elements are the installed
as children of the <sch:rule> element. as children of the <sch:rule> element.
9.2.1. Validation Phases 9.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.
skipping to change at page 43, line 28 skipping to change at page 45, line 28
</rng:group> </rng:group>
<rng:element name="ex4:bar"> <rng:element name="ex4:bar">
<rng:data type="unsignedByte"/> <rng:data type="unsignedByte"/>
</rng:element> </rng:element>
</rng:choice> </rng:choice>
In the second case branch, the "ex4:bar" element is defined as In the second case branch, the "ex4:bar" element is defined as
mandatory so that this element must be present in a valid mandatory so that this element must be present in a valid
configuration if this branch is selected. However, the two elements configuration if this branch is selected. However, the two elements
in the first branch "foo" cannot be both declared as mandatory since in the first branch "foo" cannot be both declared as mandatory since
each one of them alone suffices for a valid configuration. As a each of them alone suffices for a valid configuration. As a result,
result, the above RELAX NG fragment would successfully validate the above RELAX NG fragment would successfully validate
configurations where none of the three leafs elements is present. configurations where none of the three leaf elements is present.
Therefore, mandatory choices, which can be recognized in the Therefore, mandatory choices, which can be recognized in the
conceptual tree schema as <rng:choice> elements that do not have conceptual tree schema as <rng:choice> elements that do not have
<optional> as their parent, have to be handled in a special way: For <optional> as their parent, have to be handled in a special way: For
each mandatory choice where at least one of the cases contains more each mandatory choice where at least one of the cases contains more
than one node, a rule MUST be present in the "standard" pattern of than one node, a rule MUST be present in the "standard" pattern of
the Schematron schema enforcing the presence of at least one element the Schematron schema enforcing the presence of at least one element
from any of the cases. (RELAX NG schema guarantees that elements from any of the cases. (RELAX NG schema guarantees that elements
from different cases cannot be mixed together, that all mandatory from different cases cannot be mixed together, that all mandatory
nodes are present etc.). nodes are present etc.).
For the example module above, the Schematron rule can be as follows: For the example module above, the Schematron rule will be as follows:
<sch:rule context="/nc:rpc-reply/nc:data"> <sch:rule context="/nc:rpc-reply/nc:data">
<sch:assert test="ex4:foo1 or ex4:foo2 or ex4:bar"> <sch:assert test="ex4:foo1 or ex4:foo2 or ex4:bar">
Node(s) from at least one case of choice "foobar" must exist. Node(s) from at least one case of choice "foobar" must exist.
</sch:assert> </sch:assert>
</sch:rule> </sch:rule>
9.4. Mapping Default Values to DSRL 9.4. Mapping Default Values to DSRL
DSRL is the only component of DSDL that changes the information set DSRL is the only component of DSDL that is allowed to change the
of the validated XML document. While DSRL has other functions, the information set of the validated XML document. While DSRL has other
YANG-to-DSDL mapping uses it only for specifying default content. functions, the YANG-to-DSDL mapping uses it only for specifying
For XML instance documents based on YANG data model, insertion of default content. For XML instance documents based on YANG data
default content in general includes not only default values for leaf models, insertion of default content takes place for all implicit
elements but also containers without presence. The following nodes, see Section 8.1.
definition helps in explaining the steps needed for generating the
DSRL schema.
For a given conceptual tree schema and XML instance document, we
define _implicit element_ to be an element that is inserted in the
process of substituting the default content, provided that its parent
element exists in the instance document.
Now, let C be a conceptual tree schema and D a NETCONF instance
document. Denote R the RELAX NG schema for the document type of D,
which is generated form C and assume D is a valid XML document with
respect to R. Let P be an element appearing in D. According to the
YANG rules, an element E, which is defined as an optional child of P
in the data tree, is an implicit element if and only if it is either
a leaf element whose definition in C has a default value specified
in the @nma:default attribute, or
a container element that does not have the @nma:presence attribute
set to "true" in C and at least one of its children in the data
tree is an implicit element.
Element E has to satisfy additional conditions in the following two
special cases in order to be an implicit element, regardless of
whether it is a leaf or container:
o If E is defined in C inside an alternative of <rng:choice>, then
this alternative must be marked as the default one with @nma:
default-case="true" in C.
o If the definition of E in C carries the @nma:when attribute, then
the condition in the value of @nma:when must be true in the
context of the instance document D.
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-
Two sibling elements of <dsrl:default-content> determine the context map>. Two sibling elements of <dsrl:default-content> determine the
for application of the default content, see [11]: context for application of the default content, see [11]:
o <dsrl:parent> element contains an XSLT pattern specifying the o <dsrl:parent> element contains an XSLT pattern specifying the
parent element; the default content is applied only if the parent parent element; the default content is applied only if the parent
element exists in the instance document. element exists in the instance document.
o <dsrl:name> contains the XML name of the element which is inserted o <dsrl:name> contains the XML name of the element which, if missing
together with the content of <dsrl:default-content>. or empty, is inserted together with the content of <dsrl:default-
content>.
The <dsrl:parent> element is optional in a general DSRL schema but The <dsrl:parent> element is optional in a general DSRL schema but
for the purpose of the YANG-to-DSDL mapping this element MUST be for the purpose of the YANG-to-DSDL mapping this element MUST be
always present in order to guarantee proper application of default always present in order to guarantee proper application of default
content. content.
The logic of DSRL implies that for every non-leaf element P (implicit DSRL mapping only deals with element patterns defining implicit nodes
or not) containing at least one implicit element among its children, (see Section 8.1.2). In the conceptual tree schema, such element
the DSRL schema must provide one element map for each implicit child patterns are distinguished by NETMOD-specific annotation attributes
element E, where the full XPath of P appears in the <dsrl:parent> that @nma:default or @nma:implicit, i.e., they are either
element and the name of E in <dsrl:name>.
<rng:element name="ELEM" nma:default="DEFVALUE">
...
</rng:element>
or
<rng:element name="ELEM" nma:implicit="true">
...
</rng:element>
In the simple case, these element patterns are mapped to the
following DSRL element map:
<dsrl:element-map>
<dsrl:parent>XPARENT</dsrl:parent>
<dsrl:name>ELEM</dsrl:name>
<dsrl:default-content>DEFCONT</dsrl:default-content>
</dsrl:element-map>
where XPARENT is the absolute XPath of ELEM's parent element in the
data tree and DEFCONT is constructed as follows:
If the element pattern defining ELEM is annotated with @nma:
default, DEFCONT is equal to the value of this attribute denoted
above as DEFVALUE.
Otherwise, if the element pattern defining ELEM is annotated with
@nma:implicit, DEFCONT is an XML fragment containing all
descendant elements of ELEM that have either @nma:implicit or
@nma:default attribute.
A more complicated situation arises when the element pattern defining
an implicit node ELEM is a child of <rng:group> with @nma:implicit
attribute. This corresponds to the default case of a YANG choice
(see Section 10.12) and the DSRL mapping has to make sure that the
default content is applied only if none of the nodes from any non-
default case are present. This is accomplished by setting <dsrl:
parent> in a special way:
<dsrl:parent>XPARENT[not (ELEM1|ELEM2|...|ELEMn)]</dsrl:parent>
where ELEM1, ELEM2, ... ELEMn are the names of top-level nodes from
all non-default cases. The rest of the element map is exactly as
above.
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;
} }
choice one-or-two { choice one-or-two {
default "one"; default "one";
container one { container one {
leaf leaf2 { leaf leaf2 {
type uint8; type uint8;
default "2"; default 2;
} }
} }
leaf leaf3 { leaf leaf3 {
type uint8; type uint8;
default "3"; default 3;
} }
} }
} }
} }
The DSRL schema generated for the "get-reply" target document type The DSRL schema generated for the "get-reply" target document type
will be: will be:
<dsrl:maps xmlns:dsrl="http://purl.oclc.org/dsdl/dsrl" <dsrl:maps xmlns:dsrl="http://purl.oclc.org/dsdl/dsrl"
xmlns:ex5="http://example.com/ns/example5" xmlns:ex5="http://example.com/ns/example5"
xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"> xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
<dsrl:element-map> <dsrl:element-map>
<dsrl:parent>/nc:rpc-reply/nc:data/</dsrl:parent> <dsrl:parent>/nc:rpc-reply/nc:data</dsrl:parent>
<dsrl:name>ex5:outer</dsrl:name> <dsrl:name>ex5:outer</dsrl:name>
<dsrl:default-content> <dsrl:default-content>
<ex5:leaf1>1</ex5:leaf1> <ex5:leaf1>1</ex5:leaf1>
<ex5:one><ex5:leaf2>2</ex5:leaf2></ex5:one>
</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/</dsrl:parent> <dsrl:parent>
/nc:rpc-reply/nc:data/ex5:outer[not(ex5:leaf3)]
</dsrl:parent>
<dsrl:name>ex5:one</dsrl:name> <dsrl:name>ex5:one</dsrl:name>
<dsrl:default-content> <dsrl:default-content>
<ex5:leaf2>2</ex5:leaf2> <ex5:leaf2>2</ex5:leaf2>
</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</dsrl:parent> <dsrl:parent>/nc:rpc-reply/nc:data/ex5:outer</dsrl:parent>
<dsrl:name>ex5:leaf1</dsrl:name> <dsrl:name>ex5:leaf1</dsrl:name>
<dsrl:default-content>1</dsrl:default-content> <dsrl:default-content>1</dsrl:default-content>
</dsrl:element-map> </dsrl:element-map>
skipping to change at page 46, line 45 skipping to change at page 50, line 5
<dsrl:parent>/nc:rpc-reply/nc:data/ex5:outer/ex5:one</dsrl:parent> <dsrl:parent>/nc:rpc-reply/nc:data/ex5:outer/ex5:one</dsrl:parent>
<dsrl:name>ex5:leaf2</dsrl:name> <dsrl:name>ex5:leaf2</dsrl:name>
<dsrl:default-content>2</dsrl:default-content> <dsrl:default-content>2</dsrl:default-content>
</dsrl:element-map> </dsrl:element-map>
</dsrl:maps> </dsrl:maps>
Note that the default value for "leaf3" defined in the YANG module is Note that the default value for "leaf3" defined in the YANG module is
ignored, because "leaf3" represents a non-default alternative of a ignored, because "leaf3" represents a non-default alternative of a
choice and as such can never become an implicit element. choice and as such can never become an implicit element.
Since DSRL has no facilities similar to named patterns in RELAX NG, 10. Mapping YANG Statements to Conceptual Tree Schema
their definitions used in the conceptual tree schema must be expanded
in all places where they are referenced.
10. Mapping YANG Statements to Annotated RELAX NG
Each subsection in this section is devoted to one YANG statement and Each subsection in this section is devoted to one YANG statement and
provides the specification how the statement is mapped to the provides the specification how the statement is mapped to the
annotated RELAX NG schema of the conceptual tree. This is the first annotated RELAX NG schema of the conceptual tree. This is the first
step of the mapping procedure, see Section 5. The subsections are step of the mapping procedure, see Section 5. The subsections are
sorted alphabetically by the statement keyword. sorted alphabetically by the statement keyword.
Each YANG statement is mapped to an XML fragment, typically a single Each YANG statement is mapped to an XML fragment, typically a single
element or attribute but it may also be a larger structure. The element or attribute but it may also be a larger structure. The
mapping algorithm is inherently recursive, which means that after mapping algorithm is inherently recursive, which means that after
skipping to change at page 47, line 48 skipping to change at page 50, line 48
We use the following notation: We use the following notation:
o The argument of the statement being mapped is denoted by ARGUMENT. o The argument of the statement being mapped is denoted by ARGUMENT.
o The element in the RELAX NG schema that becomes the parent of the o The element in the RELAX NG schema that becomes the parent of the
resulting XML fragment is denoted by PARENT. resulting XML fragment is denoted by PARENT.
10.1. The anyxml Statement 10.1. The anyxml Statement
This statement is mapped to <rng:element> element and ARGUMENT This statement is mapped to <rng:element> element and ARGUMENT with
becomes the value of its @name attribute. The content of <rng: prepended local namespace prefix becomes the value of its @name
element> is attribute. The content of <rng:element> is
<rng:ref name="__anyxml__"/> <rng:ref name="__anyxml__"/>
Substatements of the 'anyxml' statement are mapped to additional Substatements of the 'anyxml' statement, if any, may be mapped to
children of the RELAX NG element definition. additional children of the RELAX NG element definition.
If the 'anyxml' statement occurs in any of the input YANG modules, If the 'anyxml' statement occurs in any of the input YANG modules,
the following pattern definition MUST be added exactly once to the the following pattern definition MUST be added exactly once to the
RELAX NG schema as a child of the <rng:grammar> element (cf. [21], p. RELAX NG schema as a child of the <rng:grammar> element (cf. [21], p.
172): 172):
<rng:define name="__anyxml__"> <rng:define name="__anyxml__">
<rng:zeroOrMore> <rng:zeroOrMore>
<rng:choice> <rng:choice>
<rng:attribute> <rng:attribute>
skipping to change at page 48, line 27 skipping to change at page 51, line 27
</rng:attribute> </rng:attribute>
<rng:element> <rng:element>
<rng:anyName/> <rng:anyName/>
<rng:ref name="__anyxml__"/> <rng:ref name="__anyxml__"/>
</rng:element> </rng:element>
<rng:text/> <rng:text/>
</rng:choice> </rng:choice>
</rng:zeroOrMore> </rng:zeroOrMore>
</rng:define> </rng:define>
EXAMPLE: YANG statement EXAMPLE: YANG statement in a module with namespace prefix "yam"
anyxml data { anyxml data {
description "Any XML content allowed here."; description "Any XML content allowed here.";
} }
maps to the following fragment: is mapped to the following fragment:
<rng:element name="data"> <rng:element name="yam:data">
<a:documentation>Any XML content allowed here</a:documentation> <a:documentation>Any XML content allowed here</a:documentation>
<rng:ref name="__anyxml__"/> <rng:ref name="__anyxml__"/>
</rng:element> </rng:element>
An anyxml node is optional if there is no "mandatory true;"
substatement. The <rng:element> element then MUST be wrapped in
<rng:optional>, except when the 'anyxml' statement is a child of the
'choice' statement and thus forms a shorthand case for that choice
(see Section 8.1.1 for details).
10.2. The argument Statement 10.2. The argument Statement
This statement is not mapped to the output schema, but see the rules This statement is not mapped to the output schema, but see the rules
for extension handling in Section 8.4. for handling extensions in Section 8.4.
10.3. The augment Statement 10.3. The augment Statement
As a substatement of 'uses', this statement is handled as a part of As a substatement of 'uses', this statement is handled as a part of
'uses' mapping, see Section 10.57. 'uses' mapping, see Section 10.57.
At the top level of a module or submodule, the 'augment' statement is At the top level of a module or submodule, the 'augment' statement is
used for augmenting the schema tree of another YANG module. If the used for augmenting the schema tree of another YANG module. If the
latter module is not processed within the same mapping session, the latter module is not processed within the same mapping session, the
top-level 'augment' statement MUST be ignored. Otherwise, the top-level 'augment' statement MUST be ignored. Otherwise, the
skipping to change at page 49, line 28 skipping to change at page 52, line 36
initiated from the main module, see Section 10.24. initiated from the main module, see Section 10.24.
10.6. The bit Statement 10.6. The bit Statement
This statement is handled within the "bits" type, see This statement is handled within the "bits" type, see
Section 10.53.3. Section 10.53.3.
10.7. The case Statement 10.7. The case Statement
This statement is mapped to <rng:group> element. If the argument of This statement is mapped to <rng:group> element. If the argument of
a sibling 'default' statement equals to ARGUMENT, @nma:default-case a sibling 'default' statement equals to ARGUMENT, @nma:implicit
attribute with the value of "true" is added to that <rng:group> attribute with the value "true" MUST be added to that <rng:group>
element. element. The @nma:implicit attribute MUST NOT be used for nodes that
belong to non-default cases of a choice (see Section 7.9.3 in [5]).
10.8. The choice Statement 10.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 of Unless 'choice' has the 'mandatory' substatement with the value
"true", the <rng:choice> element MUST be wrapped in <rng:optional>. "true", the <rng:choice> element MUST be wrapped in <rng:optional>.
The 'choice' statement with "mandatory true;" requires additional The 'choice' statement with "mandatory true;" requires additional
handling, see Section 9.3. handling, see Section 9.3.
The alternatives in <rng:choice> - mapped from either the 'case'
statement or a shorthand case - MUST NOT be defined as optional.
10.9. The config Statement 10.9. The config Statement
This statement is mapped to @nma:config attribute and ARGUMENT This statement is mapped to @nma:config attribute and ARGUMENT
becomes its value. becomes its value.
10.10. The contact Statement 10.10. The contact Statement
This statement is not used by the mapping since the output RELAX NG This statement is not used by the mapping since the output RELAX NG
schema may result from multiple YANG modules created by different schema may result from multiple YANG modules created by different
authors. The schema contains references to all input modules in the authors. The schema contains references to all input modules in the
Dublin Core elements <dc:source>, see Section 10.34. The original Dublin Core elements <dc:source>, see Section 10.34. The original
modules are the authoritative sources of the authorship information. YANG modules are the authoritative sources of the authorship
information.
10.11. The container Statement 10.11. The container Statement
Using the procedure outlined in Section 8.1, the mapping algorithm Using the rules specified in Section 8.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
as the value of its @name attribute. with prepended local namespace prefix as the value of its @name
attribute.
Finally, using the rules specified in Section 8.1.2, the mapping
algorithm MUST determine whether the container is implicit, and if
so, add the attribute @nma:implicit with the value "true" to the
<rng:element> element.
10.12. The default Statement 10.12. The default Statement
If this statement is a substatement of 'typedef' or 'leaf', it is If this statement is a substatement of 'typedef' or 'leaf', it is
mapped to the @nma:default attribute of PARENT and ARGUMENT becomes mapped to the @nma:default attribute of PARENT and ARGUMENT becomes
its value. its value.
The @nma:default attribute MUST NOT be used for nodes that belong to
non-default cases of a choice (see Section 7.9.3 in [5]).
As a substatement of 'choice', the 'default' statement identifies the As a substatement of 'choice', the 'default' statement identifies the
default case and is handled within the 'case' statement, see default case and is handled within the 'case' statement, see
Section 10.7. If the default case uses the shorthand notation where Section 10.7. If the default case uses the shorthand notation where
the 'case' statement is omitted, an extra <rng:group> element MUST be the 'case' statement is omitted, an extra <rng:group> element MUST be
inserted with @nma:default-case attribute set to "true". The net inserted with @nma:implicit attribute set to "true" and map the
result is then the same as if the 'case' statement wasn't omitted for default case node inside this element. The net result is then the
the default case. same as if the 'case' statement wasn't omitted for the default case.
EXAMPLE. The following 'choice' statement EXAMPLE. The following 'choice' statement in a module with namespace
prefix "yam"
choice leaves { choice leaves {
default feuille; default feuille;
leaf feuille { type empty; } leaf feuille { type empty; }
leaf hoja { type empty; } leaf hoja { type empty; }
} }
is mapped to is mapped to
<rng:choice> <rng:choice>
<rng:group nma:default="true"> <rng:group nma:implicit="true">
<rng:element name="feuille"> <rng:element name="yam:feuille">
<rng:empty/> <rng:empty/>
</rng:element> </rng:element>
</rng:group> </rng:group>
<rng:element name="hoja"> <rng:element name="yam:hoja">
<rng:empty/> <rng:empty/>
</rng:element/> </rng:element/>
</rng:choice> </rng:choice>
10.13. The description Statement 10.13. The description Statement
This statement is ignored if it appears at the top level of each This statement is ignored if it appears at the top level of each
input YANG module. The description can be found in the source module input YANG module. The description can be found in the source module
that is referred to by Dublin Core element <dc:source> and use that is referred to by Dublin Core element <dc:source> and use
ARGUMENT as its content. ARGUMENT as its content.
Otherwise, this statement is mapped to the DTD compatibility element Otherwise, this statement is mapped to the DTD compatibility element
<a:documentation> and ARGUMENT becomes its text. <a:documentation> and ARGUMENT becomes its text.
In order to get properly formatted in the RELAX NG compact syntax, In order to get properly formatted in the RELAX NG compact syntax,
this element SHOULD be inserted as the first child of PARENT. this element SHOULD be inserted as the first child of PARENT.
10.14. The deviation Statement 10.14. The deviation Statement
All 'deviation' statements found in the input YANG modules MUST be This statement is ignored, see Section 7.5.
applied first so that the mapping algorithm operates on a schema tree
with all deviations already incorporated.
10.15. The enum Statement 10.15. The enum Statement
This statement is mapped to <rng:value> element and ARGUMENT becomes This statement is mapped to <rng:value> element and ARGUMENT becomes
its text. All substatements except 'status' are ignored because the its text. All substatements except 'status' are ignored because the
<rng:value> element cannot contain annotations, see [12], section 6. <rng:value> element cannot contain annotations, see [12], section 6.
10.16. The error-app-tag Statement 10.16. The error-app-tag Statement
This statement is ignored unless it is a substatement of 'must'. In This statement is ignored unless it is a substatement of 'must'. In
skipping to change at page 51, line 49 skipping to change at page 55, line 24
the latter case it is mapped to the <nma:error-message> element. See the latter case it is mapped to the <nma:error-message> element. See
also Section 10.35. also Section 10.35.
10.18. The extension Statement 10.18. The extension Statement
This statement is ignored. However, extensions to the YANG language This statement is ignored. However, extensions to the YANG language
MAY be mapped as described in Section 8.4. MAY be mapped as described in Section 8.4.
10.19. The feature Statement 10.19. The feature Statement
This statement is ignored. This statement is ignored, see Section 7.5.
10.20. The grouping Statement 10.20. The grouping Statement
This statement is mapped to a RELAX NG named pattern definition <rng: This statement is mapped to a RELAX NG named pattern definition <rng:
define>, but only if the grouping defined by this statement is used define>, but only if the grouping defined by this statement is used
_without refinements and augments_ in at least one of the input _without refinements and augments_ in at least one of the input
modules. In this case, the named pattern definition becomes a child modules. In this case, the named pattern definition becomes a child
of the <rng:grammar> element and its name is ARGUMENT mangled of the <rng:grammar> element and its name is ARGUMENT mangled
according to the rules specified in Section 8.2. according to the rules specified in Section 8.2.
skipping to change at page 52, line 34 skipping to change at page 56, line 7
10.21. The identity Statement 10.21. The identity Statement
This statement is not specifically mapped. However, if the identity This statement is not specifically mapped. However, if the identity
defined by this statement is used as the base for an "identityref" defined by this statement is used as the base for an "identityref"
type in any of the input modules, ARGUMENT will appear as the text of type in any of the input modules, ARGUMENT will appear as the text of
one of the <rng:value> elements in the mapping of that "identityref" one of the <rng:value> elements in the mapping of that "identityref"
type. See Section 10.53.5 for more details and an example. type. See Section 10.53.5 for more details and an example.
10.22. The if-feature Statement 10.22. The if-feature Statement
The information whether a given feature is available or not MUST be This statement is ignored, see Section 7.5.
supplied to the mapping procedure, which MUST modify the YANG schema
tree by including or excluding the parts that depend on that feature.
10.23. The import Statement 10.23. The import Statement
This statement is not specifically mapped. The module whose name is This statement is not specifically mapped. The module whose name is
in ARGUMENT has to be parsed so that the importing module be able to in ARGUMENT has to be parsed so that the importing module be able to
use its top-level groupings and typedefs and also augment the data use its top-level groupings and typedefs and also augment the data
tree of the imported module. tree of the imported module.
If the 'import' statement has the 'revision' substatement, the If the 'import' statement has the 'revision' substatement, the
corresponding revision of the imported module MUST be used. The corresponding revision of the imported module MUST be used. The
skipping to change at page 53, line 30 skipping to change at page 56, line 46
10.26. The key Statement 10.26. The key Statement
This statement is mapped to @nma:key attribute. ARGUMENT is MUST be This statement is mapped to @nma:key attribute. ARGUMENT is MUST be
translated so that every key is prefixed with the namespace prefix of translated so that every key is prefixed with the namespace prefix of
the local module. The result of this translation then becomes the the local module. The result of this translation then becomes the
value of the @nma:key attribute. value of the @nma:key attribute.
10.27. The leaf Statement 10.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
becomes the value of its @name attribute. with prepended local namespace prefix becomes the value of its @name
attribute.
The leaf is optional if there is no "mandatory true;" substatement A leaf is optional if there is no "mandatory true;" substatement and
and if the leaf is not declared among the keys of an enclosing list. if the leaf is not declared among the keys of an enclosing list. The
In this case, the <rng:element> element MUST be wrapped in <rng: <rng:element> element then MUST be wrapped in <rng:optional>, except
optional>. when the 'leaf' statement is a child of the 'choice' statement and
thus forms a shorthand case for that choice (see Section 8.1.1 for
details).
10.28. The leaf-list Statement 10.28. The leaf-list Statement
This statement is mapped to a block enclosed by either <rng: This statement is mapped to a block enclosed by either <rng:
zeroOrMore> or <rng:oneOrMore> element depending on whether the zeroOrMore> or <rng:oneOrMore> element depending on whether the
argument of 'min-elements' substatement is "0" or positive, argument of 'min-elements' substatement is "0" or positive,
respectively (it is zero by default). This <rng:zeroOrMore> or <rng: respectively (it is zero by default). This <rng:zeroOrMore> or <rng:
oneOrMore> element becomes the PARENT. oneOrMore> element becomes the PARENT.
<rng:element> is the added as a child element of PARENT and ARGUMENT <rng:element> is the added as a child element of PARENT and ARGUMENT
becomes the value of its @name attribute. If the 'leaf-list' with prepended local namespace prefix becomes the value of its @name
statement has the 'min-elements' substatement and its argument is attribute. If the 'leaf-list' statement has the 'min-elements'
greater than one, additional attribute @nma:min-elements is attached substatement and its argument is greater than one, additional
to <rng:element> and the argument of 'min-elements' becomes the value attribute @nma:min-elements is attached to <rng:element> and the
of this attribute. Similarly, if there is the 'max-elements' argument of 'min-elements' becomes the value of this attribute.
substatement and its argument value is not "unbounded", attribute Similarly, if there is the 'max-elements' substatement and its
@nma:max-elements is attached to this element and the argument of argument value is not "unbounded", attribute @nma:max-elements is
'max-elements' becomes the value of this attribute. attached to this element and the argument of 'max-elements' becomes
the value of this attribute.
EXAMPLE. YANG leaf-list EXAMPLE. YANG leaf-list in a module with namespace prefix "yam"
leaf-list foliage { leaf-list foliage {
min-elements 3; min-elements 3;
max-elements 6378; max-elements 6378;
ordered-by user; ordered-by user;
type string; type string;
} }
is mapped to the following RELAX NG fragment: is mapped to the following RELAX NG fragment:
<rng:oneOrMore> <rng:oneOrMore>
<rng:element name="foliage" nma:ordered-by="user" <rng:element name="yam:foliage" nma:ordered-by="user"
nma:min-elements="3" nma:max-elements="6378"> nma:min-elements="3" nma:max-elements="6378">
<rng:data type="string"/> <rng:data type="string"/>
</rng:element> </rng:element>
</rng:oneOrMore> </rng:oneOrMore>
10.29. The length Statement 10.29. The length Statement
This statement is handled within the "string" type, see This statement is handled within the "string" type, see
Section 10.53.9. Section 10.53.9.
10.30. The list Statement 10.30. The list Statement
This statement is mapped exactly as the 'leaf-list' statement, see This statement is mapped exactly as the 'leaf-list' statement, see
Section 10.28. Section 10.28.
10.31. The mandatory Statement 10.31. The mandatory Statement
This statement may appear as a substatement of 'leaf', 'choice' or This statement may appear as a substatement of 'leaf', 'choice' or
'anyxml' statement. If ARGUMENT is "true", the parent data node is 'anyxml' statement. If ARGUMENT is "true", the parent data node is
mapped as mandatory, see Section 8.1. mapped as mandatory, see Section 8.1.1.
10.32. The max-elements Statement 10.32. The max-elements Statement
This statement is handled within 'leaf-list' or 'list' statements, This statement is handled within 'leaf-list' or 'list' statements,
see Section 10.28. see Section 10.28.
10.33. The min-elements Statement 10.33. The min-elements Statement
This statement is handled within 'leaf-list' or 'list' statements, This statement is handled within 'leaf-list' or 'list' statements,
see Section 10.28. see Section 10.28.
skipping to change at page 57, line 19 skipping to change at page 60, line 39
10.44. The prefix Statement 10.44. The prefix Statement
This statement is handled within the sibling 'namespace' statement, This statement is handled within the sibling 'namespace' statement,
see Section 10.36, or within the parent 'import' statement, see see Section 10.36, or within the parent 'import' statement, see
Section 10.23. As a substatement of 'belongs-to' (in submodules), Section 10.23. As a substatement of 'belongs-to' (in submodules),
the 'prefix' statement is ignored. the 'prefix' statement is ignored.
10.45. The presence Statement 10.45. The presence Statement
This statement is mapped to the annotation attribute @nma:presence This statement is mapped to the annotation attribute @nma:presence
with the value of "true". In addition, it influences the mapping of with the value "true". In addition, it influences the mapping of
'container' (Section 10.11): the parent container definition MUST be 'container' (Section 10.11): the parent container definition MUST be
wrapped in <rng:optional>, regardless of its content. See also wrapped in <rng:optional>, regardless of its content. See also
Section 8.1. Section 8.1.1.
10.46. The range Statement 10.46. The range Statement
This statement is handled within numeric types, see Section 10.53.8. This statement is handled within numeric types, see Section 10.53.8.
10.47. The reference Statement 10.47. The reference Statement
This statement is ignored if it appears at the top level of a module This statement is ignored if it appears at the top level of a module
or submodule. or submodule.
Otherwise, this statement is mapped to <a:documentation> element and Otherwise, this statement is mapped to <a:documentation> element and
its text is set to ARGUMENT prefixed with "See: ". its text is set to ARGUMENT prefixed with "See: ".
10.48. The require-instance Statement 10.48. The require-instance Statement
This statement is handled within the types "leafref" This statement is handled within "instance-identifier" type
(Section 10.53.7) and "instance-identifier" (Section 10.53.6). (Section 10.53.6).
10.49. The revision Statement 10.49. The revision Statement
The mapping uses only the most recent instance of the 'revision' The mapping uses only the most recent instance of the 'revision'
statement, i.e., one with the latest date in ARGUMENT, which statement, i.e., one with the latest date in ARGUMENT, which
specifies the current revision of the input YANG module [5]. This specifies the current revision of the input YANG module [5]. This
date SHOULD be recorded, together with the name of the YANG module, date SHOULD be recorded, together with the name of the YANG module,
in the corresponding Dublin Core element <dc:source> (see in the corresponding Dublin Core element <dc:source> (see
Section 10.34), for example in this form: Section 10.34), for example in this form:
skipping to change at page 59, line 5 skipping to change at page 62, line 21
This statement is not specifically mapped. Its substatements are This statement is not specifically mapped. Its substatements are
mapped as if they appeared directly in the module the submodule mapped as if they appeared directly in the module the submodule
belongs to. belongs to.
10.53. The type Statement 10.53. The type Statement
Most YANG built-in types have an equivalent in the XSD datatype Most YANG built-in types have an equivalent in the XSD datatype
library [16] as shown in Table 3. library [16] 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 |
| | | | | | | |
| int64 | long | 64-bit integer value | | int64 | long | 64-bit integer value |
| | | | | | | |
| uint8 | unsignedByte | 8-bit unsigned integer value | | uint8 | unsignedByte | 8-bit unsigned integer value |
| | | | | | | |
| uint16 | unsignedShort | 16-bit unsigned integer value | | uint16 | unsignedShort | 16-bit unsigned integer value |
| | | | | | | |
| uint32 | unsignedInt | 32-bit unsigned integer value | | uint32 | unsignedInt | 32-bit unsigned integer value |
| | | | | | | |
| uint64 | unsignedLong | 64-bit unsigned integer value | | uint64 | unsignedLong | 64-bit unsigned integer value |
| | | | | | | |
| float32 | float | 32-bit IEEE floating-point value |
| | | |
| float64 | double | 64-bit IEEE floating-point 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: Selected datatypes from the W3C XML Schema Type Library
Details about the mapping of individual YANG built-in types are given Details about the mapping of individual YANG built-in types are given
in the following subsections. in the following subsections.
10.53.1. The empty Type 10.53.1. The empty Type
This type is mapped to <rng:empty/>. This type is mapped to <rng:empty/>.
skipping to change at page 61, line 35 skipping to change at page 64, line 35
base "crypto:crypto-alg"; base "crypto:crypto-alg";
description "DES crypto algorithm"; description "DES crypto algorithm";
} }
identity des3 { identity des3 {
base "crypto:crypto-alg"; base "crypto:crypto-alg";
description "Triple DES crypto algorithm"; description "Triple DES crypto algorithm";
} }
} }
If these two modules are imported to another module, leaf definition If these two modules are imported to another module with namespace
prefix "yam", leaf definition
leaf crypto { leaf crypto {
type identityref { type identityref {
base "crypto:crypto-alg"; base "crypto:crypto-alg";
} }
} }
is mapped to is mapped to
<rng:element name="crypto"> <rng:element name="yam:crypto">
<rng:choice> <rng:choice>
<rng:value type="QName">crypto:crypto-alg</value> <rng:value type="QName">crypto:crypto-alg</value>
<rng:value type="QName">des:des</value> <rng:value type="QName">des:des</value>
<rng:value type="QName">des:des3</value> <rng:value type="QName">des:des3</value>
</rng:choice> </rng:choice>
</rng:element> </rng:element>
The "crypto" and "des" prefixes will by typically defined via The "crypto" and "des" prefixes will by typically defined via
attributes of the <rng:grammar> element. attributes of the <rng:grammar> element.
10.53.6. The instance-identifier Type 10.53.6. The instance-identifier Type
This type is mapped to <rng:data> element with @type attribute set to This type is mapped to <rng:data> element with @type attribute set to
"string". In addition, empty <nma:instance-identifier> element MUST "string". In addition, empty <nma:instance-identifier> element MUST
be inserted as a child of PARENT. be inserted as a child of PARENT.
The 'require-instance' substatement, if it exists, is mapped to the The 'require-instance' substatement, if it exists, is mapped to the
@require-instance attribute of <nma:instance-identifier>. @require-instance attribute of <nma:instance-identifier>.
10.53.7. The leafref Type 10.53.7. The leafref Type
This type is mapped to <rng:data> element with @type attribute set to This type is mapped exactly as the type of the leaf given in the
the type of the leaf given in the argument of 'path' substatement. argument of 'path' substatement. In addition, @nma:leafref attribute
In addition, <nma:leafref> element MUST be inserted as a child of MUST be added to PARENT. The argument of the 'path' substatement,
PARENT. The argument value of the 'path' substatement is set as the translated according to Section 8.3, is set as the value of this
text of this element. attribute.
The 'require-instance' substatement, if it exists, is mapped to the
@require-instance attribute of <nma:leafref>.
10.53.8. The numeric Types 10.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", "float32" and "float64". They "uint8", "uint16", "uint32", "uint64" and "decimal64". They are
are mapped to <rng:data> element with @type attribute set to ARGUMENT mapped to <rng:data> element with @type attribute set to ARGUMENT
mapped according to Table 3. mapped according to Table 3.
An exception is the "decimal64" type, which is mapped to the
"decimal" type of the XSD datatype library. Its precision and number
of fractional digits are controlled with the following facets, which
MUST always be present:
o "totalDigits" facet set to the value of 19.
o "fractionDigits" facet set to the argument of the 'fraction-
digits' substatement.
The fixed value of the "totalDigits" facet corresponds to the maximum
of 19 decimal digits for 64-bit integers.
For example, the statement
type decimal64 {
fraction-digits 2;
}
is mapped to the following RELAX NG datatype:
<rng:data type="decimal">
<rng:param name="totalDigits">19</rng:param>
<rng:param name="fractionDigits">2</rng:param>
</rng:data>
All numeric types support the 'range' restriction, which is handled All numeric types support the 'range' restriction, which is handled
in the following way: in the following way:
o If the range expression consists of a single range part, insert o If the range expression consists of a single range part, insert
the pair of RELAX NG facets the pair of RELAX NG facets
<rng:param name="minInclusive">...</rng:param> <rng:param name="minInclusive">...</rng:param>
and and
<rng:param name="maxInclusive">...</rng:param> <rng:param name="maxInclusive">...</rng:param>
skipping to change at page 65, line 41 skipping to change at page 69, line 22
corresponding grouping must be looked up and its contents is inserted corresponding grouping must be looked up and its contents is inserted
as children of PARENT. See Section 8.2.1 for further details and an as children of PARENT. See Section 8.2.1 for further details and an
example. example.
10.58. The value Statement 10.58. The value Statement
This statement is ignored. This statement is ignored.
10.59. The when Statement 10.59. The when Statement
This statement is mapped to @nma:when attribute and ARGUMENT becomes This statement is mapped to @nma:when attribute and ARGUMENT,
it value. translated according to Section 8.3, becomes it value.
10.60. The yang-version Statement 10.60. The yang-version Statement
This statement is not mapped to the output schema. However, an This statement is not mapped to the output schema. However, an
implementation SHOULD check that it is compatible with the YANG implementation SHOULD check that it is compatible with the YANG
version declared by the statement (currently version 1). version declared by the statement (currently version 1).
10.61. The yin-element Statement 10.61. The yin-element Statement
This statement is not mapped to the output schema, but see the rules This statement is not mapped to the output schema, but see the rules
skipping to change at page 67, line 34 skipping to change at page 70, line 34
MUST be changed to <rng:notAllowed>. MUST be changed to <rng:notAllowed>.
o When generating Schematron or DSRL, the CONTELEM definition and o When generating Schematron or DSRL, the CONTELEM definition and
all its descendants in the conceptual tree schema MUST be ignored. all its descendants in the conceptual tree schema MUST be ignored.
11.2. The @nma:default Annotation 11.2. The @nma:default Annotation
This annotation is used for generating the DSRL schema as described This annotation is used for generating the DSRL schema as described
in Section 9.4. in Section 9.4.
11.3. The @nma:default-case Annotation 11.3. The @nma:implicit Annotation
This annotation is used for generating the DSRL schema as described This annotation is used for generating the DSRL schema as described
in Section 9.4. in Section 9.4.
11.4. The <nma:error-app-tag> Annotation 11.4. The <nma:error-app-tag> Annotation
This annotation currently has no mapping defined. This annotation currently has no mapping defined.
11.5. The <nma:error-message> Annotation 11.5. The <nma:error-message> Annotation
skipping to change at page 68, line 32 skipping to change at page 71, line 32
</sch:report> </sch:report>
where CONDITION has this form: where CONDITION has this form:
preceding-sibling::CONTELEM[C_1 and C_2 and ... and C_n] preceding-sibling::CONTELEM[C_1 and C_2 and ... and C_n]
Each C_i, for i=1,2,...,n, specifies the condition for violation of Each C_i, for i=1,2,...,n, specifies the condition for violation of
uniqueness of key k_i, namely uniqueness of key k_i, namely
k_i=current()/k_i k_i=current()/k_i
11.8. The <nma:leafref> Annotation 11.8. The @nma:leafref Annotation
The mapping of this annotation depends on its @require-instance
attribute. If this attribute is not present or its value is "true",
the referred leaf must exist in the instance document (this is
verified by the RELAX NG schema) and the <nma:leafref> annotation is
mapped to the following assert:
<sch:assert test="PATH=..">
Leafref "CONTELEM" must have the same value as "PATH"
</sch:assert>
where PATH is the content of <nma:leafref>.
If the @require-instance attribute has the value "false", then the This annotation is mapped to the following assert:
equality in contents of the context element and the referred leaf is
required only if the referred leaf exists. Hence, <nma:leafref> is
mapped to the following assert:
<sch:assert test="not(PATH) or 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>
In both cases the assert is a descendant of the "ref-integrity" where PATH is the value of @nma:leafref. The assert is a descendant
pattern, which means that it will be used only for the "full" of the "ref-integrity" pattern, which means that it will be used only
validation phase. for the "full" validation phase.
11.9. The @nma:min-elements Annotation 11.9. The @nma:min-elements Annotation
This annotation is mapped to the following Schematron assert: This annotation is mapped to the following Schematron assert:
<sch:assert test="count(../CONTELEM)&gt;=MIN"> <sch:assert test="count(../CONTELEM)&gt;=MIN">
List "CONTELEM" - item count must be at least MIN List "CONTELEM" - item count must be at least MIN
</sch:assert> </sch:assert>
where MIN is the value of @nma:min-elements. where MIN is the value of @nma:min-elements.
skipping to change at page 75, line 33 skipping to change at page 78, line 33
<define name="config-attribute"> <define name="config-attribute">
<attribute name="nma:config"> <attribute name="nma:config">
<data type="boolean"/> <data type="boolean"/>
</attribute> </attribute>
</define> </define>
<define name="default-attribute"> <define name="default-attribute">
<attribute name="nma:default"/> <attribute name="nma:default"/>
</define> </define>
<define name="default-case-attribute"> <define name="implicit-attribute">
<attribute name="nma:default-case"> <attribute name="nma:implicit">
<data type="boolean"/> <data type="boolean"/>
</attribute> </attribute>
</define> </define>
<define name="error-app-tag-element"> <define name="error-app-tag-element">
<optional> <optional>
<element name="nma:error-app-tag"> <element name="nma:error-app-tag">
<text/> <text/>
</element> </element>
</optional> </optional>
skipping to change at page 76, line 24 skipping to change at page 79, line 24
</define> </define>
<define name="key-attribute"> <define name="key-attribute">
<attribute name="nma:key"> <attribute name="nma:key">
<list> <list>
<data type="QName"/> <data type="QName"/>
</list> </list>
</attribute> </attribute>
</define> </define>
<define name="leafref-element"> <define name="leafref-attribute">
<element name="nma:leafref"> <attribute name="nma:leafref">
<optional>
<attribute name="nma:require-instance">
<data type="boolean"/>
</attribute>
</optional>
<data type="string"/> <data type="string"/>
</element> </element>
</define> </define>
<define name="min-elements-attribute"> <define name="min-elements-attribute">
<attribute name="nma:min-elements"> <attribute name="nma:min-elements">
<data type="integer"/> <data type="integer"/>
</attribute> </attribute>
</define> </define>
skipping to change at page 78, line 16 skipping to change at page 81, line 11
</define> </define>
</grammar> </grammar>
A.2. Compact Syntax A.2. Compact Syntax
namespace nma = "urn:ietf:params:xml:ns:netmod:dsdl-annotations:1" namespace nma = "urn:ietf:params:xml:ns:netmod:dsdl-annotations:1"
config-attribute = attribute nma:config { xsd:boolean } config-attribute = attribute nma:config { xsd:boolean }
default-attribute = attribute nma:default { text } default-attribute = attribute nma:default { text }
default-case-attribute = attribute nma:default-case { xsd:boolean } implicit-attribute = attribute nma:implicit { xsd:boolean }
error-app-tag-element = element nma:error-app-tag { text }? error-app-tag-element = element nma:error-app-tag { text }?
error-message-element = element nma:error-message { text }? error-message-element = element nma:error-message { text }?
instance-identifier-element = instance-identifier-element =
element nma:instance-identifier { element nma:instance-identifier {
attribute nma:require-instance { xsd:boolean }? attribute nma:require-instance { xsd:boolean }?
} }
key-attribute = key-attribute =
attribute nma:key { attribute nma:key {
list { xsd:QName } list { xsd:QName }
} }
leafref-element = leafref-element =
element nma:leafref { attribute nma:leafref {
attribute nma:require-instance { xsd:boolean }?,
xsd:string xsd:string
} }
min-elements-attribute = attribute nma:min-elements { xsd:integer } min-elements-attribute = attribute nma:min-elements { xsd:integer }
max-elements-attribute = attribute nma:max-elements { xsd:integer } max-elements-attribute = attribute nma:max-elements { xsd:integer }
must-element = must-element =
element nma:must { element nma:must {
attribute nma:assert { xsd:string }, attribute nma:assert { xsd:string },
(err-app-tag-element & err-message-element) (err-app-tag-element & err-message-element)
} }
ordered-by-attribute = attribute nma:ordered-by { "user" | "system" } ordered-by-attribute = attribute nma:ordered-by { "user" | "system" }
skipping to change at page 82, line 7 skipping to change at page 85, line 7
"configuration and operational parameters for a DHCP server."; "configuration and operational parameters for a DHCP server.";
leaf max-lease-time { leaf max-lease-time {
type uint32; type uint32;
units seconds; units seconds;
default 7200; default 7200;
} }
leaf default-lease-time { leaf default-lease-time {
type uint32; type uint32;
units seconds; units seconds;
must '. <= ../dhcp:max-lease-time' { must '. <= ../max-lease-time' {
error-message error-message
"The default-lease-time must be less than max-lease-time"; "The default-lease-time must be less than max-lease-time";
} }
default 600; default 600;
} }
uses subnet-list; uses subnet-list;
container shared-networks { container shared-networks {
list shared-network { list shared-network {
skipping to change at page 84, line 20 skipping to change at page 87, line 20
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<grammar <grammar
xmlns="http://relaxng.org/ns/structure/1.0" xmlns="http://relaxng.org/ns/structure/1.0"
xmlns:a="http://relaxng.org/ns/compatibility/annotations/1.0" xmlns:a="http://relaxng.org/ns/compatibility/annotations/1.0"
xmlns:dc="http://purl.org/dc/terms" xmlns:dc="http://purl.org/dc/terms"
xmlns:dhcp="http://example.com/ns/dhcp" xmlns:dhcp="http://example.com/ns/dhcp"
xmlns:nma="urn:ietf:params:xml:ns:netmod:dsdl-annotations:1" xmlns:nma="urn:ietf:params:xml:ns:netmod:dsdl-annotations:1"
xmlns:nmt="urn:ietf:params:xml:ns:netmod:conceptual-tree:1" xmlns:nmt="urn:ietf:params:xml:ns:netmod:conceptual-tree:1"
datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes"> datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes">
<dc:creator>Pyang 0.9.3, RELAX NG plugin</dc:creator> <dc:creator>Pyang 0.9.3, CTS plugin</dc:creator>
<dc:source>YANG module 'dhcp'</dc:source> <dc:source>YANG module 'dhcp'</dc:source>
<start> <start>
<element name="nmt:netmod-tree"> <element name="nmt:netmod-tree">
<element name="nmt:top"> <element name="nmt:top">
<interleave> <interleave>
<optional> <optional>
<element name="dhcp:dhcp"> <element name="dhcp:dhcp" nma:implicit="true">
<interleave>
<a:documentation> <a:documentation>
configuration and operational parameters for a DHCP server. configuration and operational parameters for a DHCP server
</a:documentation> </a:documentation>
<optional> <optional>
<element name="dhcp:max-lease-time" <element name="dhcp:max-lease-time"
nma:default="7200" nma:units="seconds"> nma:default="7200" nma:units="seconds">
<data type="unsignedInt"/> <data type="unsignedInt"/>
</element> </element>
</optional> </optional>
<optional> <optional>
<element name="dhcp:default-lease-time" <element name="dhcp:default-lease-time"
nma:default="600" nma:units="seconds"> nma:default="600" nma:units="seconds">
<data type="unsignedInt"/> <data type="unsignedInt"/>
<nma:must <nma:must assert=". &lt;= ../dhcp:max-lease-time">
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>
</element> </element>
</optional> </optional>
<ref name="_dhcp__subnet-list"/> <ref name="_dhcp__subnet-list"/>
<optional> <optional>
<element name="dhcp:shared-networks"> <element name="dhcp:shared-networks">
<interleave>
<zeroOrMore> <zeroOrMore>
<element name="dhcp:shared-network" <element name="dhcp:shared-network"
nma:key="dhcp:name"> nma:key="dhcp:name">
<element name="dhcp:name"> <element name="dhcp:name">
<data type="string"/> <data type="string"/>
</element> </element>
<interleave>
<ref name="_dhcp__subnet-list"/> <ref name="_dhcp__subnet-list"/>
</interleave>
</element> </element>
</zeroOrMore> </zeroOrMore>
</interleave>
</element> </element>
</optional> </optional>
<optional> <optional>
<element name="dhcp:status" nma:config="false"> <element name="dhcp:status" nma:config="false">
<interleave>
<zeroOrMore> <zeroOrMore>
<element name="dhcp:leases" <element name="dhcp:leases"
nma:key="dhcp:address"> nma:key="dhcp:address">
<element name="dhcp:address"> <element name="dhcp:address">
<ref name="inet-types__ip-address"/> <ref name="ietf-inet-types__ip-address"/>
</element> </element>
<interleave>
<optional> <optional>
<element name="dhcp:starts"> <element name="dhcp:starts">
<ref name="yang-types__date-and-time"/> <ref name="ietf-yang-types__date-and-time"/>
</element> </element>
</optional> </optional>
<optional> <optional>
<element name="dhcp:ends"> <element name="dhcp:ends">
<ref name="yang-types__date-and-time"/> <ref name="ietf-yang-types__date-and-time"/>
</element> </element>
</optional> </optional>
<optional> <optional>
<element name="dhcp:hardware"> <element name="dhcp:hardware">
<interleave>
<optional> <optional>
<element name="dhcp:type"> <element name="dhcp:type">
<choice> <choice>
<value>ethernet</value> <value>ethernet</value>
<value>token-ring</value> <value>token-ring</value>
<value>fddi</value> <value>fddi</value>
</choice> </choice>
</element> </element>
</optional> </optional>
<optional> <optional>
<element name="dhcp:address"> <element name="dhcp:address">
<ref name="yang-types__phys-address"/> <ref name="ietf-yang-types__phys-address"/>
</element> </element>
</optional> </optional>
</interleave>
</element> </element>
</optional> </optional>
</interleave>
</element> </element>
</zeroOrMore> </zeroOrMore>
</interleave>
</element> </element>
</optional> </optional>
</interleave>
</element> </element>
</optional> </optional>
</interleave> </interleave>
</element> </element>
<element name="nmt:rpc-methods"> <element name="nmt:rpc-methods">
<empty/> <empty/>
</element> </element>
<element name="nmt:notifications"> <element name="nmt:notifications">
<empty/> <empty/>
</element> </element>
</element> </element>
</start> </start>
<define name="_dhcp__subnet-list"> <define name="_dhcp__subnet-list">
<interleave>
<a:documentation>A reusable list of subnets</a:documentation> <a:documentation>A reusable list of subnets</a:documentation>
<zeroOrMore> <zeroOrMore>
<element name="dhcp:subnet" nma:key="dhcp:net"> <element name="dhcp:subnet" nma:key="dhcp:net">
<element name="dhcp:net"> <element name="dhcp:net">
<ref name="inet-types__ip-prefix"/> <ref name="ietf-inet-types__ip-prefix"/>
</element> </element>
<interleave>
<optional> <optional>
<element name="dhcp:range"> <element name="dhcp:range">
<interleave>
<optional> <optional>
<element name="dhcp:dynamic-bootp"> <element name="dhcp:dynamic-bootp">
<a:documentation> <a:documentation>
Allows BOOTP clients to get addresses in this range Allows BOOTP clients to get addresses in this range
</a:documentation> </a:documentation>
<empty/> <empty/>
</element> </element>
</optional> </optional>
<element name="dhcp:low"> <element name="dhcp:low">
<ref name="inet-types__ip-address"/> <ref name="ietf-inet-types__ip-address"/>
</element> </element>
<element name="dhcp:high"> <element name="dhcp:high">
<ref name="inet-types__ip-address"/> <ref name="ietf-inet-types__ip-address"/>
</element> </element>
</interleave>
</element> </element>
</optional> </optional>
<optional> <optional>
<element name="dhcp:dhcp-options"> <element name="dhcp:dhcp-options">
<interleave>
<a:documentation> <a:documentation>
Options in the DHCP protocol Options in the DHCP protocol
</a:documentation> </a:documentation>
<zeroOrMore> <zeroOrMore>
<element name="dhcp:router" nma:ordered-by="user"> <element name="dhcp:router" nma:ordered-by="user">
<a:documentation> <a:documentation>
See: RFC 2132, sec. 3.8 See: RFC 2132, sec. 3.8
</a:documentation> </a:documentation>
<ref name="inet-types__host"/> <ref name="ietf-inet-types__host"/>
</element> </element>
</zeroOrMore> </zeroOrMore>
<optional> <optional>
<element name="dhcp:domain-name"> <element name="dhcp:domain-name">
<a:documentation> <a:documentation>
See: RFC 2132, sec. 3.17 See: RFC 2132, sec. 3.17
</a:documentation> </a:documentation>
<ref name="inet-types__domain-name"/> <ref name="ietf-inet-types__domain-name"/>
</element> </element>
</optional> </optional>
</interleave>
</element> </element>
</optional> </optional>
<optional> <optional>
<element name="dhcp:max-lease-time" <element name="dhcp:max-lease-time"
nma:default="7200" nma:units="seconds"> nma:default="7200" nma:units="seconds">
<data type="unsignedInt"/> <data type="unsignedInt"/>
</element> </element>
</optional> </optional>
</interleave>
</element> </element>
</zeroOrMore> </zeroOrMore>
</interleave>
</define> </define>
<define name="inet-types__ip-prefix"> <define name="ietf-inet-types__ip-prefix">
<choice> <choice>
<ref name="inet-types__ipv4-prefix"/> <ref name="ietf-inet-types__ipv4-prefix"/>
<ref name="inet-types__ipv6-prefix"/> <ref name="ietf-inet-types__ipv6-prefix"/>
</choice> </choice>
</define> </define>
<define name="inet-types__ipv4-prefix"> <define name="ietf-inet-types__ipv4-prefix">
<data type="string"> <data type="string">
<param name="pattern">... regex pattern ...</param> <param name="pattern">... regex pattern ...</param>
</data> </data>
</define> </define>
<define name="inet-types__ipv6-prefix"> <define name="ietf-inet-types__ipv6-prefix">
<data type="string"> <data type="string">
<param name="pattern">... regex pattern ...</param> <param name="pattern">... regex pattern ...</param>
<param name="pattern">... regex pattern ...</param>
</data> </data>
</define> </define>
<define name="inet-types__ip-address"> <define name="ietf-inet-types__ip-address">
<choice> <choice>
<ref name="inet-types__ipv4-address"/> <ref name="ietf-inet-types__ipv4-address"/>
<ref name="inet-types__ipv6-address"/> <ref name="ietf-inet-types__ipv6-address"/>
</choice> </choice>
</define> </define>
<define name="inet-types__ipv4-address"> <define name="ietf-inet-types__ipv4-address">
<data type="string"> <data type="string">
<param name="pattern">... regex pattern ...</param> <param name="pattern">... regex pattern ...</param>
</data> </data>
</define> </define>
<define name="inet-types__ipv6-address"> <define name="ietf-inet-types__ipv6-address">
<data type="string"> <data type="string">
<param name="pattern">... regex pattern ...</param> <param name="pattern">... regex pattern ...</param>
<param name="pattern">... regex pattern ...</param>
</data> </data>
</define> </define>
<define name="inet-types__host"> <define name="ietf-inet-types__host">
<choice> <choice>
<ref name="inet-types__ip-address"/> <ref name="ietf-inet-types__ip-address"/>
<ref name="inet-types__domain-name"/> <ref name="ietf-inet-types__domain-name"/>
</choice> </choice>
</define> </define>
<define name="inet-types__domain-name"> <define name="ietf-inet-types__domain-name">
<data type="string"> <data type="string">
<param name="pattern">... regex pattern ...</param> <param name="minLength">1</param>
<param name="maxLength">253</param>
<param name="pattern">... regex pattern ...</param> <param name="pattern">... regex pattern ...</param>
</data> </data>
</define> </define>
<define name="yang-types__date-and-time"> <define name="ietf-yang-types__date-and-time">
<data type="string"> <data type="string">
<param name="pattern">... regex pattern ...</param> <param name="pattern">... regex pattern ...</param>
</data> </data>
</define> </define>
<define name="yang-types__phys-address"> <define name="ietf-yang-types__phys-address">
<data type="string"/> <data type="string">
<param name="pattern">
([0-9a0-fA-F]{2}(:[0-9a0-fA-F]{2})*)?
</param>
</data>
</define> </define>
</grammar> </grammar>
C.2.2. Compact Syntax C.2.2. Compact Syntax
namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0" namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0"
namespace dc = "http://purl.org/dc/terms" namespace dc = "http://purl.org/dc/terms"
namespace dhcp = "http://example.com/ns/dhcp" namespace dhcp = "http://example.com/ns/dhcp"
namespace nma = "urn:ietf:params:xml:ns:netmod:dsdl-annotations:1" namespace nma = "urn:ietf:params:xml:ns:netmod:dsdl-annotations:1"
namespace nmt = "urn:ietf:params:xml:ns:netmod:conceptual-tree:1" namespace nmt = "urn:ietf:params:xml:ns:netmod:conceptual-tree:1"
dc:creator [ "Pyang 0.9.3, RELAX NG plugin" ] dc:creator [ "Pyang 0.9.3, CTS plugin" ]
dc:source [ "YANG module 'dhcp'" ] dc:source [ "YANG module 'dhcp'" ]
start = start =
element nmt:netmod-tree { element nmt:netmod-tree {
element nmt:top { element nmt:top {
[ nma:implicit = "true" ]
## configuration and operational parameters for a DHCP server.
element dhcp:dhcp { element dhcp:dhcp {
[ nma:default = "7200" nma:units = "seconds" ]
element dhcp:max-lease-time { xsd:unsignedInt }?, ##
[ nma:default = "600" nma:units = "seconds" ] ## configuration and operational parameters for a DHCP server
##
([ nma:default = "7200" nma:units = "seconds" ]
element dhcp:max-lease-time { xsd:unsignedInt }?
& [ nma:default = "600" nma:units = "seconds" ]
element dhcp:default-lease-time { element dhcp:default-lease-time {
xsd:unsignedInt xsd:unsignedInt
>> nma:must [ >> nma:must [
assert = ". <= ../dhcp:max-lease-time" assert = ". <= ../dhcp:max-lease-time"
nma:error-message [ nma:error-message [
"The default-lease-time must be less than max-lease-time" "\x{a}" ~
"The default-lease-time must be less than max-lease-time." ~
"\x{a}"
] ]
] ]
}?, }?
_dhcp__subnet-list, & _dhcp__subnet-list
element dhcp:shared-networks { & element dhcp:shared-networks {
[ nma:key = "dhcp:name" ] [ nma:key = "dhcp:name" ]
element dhcp:shared-network { element dhcp:shared-network {
element dhcp:name { xsd:string }, element dhcp:name { xsd:string },
_dhcp__subnet-list (_dhcp__subnet-list)
}* }*
}?, }?
[ nma:config = "false" ] & [ nma:config = "false" ]
element dhcp:status { element dhcp:status {
[ nma:key = "dhcp:address" ] [ nma:key = "dhcp:address" ]
element dhcp:leases { element dhcp:leases {
element dhcp:address { inet-types__ip-address }, element dhcp:address { ietf-inet-types__ip-address },
element dhcp:starts { yang-types__date-and-time }?, (element dhcp:starts { ietf-yang-types__date-and-time }?
element dhcp:ends { yang-types__date-and-time }?, & element dhcp:ends { ietf-yang-types__date-and-time }?
element dhcp:hardware { & element dhcp:hardware {
element dhcp:type { "ethernet" element dhcp:type {
| "token-ring" "ethernet" | "token-ring" | "fddi"
| "fddi"
}?,
element dhcp:address { yang-types__phys-address }?
}? }?
}* & element dhcp:address {
ietf-yang-types__phys-address
}? }?
}?)
}*
}?)
}? }?
}, },
element nmt:rpc-methods { empty }, element nmt:rpc-methods { empty },
element nmt:notifications { empty } element nmt:notifications { empty }
} }
_dhcp__subnet-list =
## A reusable list of subnets ## A reusable list of subnets
_dhcp__subnet-list = ([ nma:key = "dhcp:net" ]
[ nma:key = "dhcp:net" ]
element dhcp:subnet { element dhcp:subnet {
element dhcp:net { inet-types__ip-prefix }, element dhcp:net { ietf-inet-types__ip-prefix },
element dhcp:range { (element dhcp:range {
##
## Allows BOOTP clients to get addresses in this range ## Allows BOOTP clients to get addresses in this range
element dhcp:dynamic-bootp { empty }?, ##
element dhcp:low { inet-types__ip-address }, element dhcp:dynamic-bootp { empty }?
element dhcp:high { inet-types__ip-address } & element dhcp:low { ietf-inet-types__ip-address }
}?, & element dhcp:high { ietf-inet-types__ip-address }
}?
& element dhcp:dhcp-options {
##
## Options in the DHCP protocol ## Options in the DHCP protocol
element dhcp:dhcp-options { ##
(
##
## See: RFC 2132, sec. 3.8 ## See: RFC 2132, sec. 3.8
##
[ nma:ordered-by = "user" ] [ nma:ordered-by = "user" ]
element dhcp:router { inet-types__host }*, element dhcp:router { ietf-inet-types__host }*
&
##
## See: RFC 2132, sec. 3.17 ## See: RFC 2132, sec. 3.17
element dhcp:domain-name { inet-types__domain-name }? ##
}?, element dhcp:domain-name { ietf-inet-types__domain-name }?)
[ nma:default = "7200" nma:units = "seconds" ] }?
element dhcp:max-lease-time { xsd:unsignedInt }? & [ nma:default = "7200" nma:units = "seconds" ]
}* element dhcp:max-lease-time { xsd:unsignedInt }?)
inet-types__ip-prefix = }*)
inet-types__ipv4-prefix | inet-types__ipv6-prefix ietf-inet-types__ip-prefix =
inet-types__ipv4-prefix = ietf-inet-types__ipv4-prefix | ietf-inet-types__ipv6-prefix
xsd:string { ietf-inet-types__ipv4-prefix =
pattern = xsd:string { pattern = "... regex pattern ..." }
"(([0-1]?[0-9]?[0-9]|2[0-4][0-9]|25[0-5])\.)" ~ ietf-inet-types__ipv6-prefix =
"{3}([0-1]?[0-9]?[0-9]|2[0-4][0-9]|25[0-5])/\p{N}+"
}
inet-types__ipv6-prefix =
xsd:string {
pattern =
"((([0-9a-fA-F]{1,4}:){7})([0-9a-fA-F]{1,4})/" ~
"\p{N}+)|((([0-9a-fA-F]{1,4}:){6})(([0-9]{1,3}\." ~
"[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}))/\p{N}+)|" ~
"((([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*(::)" ~
"(([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*/\p{N}+)" ~
"((([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*(::)" ~
"(([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*(([0-9]" ~
"{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}))/\p{N}+)"
}
inet-types__ip-address =
inet-types__ipv4-address | inet-types__ipv6-address
inet-types__ipv4-address =
xsd:string { xsd:string {
pattern = pattern = "... regex pattern ..."
"(([0-1]?[0-9]?[0-9]|2[0-4][0-9]|25[0-5])\.){3}([0-1]?" ~ pattern = "... regex pattern ..."
"[0-9]?[0-9]|2[0-4][0-9]|25[0-5])(%[\p{N}\p{L}]+)?"
} }
inet-types__ipv6-address = ietf-inet-types__ip-address =
ietf-inet-types__ipv4-address | ietf-inet-types__ipv6-address
ietf-inet-types__ipv4-address =
xsd:string { pattern = "... regex pattern ..." }
ietf-inet-types__ipv6-address =
xsd:string { xsd:string {
pattern = pattern = "... regex pattern ..."
"((([0-9a-fA-F]{1,4}:){7})([0-9a-fA-F]{1,4})(%[\p{N}" ~ pattern = "... regex pattern ..."
"\p{L}]+)?)|((([0-9a-fA-F]{1,4}:){6})(([0-9]{1,3}\." ~
"[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}))(%[\p{N}\p{L}]+)?)|" ~
"((([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*(::)" ~
"(([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*(%[\p{N}" ~
"\p{L}]+)?)((([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*" ~
"(::)(([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*(([0-9]{1,3}" ~
"\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}))(%[\p{N}\p{L}]+)?)"
} }
inet-types__host = inet-types__ip-address | inet-types__domain-name ietf-inet-types__host =
inet-types__domain-name = ietf-inet-types__ip-address | ietf-inet-types__domain-name
ietf-inet-types__domain-name =
xsd:string { xsd:string {
pattern = minLength = "1"
"([a-zA-Z][a-zA-Z0-9\-]*[a-zA-Z0-9]\.)*" ~ maxLength = "253"
"[a-zA-Z][a-zA-Z0-9\-]*[a-zA-Z0-9]" pattern = "... regex pattern ..."
pattern =
"([r-zA-Z][a-zA-Z0-9\-]*[a-zA-Z0-9]\.)*" ~
"[a-zA-Z][a-zA-Z0-9\-]*[a-zA-Z0-9]"
} }
yang-types__date-and-time = ietf-yang-types__date-and-time =
xsd:string { pattern = "... regex pattern ..." }
ietf-yang-types__phys-address =
xsd:string { xsd:string {
pattern = pattern = "([0-9a0-fA-F]{2}(:[0-9a0-fA-F]{2})*)?"
"\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}" ~
"(\.d*)?(Z|(\+|-)\d{2}:\d{2})"
} }
yang-types__phys-address = xsd:string
C.3. Final DSDL Schemas C.3. Final DSDL Schemas
This appendix contains DSDL schemas that were obtained from the This appendix contains DSDL schemas that were obtained from the
conceptual tree schema in Appendix C.2 by XSL transformations. These conceptual tree schema in Appendix C.2 by XSL transformations. These
schemas can be directly used for validating a reply to unfiltered schemas can be directly used for validating a reply to unfiltered
<get> with the contents corresponding to the DHCP data model. <get> with the contents corresponding to the DHCP data model.
The RELAX NG schema (again shown in both XML and compact syntax) The RELAX NG schema (again shown in both XML and compact syntax)
includes the schema independent library from Appendix B. includes the schema independent library from Appendix B.
skipping to change at page 92, line 6 skipping to change at page 95, line 21
<?xml version="1.0" encoding="utf-8"?> <?xml version="1.0" encoding="utf-8"?>
<grammar <grammar
xmlns="http://relaxng.org/ns/structure/1.0" xmlns="http://relaxng.org/ns/structure/1.0"
xmlns:a="http://relaxng.org/ns/compatibility/annotations/1.0" xmlns:a="http://relaxng.org/ns/compatibility/annotations/1.0"
xmlns:dc="http://purl.org/dc/terms" xmlns:dc="http://purl.org/dc/terms"
xmlns:dhcp="http://example.com/ns/dhcp" xmlns:dhcp="http://example.com/ns/dhcp"
xmlns:nma="urn:ietf:params:xml:ns:netmod:dsdl-annotations:1" xmlns:nma="urn:ietf:params:xml:ns:netmod:dsdl-annotations:1"
xmlns:nmt="urn:ietf:params:xml:ns:netmod:conceptual-tree:1" xmlns:nmt="urn:ietf:params:xml:ns:netmod:conceptual-tree:1"
datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes" datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes"
ns="urn:ietf:params:xml:ns:netconf:base:1.0"> ns="urn:ietf:params:xml:ns:netconf:base:1.0">
<rng:include xmlns:rng="http://relaxng.org/ns/structure/1.0" <include href="relaxng-lib.rng"/>
href="./relaxng-lib.rng"/>
<start> <start>
<rng:element xmlns:rng="http://relaxng.org/ns/structure/1.0" <element name="rpc-reply">
name="rpc-reply"> <ref name="message-id-attribute"/>
<rng:ref name="message-id-attribute"/> <element name="data">
<rng:element name="data">
<interleave> <interleave>
<optional> <optional>
<element name="dhcp:dhcp"> <element name="dhcp:dhcp">
<interleave>
<optional> <optional>
<element name="dhcp:max-lease-time"> <element name="dhcp:max-lease-time">
<data type="unsignedInt"/> <data type="unsignedInt"/>
</element> </element>
</optional> </optional>
<optional> <optional>
<element name="dhcp:default-lease-time"> <element name="dhcp:default-lease-time">
<data type="unsignedInt"/> <data type="unsignedInt"/>
</element> </element>
</optional> </optional>
<ref name="_dhcp__subnet-list"/> <ref name="_dhcp__subnet-list"/>
<optional> <optional>
<element name="dhcp:shared-networks"> <element name="dhcp:shared-networks">
<interleave>
<zeroOrMore> <zeroOrMore>
<element name="dhcp:shared-network"> <element name="dhcp:shared-network">
<element name="dhcp:name"> <element name="dhcp:name">
<data type="string"/> <data type="string"/>
</element> </element>
<interleave>
<ref name="_dhcp__subnet-list"/> <ref name="_dhcp__subnet-list"/>
</interleave>
</element> </element>
</zeroOrMore> </zeroOrMore>
</interleave>
</element> </element>
</optional> </optional>
<optional> <optional>
<element name="dhcp:status"> <element name="dhcp:status">
<interleave>
<zeroOrMore> <zeroOrMore>
<element name="dhcp:leases"> <element name="dhcp:leases">
<element name="dhcp:address"> <element name="dhcp:address">
<ref name="inet-types__ip-address"/> <ref name="ietf-inet-types__ip-address"/>
</element> </element>
<interleave>
<optional> <optional>
<element name="dhcp:starts"> <element name="dhcp:starts">
<ref name="yang-types__date-and-time"/> <ref name="ietf-yang-types__date-and-time"/>
</element> </element>
</optional> </optional>
<optional> <optional>
<element name="dhcp:ends"> <element name="dhcp:ends">
<ref name="yang-types__date-and-time"/> <ref name="ietf-yang-types__date-and-time"/>
</element> </element>
</optional> </optional>
<optional> <optional>
<element name="dhcp:hardware"> <element name="dhcp:hardware">
<interleave>
<optional> <optional>
<element name="dhcp:type"> <element name="dhcp:type">
<choice> <choice>
<value>ethernet</value> <value>ethernet</value>
<value>token-ring</value> <value>token-ring</value>
<value>fddi</value> <value>fddi</value>
</choice> </choice>
</element> </element>
</optional> </optional>
<optional> <optional>
<element name="dhcp:address"> <element name="dhcp:address">
<ref name="yang-types__phys-address"/> <ref name="ietf-yang-types__phys-address"/>
</element> </element>
</optional> </optional>
</interleave>
</element> </element>
</optional> </optional>
</interleave>
</element> </element>
</zeroOrMore> </zeroOrMore>
</interleave>
</element> </element>
</optional> </optional>
</interleave>
</element> </element>
</optional> </optional>
</interleave> </interleave>
</rng:element> </element>
</rng:element> </element>
</start> </start>
<define name="_dhcp__subnet-list"> <define name="_dhcp__subnet-list">
<interleave>
<zeroOrMore> <zeroOrMore>
<element name="dhcp:subnet"> <element name="dhcp:subnet">
<element name="dhcp:net"> <element name="dhcp:net">
<ref name="inet-types__ip-prefix"/> <ref name="ietf-inet-types__ip-prefix"/>
</element> </element>
<interleave>
<optional> <optional>
<element name="dhcp:range"> <element name="dhcp:range">
<interleave>
<optional> <optional>
<element name="dhcp:dynamic-bootp"> <element name="dhcp:dynamic-bootp">
<empty/> <empty/>
</element> </element>
</optional> </optional>
<element name="dhcp:low"> <element name="dhcp:low">
<ref name="inet-types__ip-address"/> <ref name="ietf-inet-types__ip-address"/>
</element> </element>
<element name="dhcp:high"> <element name="dhcp:high">
<ref name="inet-types__ip-address"/> <ref name="ietf-inet-types__ip-address"/>
</element> </element>
</interleave>
</element> </element>
</optional> </optional>
<optional> <optional>
<element name="dhcp:dhcp-options"> <element name="dhcp:dhcp-options">
<interleave>
<zeroOrMore> <zeroOrMore>
<element name="dhcp:router"> <element name="dhcp:router">
<ref name="inet-types__host"/> <ref name="ietf-inet-types__host"/>
</element> </element>
</zeroOrMore> </zeroOrMore>
<optional> <optional>
<element name="dhcp:domain-name"> <element name="dhcp:domain-name">
<ref name="inet-types__domain-name"/> <ref name="ietf-inet-types__domain-name"/>
</element> </element>
</optional> </optional>
</interleave>
</element> </element>
</optional> </optional>
<optional> <optional>
<element name="dhcp:max-lease-time"> <element name="dhcp:max-lease-time">
<data type="unsignedInt"/> <data type="unsignedInt"/>
</element> </element>
</optional> </optional>
</interleave>
</element> </element>
</zeroOrMore> </zeroOrMore>
</interleave>
</define> </define>
<define name="inet-types__ip-prefix"> <define name="ietf-inet-types__ip-prefix">
<choice> <choice>
<ref name="inet-types__ipv4-prefix"/> <ref name="ietf-inet-types__ipv4-prefix"/>
<ref name="inet-types__ipv6-prefix"/> <ref name="ietf-inet-types__ipv6-prefix"/>
</choice> </choice>
</define> </define>
<define name="inet-types__ipv4-prefix"> <define name="ietf-inet-types__ipv4-prefix">
<data type="string"> <data type="string">
<param name="pattern">... regex pattern ...</param> <param name="pattern">... regex pattern ...</param>
</data> </data>
</define> </define>
<define name="inet-types__ipv6-prefix"> <define name="ietf-inet-types__ipv6-prefix">
<data type="string"> <data type="string">
<param name="pattern">... regex pattern ...</param> <param name="pattern">... regex pattern ...</param>
<param name="pattern">... regex pattern ...</param>
</data> </data>
</define> </define>
<define name="inet-types__ip-address"> <define name="ietf-inet-types__ip-address">
<choice> <choice>
<ref name="inet-types__ipv4-address"/> <ref name="ietf-inet-types__ipv4-address"/>
<ref name="inet-types__ipv6-address"/> <ref name="ietf-inet-types__ipv6-address"/>
</choice> </choice>
</define> </define>
<define name="inet-types__ipv4-address"> <define name="ietf-inet-types__ipv4-address">
<data type="string"> <data type="string">
<param name="pattern">... regex pattern ...</param> <param name="pattern">... regex pattern ...</param>
</data> </data>
</define> </define>
<define name="inet-types__ipv6-address"> <define name="ietf-inet-types__ipv6-address">
<data type="string"> <data type="string">
<param name="pattern">... regex pattern ...</param> <param name="pattern">... regex pattern ...</param>
<param name="pattern">... regex pattern ...</param>
</data> </data>
</define> </define>
<define name="inet-types__host"> <define name="ietf-inet-types__host">
<choice> <choice>
<ref name="inet-types__ip-address"/> <ref name="ietf-inet-types__ip-address"/>
<ref name="inet-types__domain-name"/> <ref name="ietf-inet-types__domain-name"/>
</choice> </choice>
</define> </define>
<define name="inet-types__domain-name"> <define name="ietf-inet-types__domain-name">
<data type="string"> <data type="string">
<param name="pattern">... regex pattern ...</param> <param name="minLength">1</param>
<param name="maxLength">253</param>
<param name="pattern">... regex pattern ...</param> <param name="pattern">... regex pattern ...</param>
</data> </data>
</define> </define>
<define name="yang-types__date-and-time"> <define name="ietf-yang-types__date-and-time">
<data type="string"> <data type="string">
<param name="pattern">... regex pattern ...</param> <param name="pattern">... regex pattern ...</param>
</data> </data>
</define> </define>
<define name="yang-types__phys-address"> <define name="ietf-yang-types__phys-address">
<data type="string"/> <data type="string">
<param name="pattern">
([0-9a0-fA-F]{2}(:[0-9a0-fA-F]{2})*)?
</param>
</data>
</define> </define>
</grammar> </grammar>
C.3.2. RELAX NG Schema for <get> Reply - Compact Syntax C.3.2. RELAX NG Schema for <get> Reply - Compact Syntax
default namespace = "urn:ietf:params:xml:ns:netconf:base:1.0" default namespace = "urn:ietf:params:xml:ns:netconf:base:1.0"
namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0" namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0"
namespace dc = "http://purl.org/dc/terms" namespace dc = "http://purl.org/dc/terms"
namespace dhcp = "http://example.com/ns/dhcp" namespace dhcp = "http://example.com/ns/dhcp"
namespace nma = "urn:ietf:params:xml:ns:netmod:dsdl-annotations:1" namespace nma = "urn:ietf:params:xml:ns:netmod:dsdl-annotations:1"
namespace nmt = "urn:ietf:params:xml:ns:netmod:conceptual-tree:1" namespace nmt = "urn:ietf:params:xml:ns:netmod:conceptual-tree:1"
include "relaxng-lib.rnc" include "relaxng-lib.rnc"
start = start =
element rpc-reply { element rpc-reply {
message-id-attribute, message-id-attribute,
element data { element data {
element dhcp:dhcp { element dhcp:dhcp {
element dhcp:max-lease-time { xsd:unsignedInt }?, element dhcp:max-lease-time { xsd:unsignedInt }?
element dhcp:default-lease-time { xsd:unsignedInt }?, & element dhcp:default-lease-time { xsd:unsignedInt }?
_dhcp__subnet-list, & _dhcp__subnet-list
element dhcp:shared-networks { & element dhcp:shared-networks {
element dhcp:shared-network { element dhcp:shared-network {
element dhcp:name { xsd:string }, element dhcp:name { xsd:string },
_dhcp__subnet-list (_dhcp__subnet-list)
}* }*
}?, }?
element dhcp:status { & element dhcp:status {
element dhcp:leases { element dhcp:leases {
element dhcp:address { inet-types__ip-address }, element dhcp:address { ietf-inet-types__ip-address },
element dhcp:starts { yang-types__date-and-time }?, (element dhcp:starts { ietf-yang-types__date-and-time }?
element dhcp:ends { yang-types__date-and-time }?, & element dhcp:ends { ietf-yang-types__date-and-time }?
element dhcp:hardware { & element dhcp:hardware {
element dhcp:type { "ethernet" element dhcp:type {
| "token-ring" "ethernet" | "token-ring" | "fddi"
| "fddi"
}?,
element dhcp:address { yang-types__phys-address }?
}? }?
& element dhcp:address {
ietf-yang-types__phys-address
}?
}?)
}* }*
}? }?
}? }?
} }
} }
_dhcp__subnet-list = _dhcp__subnet-list =
element dhcp:subnet { element dhcp:subnet {
element dhcp:net { inet-types__ip-prefix }, element dhcp:net { ietf-inet-types__ip-prefix },
element dhcp:range { (element dhcp:range {
element dhcp:dynamic-bootp { empty }?, element dhcp:dynamic-bootp { empty }?
element dhcp:low { inet-types__ip-address }, & element dhcp:low { ietf-inet-types__ip-address }
element dhcp:high { inet-types__ip-address } & element dhcp:high { ietf-inet-types__ip-address }
}?, }?
element dhcp:dhcp-options { & element dhcp:dhcp-options {
element dhcp:router { inet-types__host }*, element dhcp:router { ietf-inet-types__host }*
element dhcp:domain-name { inet-types__domain-name }? & element dhcp:domain-name { ietf-inet-types__domain-name }?
}?, }?
element dhcp:max-lease-time { xsd:unsignedInt }? & element dhcp:max-lease-time { xsd:unsignedInt }?)
}* }*
inet-types__ip-prefix = ietf-inet-types__ip-prefix =
inet-types__ipv4-prefix | inet-types__ipv6-prefix ietf-inet-types__ipv4-prefix | ietf-inet-types__ipv6-prefix
inet-types__ipv4-prefix = ietf-inet-types__ipv4-prefix =
xsd:string { xsd:string { pattern = "... regex pattern ..." }
pattern = ietf-inet-types__ipv6-prefix =
"(([0-1]?[0-9]?[0-9]|2[0-4][0-9]|25[0-5])\.)" ~
"{3}([0-1]?[0-9]?[0-9]|2[0-4][0-9]|25[0-5])/\p{N}+"
}
inet-types__ipv6-prefix =
xsd:string {
pattern =
"((([0-9a-fA-F]{1,4}:){7})([0-9a-fA-F]{1,4})/" ~
"\p{N}+)|((([0-9a-fA-F]{1,4}:){6})(([0-9]{1,3}\." ~
"[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}))/\p{N}+)|" ~
"((([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*(::)" ~
"(([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*/\p{N}+)" ~
"((([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*(::)" ~
"(([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*(([0-9]" ~
"{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}))/\p{N}+)"
}
inet-types__ip-address =
inet-types__ipv4-address | inet-types__ipv6-address
inet-types__ipv4-address =
xsd:string { xsd:string {
pattern = pattern = "... regex pattern ..."
"(([0-1]?[0-9]?[0-9]|2[0-4][0-9]|25[0-5])\.){3}([0-1]?" ~ pattern = "... regex pattern ..."
"[0-9]?[0-9]|2[0-4][0-9]|25[0-5])(%[\p{N}\p{L}]+)?"
} }
inet-types__ipv6-address = ietf-inet-types__ip-address =
ietf-inet-types__ipv4-address | ietf-inet-types__ipv6-address
ietf-inet-types__ipv4-address =
xsd:string { pattern = "... regex pattern ..." }
ietf-inet-types__ipv6-address =
xsd:string { xsd:string {
pattern = pattern = "... regex pattern ..."
"((([0-9a-fA-F]{1,4}:){7})([0-9a-fA-F]{1,4})(%[\p{N}" ~ pattern = "... regex pattern ..."
"\p{L}]+)?)|((([0-9a-fA-F]{1,4}:){6})(([0-9]{1,3}\." ~
"[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}))(%[\p{N}\p{L}]+)?)|" ~
"((([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*(::)" ~
"(([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*(%[\p{N}" ~
"\p{L}]+)?)((([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*" ~
"(::)(([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*(([0-9]{1,3}" ~
"\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}))(%[\p{N}\p{L}]+)?)"
} }
inet-types__host = inet-types__ip-address | inet-types__domain-name ietf-inet-types__host =
inet-types__domain-name = ietf-inet-types__ip-address | ietf-inet-types__domain-name
ietf-inet-types__domain-name =
xsd:string { xsd:string {
pattern = minLength = "1"
"([a-zA-Z][a-zA-Z0-9\-]*[a-zA-Z0-9]\.)*" ~ maxLength = "253"
"[a-zA-Z][a-zA-Z0-9\-]*[a-zA-Z0-9]" pattern = "... regex pattern ..."
pattern =
"([r-zA-Z][a-zA-Z0-9\-]*[a-zA-Z0-9]\.)*" ~
"[a-zA-Z][a-zA-Z0-9\-]*[a-zA-Z0-9]"
} }
yang-types__date-and-time = ietf-yang-types__date-and-time =
xsd:string { pattern = "... regex pattern ..." }
ietf-yang-types__phys-address =
xsd:string { xsd:string {
pattern = pattern =
"\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}" ~ "\x{a}" ~
"(\.d*)?(Z|(\+|-)\d{2}:\d{2})" " ([0-9a0-fA-F]{2}(:[0-9a0-fA-F]{2})*)?\x{a}" ~
" "
} }
yang-types__phys-address = xsd:string
C.4. Schematron Schema for <get> Reply C.4. Schematron Schema for <get> Reply
<?xml version="1.0" encoding="utf-8"?> <?xml version="1.0" encoding="utf-8"?>
<sch:schema xmlns:sch="http://purl.oclc.org/dsdl/schematron"> <sch:schema xmlns:sch="http://purl.oclc.org/dsdl/schematron">
<sch:ns uri="http://example.com/ns/dhcp" prefix="dhcp"/> <sch:ns uri="http://example.com/ns/dhcp" prefix="dhcp"/>
<sch:ns uri="urn:ietf:params:xml:ns:netconf:base:1.0" <sch:ns uri="urn:ietf:params:xml:ns:netconf:base:1.0"
prefix="nc"/> prefix="nc"/>
<sch:phase id="full"> <sch:phase id="full">
<sch:active pattern="standard"/> <sch:active pattern="standard"/>
<sch:active pattern="ref-integrity"/> <sch:active pattern="ref-integrity"/>
</sch:phase> </sch:phase>
<sch:phase id="noref"> <sch:phase id="noref">
<sch:active pattern="standard"/> <sch:active pattern="standard"/>
</sch:phase> </sch:phase>
<sch:pattern id="standard"> <sch:pattern id="standard">
<sch:rule id="std-id2246197" abstract="true"> <sch:rule id="std-id2247270" abstract="true">
<sch:report test="preceding-sibling::dhcp:subnet <sch:report test="preceding-sibling::dhcp:subnet
[dhcp:net=current()/dhcp:net]"> [dhcp:net=current()/dhcp:net]">
Duplicate key of list dhcp:subnet Duplicate key of list dhcp:subnet
</sch:report> </sch:report>
</sch:rule> </sch:rule>
<sch:rule context="/nc:rpc-reply/nc:data/dhcp:dhcp/ <sch:rule context="/nc:rpc-reply/nc:data/dhcp:dhcp/
dhcp:default-lease-time"> dhcp:default-lease-time">
<sch:assert test=". &lt;= ../dhcp:max-lease-time"> <sch:assert test=". &lt;= ../dhcp:max-lease-time">
The default-lease-time must be less than max-lease-time The default-lease-time must be less than max-lease-time.
</sch:assert> </sch:assert>
</sch:rule> </sch:rule>
<sch:rule context="/nc:rpc-reply/nc:data/dhcp:dhcp/dhcp:subnet"> <sch:rule context="/nc:rpc-reply/nc:data/dhcp:dhcp/dhcp:subnet">
<sch:extends rule="std-id2246197"/> <sch:extends rule="std-id2247270"/>
</sch:rule> </sch:rule>
<sch:rule context="/nc:rpc-reply/nc:data/dhcp:dhcp/ <sch:rule context="/nc:rpc-reply/nc:data/dhcp:dhcp/
dhcp:shared-networks/dhcp:shared-network"> dhcp:shared-networks/dhcp:shared-network">
<sch:report test="preceding-sibling::dhcp:shared-network <sch:report test="preceding-sibling::dhcp:shared-network
[dhcp:name=current()/dhcp:name]"> [dhcp:name=current()/dhcp:name]">
Duplicate key of list dhcp:shared-network Duplicate key of list dhcp:shared-network
</sch:report> </sch:report>
</sch:rule> </sch:rule>
<sch:rule context="/nc:rpc-reply/nc:data/dhcp:dhcp/ <sch:rule context="/nc:rpc-reply/nc:data/dhcp:dhcp/
dhcp:shared-networks/dhcp:shared-network/ dhcp:shared-networks/dhcp:shared-network/
dhcp:subnet"> dhcp:subnet">
<sch:extends rule="std-id2246197"/> <sch:extends rule="std-id2247270"/>
</sch:rule> </sch:rule>
<sch:rule context="/nc:rpc-reply/nc:data/dhcp:dhcp/ <sch:rule context="/nc:rpc-reply/nc:data/dhcp:dhcp/
dhcp:status/dhcp:leases"> dhcp:status/dhcp:leases">
<sch:report test="preceding-sibling::dhcp:leases <sch:report test="preceding-sibling::dhcp:leases
[dhcp:address=current()/dhcp:address]"> [dhcp:address=current()/dhcp:address]">
Duplicate key of list dhcp:leases Duplicate key of list dhcp:leases
</sch:report> </sch:report>
</sch:rule> </sch:rule>
</sch:pattern> </sch:pattern>
<sch:pattern id="ref-integrity"/> <sch:pattern id="ref-integrity"/>
skipping to change at page 100, line 7 skipping to change at page 104, 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 -01 and -02 D.1. Changes Between Versions -02 and -03
o Changed @nma:default-case to @nma:implicit.
o Changed nma:leafref annotation from element to attribute.
o Added skeleton rule to Section 9.2.
o Reworked Section 9.4, added skeleton element maps,corrected the
example.
o Added section Section 7.5 on 'feature' and 'deviation'.
o New Section 8.1 integrating discussion of both optional/mandatory
(was in -02) and implicit nodes (new).
o Reflected that key argument and schema node identifiers are no
more XPath (should be in yang-07).
o Element patterns for implicit containers now must have @nma:
implicit attribute.
o Removed "float32" and "float64" types and added mapping of
"decimal64" with example.
o Removed mapping of 'require-instance' for "leafref" type.
o Updated RELAX NG schema for NETMOD-specific annotations.
o Updated the DHCP example.
o Many minor corrections and clarifications.
D.2. Changes Between Versions -01 and -02
o Moved Section 6 "NETCONF Content Validation" after Section 5. o Moved Section 6 "NETCONF Content Validation" after Section 5.
o New text about mapping defaults to DSRL, especially in Section 6 o New text about mapping defaults to DSRL, especially in Section 6
and Section 9.4. and Section 9.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 100, line 33 skipping to change at page 105, line 19
o Fixed the schema for NETMOD-specific annotations by adding o Fixed the schema for NETMOD-specific annotations by adding
explicit prefix to all defined elements and attributes. explicit prefix to all defined elements and attributes.
Previously, the attributes had no namespace. Previously, the attributes had no namespace.
o Handling of 'feature', 'if-feature' and 'deviation' added. o Handling of 'feature', 'if-feature' and 'deviation' added.
o Handling of nma:instance-identifier via XSLT extension function. o Handling of nma:instance-identifier via XSLT extension function.
o Many other minor corrections and improvements. o Many other minor corrections and improvements.
D.2. Changes Between Versions -00 and -01 D.3. Changes Between Versions -00 and -01
o Attributes @nma:min-elements and @nma:max-elements are attached to o Attributes @nma:min-elements and @nma:max-elements are attached to
<rng:element> (list entry) and not to <rng:zeroOrMore> or <rng: <rng:element> (list entry) and not to <rng:zeroOrMore> or <rng:
oneOrMore>. oneOrMore>.
o Keys and all node identifiers in 'key' and 'unique' statements are o Keys and all node identifiers in 'key' and 'unique' statements are
prefixed. prefixed.
o Fixed the mapping of 'rpc' and 'notification'. o Fixed the mapping of 'rpc' and 'notification'.
 End of changes. 309 change blocks. 
764 lines changed or deleted 956 lines changed or added

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