draft-ietf-netmod-dsdl-map-06.txt   draft-ietf-netmod-dsdl-map-07.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: December 21, 2010 Plantronics Expires: February 24, 2011 Plantronics
S. Chisholm S. Chisholm
Nortel Nortel
June 19, 2010 August 23, 2010
Mapping YANG to Document Schema Definition Languages and Validating Mapping YANG to Document Schema Definition Languages and Validating
NETCONF Content NETCONF Content
draft-ietf-netmod-dsdl-map-06 draft-ietf-netmod-dsdl-map-07
Abstract Abstract
This draft specifies the mapping rules for translating YANG data This draft specifies the mapping rules for translating YANG data
models into Document Schema Definition Languages (DSDL), a models into Document Schema Definition Languages (DSDL), a
coordinated set of XML schema languages standardized as ISO 19757. coordinated set of XML schema languages standardized as ISO/IEC
The following DSDL schema languages are addressed by the mapping: 19757. The following DSDL schema languages are addressed by the
RELAX NG, Schematron and DSRL. The mapping takes one or more YANG mapping: RELAX NG, Schematron and Document Schema Renaming Language
modules and produces a set of DSDL schemas for a selected target (DSRL). The mapping takes one or more YANG modules and produces a
document type - datastore content, NETCONF message etc. Procedures set of DSDL schemas for a selected target document type - datastore
for schema-based validation of such documents are also discussed. content, NETCONF message etc. Procedures for schema-based validation
of such documents are also discussed.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted 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). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on December 21, 2010. This Internet-Draft will expire on February 24, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6
2. Terminology and Notation . . . . . . . . . . . . . . . . . . 7 2. Terminology and Notation . . . . . . . . . . . . . . . . . . 8
2.1. Glossary of New Terms . . . . . . . . . . . . . . . . . 10 2.1. Glossary of New Terms . . . . . . . . . . . . . . . . . 11
3. Objectives and Motivation . . . . . . . . . . . . . . . . . . 11 3. Objectives and Motivation . . . . . . . . . . . . . . . . . . 12
4. DSDL Schema Languages . . . . . . . . . . . . . . . . . . . . 13 4. DSDL Schema Languages . . . . . . . . . . . . . . . . . . . . 14
4.1. RELAX NG . . . . . . . . . . . . . . . . . . . . . . . . 13 4.1. RELAX NG . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2. Schematron . . . . . . . . . . . . . . . . . . . . . . . 14 4.2. Schematron . . . . . . . . . . . . . . . . . . . . . . . 15
4.3. Document Semantics Renaming Language (DSRL) . . . . . . 15 4.3. Document Semantics Renaming Language (DSRL) . . . . . . 16
5. Additional Annotations . . . . . . . . . . . . . . . . . . . 16 5. Additional Annotations . . . . . . . . . . . . . . . . . . . 17
5.1. Dublin Core Metadata Elements . . . . . . . . . . . . . 16 5.1. Dublin Core Metadata Elements . . . . . . . . . . . . . 17
5.2. RELAX NG DTD Compatibility Annotations . . . . . . . . . 16 5.2. RELAX NG DTD Compatibility Annotations . . . . . . . . . 17
5.3. NETMOD-Specific Annotations . . . . . . . . . . . . . . 17 5.3. NETMOD-Specific Annotations . . . . . . . . . . . . . . 18
6. Overview of the Mapping . . . . . . . . . . . . . . . . . . . 19 6. Overview of the Mapping . . . . . . . . . . . . . . . . . . . 20
7. NETCONF Content Validation . . . . . . . . . . . . . . . . . 21 7. NETCONF Content Validation . . . . . . . . . . . . . . . . . 22
8. Design Considerations . . . . . . . . . . . . . . . . . . . . 22 8. Design Considerations . . . . . . . . . . . . . . . . . . . . 23
8.1. Hybrid Schema . . . . . . . . . . . . . . . . . . . . . 22 8.1. Hybrid Schema . . . . . . . . . . . . . . . . . . . . . 23
8.2. Modularity . . . . . . . . . . . . . . . . . . . . . . . 25 8.2. Modularity . . . . . . . . . . . . . . . . . . . . . . . 26
8.3. Granularity . . . . . . . . . . . . . . . . . . . . . . 26 8.3. Granularity . . . . . . . . . . . . . . . . . . . . . . 27
8.4. Handling of XML Namespaces . . . . . . . . . . . . . . . 27 8.4. Handling of XML Namespaces . . . . . . . . . . . . . . . 28
9. Mapping YANG Data Models to the Hybrid Schema . . . . . . . . 28 9. Mapping YANG Data Models to the Hybrid Schema . . . . . . . . 29
9.1. Occurrence Rules for Data Nodes . . . . . . . . . . . . 28 9.1. Occurrence Rules for Data Nodes . . . . . . . . . . . . 29
9.1.1. Optional and Mandatory Nodes . . . . . . . . . . . 29 9.1.1. Optional and Mandatory Nodes . . . . . . . . . . . 30
9.1.2. Implicit Nodes . . . . . . . . . . . . . . . . . . 30 9.1.2. Implicit Nodes . . . . . . . . . . . . . . . . . . 31
9.2. Mapping YANG Groupings and Typedefs . . . . . . . . . . 31 9.2. Mapping YANG Groupings and Typedefs . . . . . . . . . . 32
9.2.1. YANG Refinements and Augments . . . . . . . . . . . 32 9.2.1. YANG Refinements and Augments . . . . . . . . . . . 33
9.2.2. Type Derivation Chains . . . . . . . . . . . . . . 35 9.2.2. Type Derivation Chains . . . . . . . . . . . . . . 36
9.3. Translation of XPath Expressions . . . . . . . . . . . . 37 9.3. Translation of XPath Expressions . . . . . . . . . . . . 38
9.4. YANG Language Extensions . . . . . . . . . . . . . . . . 38 9.4. YANG Language Extensions . . . . . . . . . . . . . . . . 39
10. Mapping YANG Statements to the Hybrid Schema . . . . . . . . 40 10. Mapping YANG Statements to the Hybrid Schema . . . . . . . . 41
10.1. The anyxml Statement . . . . . . . . . . . . . . . . . . 40 10.1. The 'anyxml' Statement . . . . . . . . . . . . . . . . . 41
10.2. The argument Statement . . . . . . . . . . . . . . . . . 41 10.2. The 'argument' Statement . . . . . . . . . . . . . . . . 42
10.3. The augment Statement . . . . . . . . . . . . . . . . . 42 10.3. The 'augment' Statement . . . . . . . . . . . . . . . . 43
10.4. The base Statement . . . . . . . . . . . . . . . . . . . 42 10.4. The 'base' Statement . . . . . . . . . . . . . . . . . . 43
10.5. The belongs-to Statement . . . . . . . . . . . . . . . . 42 10.5. The 'belongs-to' Statement . . . . . . . . . . . . . . . 43
10.6. The bit Statement . . . . . . . . . . . . . . . . . . . 42 10.6. The 'bit' Statement . . . . . . . . . . . . . . . . . . 43
10.7. The case Statement . . . . . . . . . . . . . . . . . . . 42 10.7. The 'case' Statement . . . . . . . . . . . . . . . . . . 43
10.8. The choice Statement . . . . . . . . . . . . . . . . . . 42 10.8. The 'choice' Statement . . . . . . . . . . . . . . . . . 43
10.9. The config Statement . . . . . . . . . . . . . . . . . . 43 10.9. The 'config' Statement . . . . . . . . . . . . . . . . . 44
10.10. The contact Statement . . . . . . . . . . . . . . . . . 43 10.10. The 'contact' Statement . . . . . . . . . . . . . . . . 44
10.11. The container Statement . . . . . . . . . . . . . . . . 43 10.11. The 'container' Statement . . . . . . . . . . . . . . . 44
10.12. The default Statement . . . . . . . . . . . . . . . . . 43 10.12. The 'default' Statement . . . . . . . . . . . . . . . . 44
10.13. The description Statement . . . . . . . . . . . . . . . 45 10.13. The 'description' Statement . . . . . . . . . . . . . . 46
10.14. The deviation Statement . . . . . . . . . . . . . . . . 45 10.14. The 'deviation' Statement . . . . . . . . . . . . . . . 46
10.15. The enum Statement . . . . . . . . . . . . . . . . . . . 45 10.15. The 'enum' Statement . . . . . . . . . . . . . . . . . . 46
10.16. The error-app-tag Statement . . . . . . . . . . . . . . 45 10.16. The 'error-app-tag' Statement . . . . . . . . . . . . . 46
10.17. The error-message Statement . . . . . . . . . . . . . . 45 10.17. The 'error-message' Statement . . . . . . . . . . . . . 46
10.18. The extension Statement . . . . . . . . . . . . . . . . 45 10.18. The 'extension' Statement . . . . . . . . . . . . . . . 46
10.19. The feature Statement . . . . . . . . . . . . . . . . . 45 10.19. The 'feature' Statement . . . . . . . . . . . . . . . . 46
10.20. The grouping Statement . . . . . . . . . . . . . . . . . 45 10.20. The 'grouping' Statement . . . . . . . . . . . . . . . . 46
10.21. The identity Statement . . . . . . . . . . . . . . . . . 46 10.21. The 'identity' Statement . . . . . . . . . . . . . . . . 47
10.22. The if-feature Statement . . . . . . . . . . . . . . . . 47 10.22. The 'if-feature' Statement . . . . . . . . . . . . . . . 48
10.23. The import Statement . . . . . . . . . . . . . . . . . . 48 10.23. The 'import' Statement . . . . . . . . . . . . . . . . . 49
10.24. The include Statement . . . . . . . . . . . . . . . . . 48 10.24. The 'include' Statement . . . . . . . . . . . . . . . . 49
10.25. The input Statement . . . . . . . . . . . . . . . . . . 48 10.25. The 'input' Statement . . . . . . . . . . . . . . . . . 49
10.26. The key Statement . . . . . . . . . . . . . . . . . . . 48 10.26. The 'key' Statement . . . . . . . . . . . . . . . . . . 49
10.27. The leaf Statement . . . . . . . . . . . . . . . . . . . 48 10.27. The 'leaf' Statement . . . . . . . . . . . . . . . . . . 49
10.28. The leaf-list Statement . . . . . . . . . . . . . . . . 49 10.28. The 'leaf-list' Statement . . . . . . . . . . . . . . . 50
10.29. The length Statement . . . . . . . . . . . . . . . . . . 49 10.29. The 'length' Statement . . . . . . . . . . . . . . . . . 50
10.30. The list Statement . . . . . . . . . . . . . . . . . . . 50 10.30. The 'list' Statement . . . . . . . . . . . . . . . . . . 51
10.31. The mandatory Statement . . . . . . . . . . . . . . . . 51 10.31. The 'mandatory' Statement . . . . . . . . . . . . . . . 52
10.32. The max-elements Statement . . . . . . . . . . . . . . . 51 10.32. The 'max-elements' Statement . . . . . . . . . . . . . . 52
10.33. The min-elements Statement . . . . . . . . . . . . . . . 51 10.33. The 'min-elements' Statement . . . . . . . . . . . . . . 52
10.34. The module Statement . . . . . . . . . . . . . . . . . . 51 10.34. The 'module' Statement . . . . . . . . . . . . . . . . . 52
10.35. The must Statement . . . . . . . . . . . . . . . . . . . 52 10.35. The 'must' Statement . . . . . . . . . . . . . . . . . . 53
10.36. The namespace Statement . . . . . . . . . . . . . . . . 52 10.36. The 'namespace' Statement . . . . . . . . . . . . . . . 53
10.37. The notification Statement . . . . . . . . . . . . . . . 53 10.37. The 'notification' Statement . . . . . . . . . . . . . . 54
10.38. The ordered-by Statement . . . . . . . . . . . . . . . . 53 10.38. The 'ordered-by' Statement . . . . . . . . . . . . . . . 54
10.39. The organization Statement . . . . . . . . . . . . . . . 53 10.39. The 'organization' Statement . . . . . . . . . . . . . . 54
10.40. The output Statement . . . . . . . . . . . . . . . . . . 53 10.40. The 'output' Statement . . . . . . . . . . . . . . . . . 54
10.41. The path Statement . . . . . . . . . . . . . . . . . . . 53 10.41. The 'path' Statement . . . . . . . . . . . . . . . . . . 54
10.42. The pattern Statement . . . . . . . . . . . . . . . . . 53 10.42. The 'pattern' Statement . . . . . . . . . . . . . . . . 54
10.43. The position Statement . . . . . . . . . . . . . . . . . 54 10.43. The 'position' Statement . . . . . . . . . . . . . . . . 55
10.44. The prefix Statement . . . . . . . . . . . . . . . . . . 54 10.44. The 'prefix' Statement . . . . . . . . . . . . . . . . . 55
10.45. The presence Statement . . . . . . . . . . . . . . . . . 54 10.45. The 'presence' Statement . . . . . . . . . . . . . . . . 55
10.46. The range Statement . . . . . . . . . . . . . . . . . . 54 10.46. The 'range' Statement . . . . . . . . . . . . . . . . . 55
10.47. The reference Statement . . . . . . . . . . . . . . . . 54 10.47. The 'reference' Statement . . . . . . . . . . . . . . . 55
10.48. The require-instance Statement . . . . . . . . . . . . . 54 10.48. The 'require-instance' Statement . . . . . . . . . . . . 55
10.49. The revision Statement . . . . . . . . . . . . . . . . . 54 10.49. The 'revision' Statement . . . . . . . . . . . . . . . . 55
10.50. The rpc Statement . . . . . . . . . . . . . . . . . . . 55 10.50. The 'rpc' Statement . . . . . . . . . . . . . . . . . . 55
10.51. The status Statement . . . . . . . . . . . . . . . . . . 55 10.51. The 'status' Statement . . . . . . . . . . . . . . . . . 56
10.52. The submodule Statement . . . . . . . . . . . . . . . . 55 10.52. The 'submodule' Statement . . . . . . . . . . . . . . . 56
10.53. The type Statement . . . . . . . . . . . . . . . . . . . 55 10.53. The 'type' Statement . . . . . . . . . . . . . . . . . . 56
10.53.1. The empty Type . . . . . . . . . . . . . . . . . . 56 10.53.1. The "empty" Type . . . . . . . . . . . . . . . . . 57
10.53.2. The boolean and binary Types . . . . . . . . . . . 57 10.53.2. The "boolean" and "binary" Types . . . . . . . . . 58
10.53.3. The bits Type . . . . . . . . . . . . . . . . . . . 57 10.53.3. The "bits" Type . . . . . . . . . . . . . . . . . . 58
10.53.4. The enumeration and union Types . . . . . . . . . . 57 10.53.4. The "enumeration" and "union" Types . . . . . . . . 58
10.53.5. The identityref Type . . . . . . . . . . . . . . . 57 10.53.5. The "identityref" Type . . . . . . . . . . . . . . 58
10.53.6. The instance-identifier Type . . . . . . . . . . . 58 10.53.6. The "instance-identifier" Type . . . . . . . . . . 59
10.53.7. The leafref Type . . . . . . . . . . . . . . . . . 58 10.53.7. The "leafref" Type . . . . . . . . . . . . . . . . 59
10.53.8. The numeric Types . . . . . . . . . . . . . . . . . 58 10.53.8. The Numeric Types . . . . . . . . . . . . . . . . . 59
10.53.9. The string Type . . . . . . . . . . . . . . . . . . 60 10.53.9. The "string" Type . . . . . . . . . . . . . . . . . 61
10.53.10. Derived Types . . . . . . . . . . . . . . . . . . . 61 10.53.10. Derived Types . . . . . . . . . . . . . . . . . . . 62
10.54. The typedef Statement . . . . . . . . . . . . . . . . . 62 10.54. The 'typedef' Statement . . . . . . . . . . . . . . . . 63
10.55. The unique Statement . . . . . . . . . . . . . . . . . . 62 10.55. The 'unique' Statement . . . . . . . . . . . . . . . . . 63
10.56. The units Statement . . . . . . . . . . . . . . . . . . 63 10.56. The 'units' Statement . . . . . . . . . . . . . . . . . 64
10.57. The uses Statement . . . . . . . . . . . . . . . . . . . 63 10.57. The 'uses' Statement . . . . . . . . . . . . . . . . . . 64
10.58. The value Statement . . . . . . . . . . . . . . . . . . 63 10.58. The 'value' Statement . . . . . . . . . . . . . . . . . 64
10.59. The when Statement . . . . . . . . . . . . . . . . . . . 63 10.59. The 'when' Statement . . . . . . . . . . . . . . . . . . 64
10.60. The yang-version Statement . . . . . . . . . . . . . . . 63 10.60. The 'yang-version' Statement . . . . . . . . . . . . . . 64
10.61. The yin-element Statement . . . . . . . . . . . . . . . 63 10.61. The 'yin-element' Statement . . . . . . . . . . . . . . 64
11. Mapping the Hybrid Schema to DSDL . . . . . . . . . . . . . . 64 11. Mapping the Hybrid Schema to DSDL . . . . . . . . . . . . . . 65
11.1. Generating RELAX NG Schemas for Various Document Types . 64 11.1. Generating RELAX NG Schemas for Various Document Types . 65
11.2. Mapping Semantic Constraints to Schematron . . . . . . . 65 11.2. Mapping Semantic Constraints to Schematron . . . . . . . 66
11.2.1. Constraints on Mandatory Choice . . . . . . . . . . 68 11.2.1. Constraints on Mandatory Choice . . . . . . . . . . 69
11.3. Mapping Default Values to DSRL . . . . . . . . . . . . . 69 11.3. Mapping Default Values to DSRL . . . . . . . . . . . . . 70
12. Mapping NETMOD-specific Annotations to DSDL Schema 12. Mapping NETMOD-specific Annotations to DSDL Schema
Languages . . . . . . . . . . . . . . . . . . . . . . . . . . 75 Languages . . . . . . . . . . . . . . . . . . . . . . . . . . 76
12.1. The @nma:config Annotation . . . . . . . . . . . . . . . 75 12.1. The @nma:config Annotation . . . . . . . . . . . . . . . 76
12.2. The @nma:default Annotation . . . . . . . . . . . . . . 75 12.2. The @nma:default Annotation . . . . . . . . . . . . . . 76
12.3. The <nma:error-app-tag> Annotation . . . . . . . . . . . 75 12.3. The <nma:error-app-tag> Annotation . . . . . . . . . . . 76
12.4. The <nma:error-message> Annotation . . . . . . . . . . . 75 12.4. The <nma:error-message> Annotation . . . . . . . . . . . 76
12.5. The @if-feature Annotation . . . . . . . . . . . . . . . 75 12.5. The @if-feature Annotation . . . . . . . . . . . . . . . 76
12.6. The @nma:implicit Annotation . . . . . . . . . . . . . . 76 12.6. The @nma:implicit Annotation . . . . . . . . . . . . . . 77
12.7. The <nma:instance-identifier> Annotation . . . . . . . . 76 12.7. The <nma:instance-identifier> Annotation . . . . . . . . 77
12.8. The @nma:key Annotation . . . . . . . . . . . . . . . . 76 12.8. The @nma:key Annotation . . . . . . . . . . . . . . . . 77
12.9. The @nma:leaf-list Annotation . . . . . . . . . . . . . 76 12.9. The @nma:leaf-list Annotation . . . . . . . . . . . . . 77
12.10. The @nma:leafref Annotation . . . . . . . . . . . . . . 77 12.10. The @nma:leafref Annotation . . . . . . . . . . . . . . 78
12.11. The @nma:min-elements Annotation . . . . . . . . . . . . 77 12.11. The @nma:min-elements Annotation . . . . . . . . . . . . 78
12.12. The @nma:max-elements Annotation . . . . . . . . . . . . 77 12.12. The @nma:max-elements Annotation . . . . . . . . . . . . 78
12.13. The <nma:must> Annotation . . . . . . . . . . . . . . . 77 12.13. The <nma:must> Annotation . . . . . . . . . . . . . . . 78
12.14. The <nma:ordered-by> Annotation . . . . . . . . . . . . 78 12.14. The <nma:ordered-by> Annotation . . . . . . . . . . . . 79
12.15. The <nma:status> Annotation . . . . . . . . . . . . . . 78 12.15. The <nma:status> Annotation . . . . . . . . . . . . . . 79
12.16. The @nma:unique Annotation . . . . . . . . . . . . . . . 78 12.16. The @nma:unique Annotation . . . . . . . . . . . . . . . 79
12.17. The @nma:when Annotation . . . . . . . . . . . . . . . . 78 12.17. The @nma:when Annotation . . . . . . . . . . . . . . . . 79
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 79 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 80
14. Security Considerations . . . . . . . . . . . . . . . . . . . 80 14. Security Considerations . . . . . . . . . . . . . . . . . . . 81
15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 81 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 82
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 82 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 83
16.1. Normative References . . . . . . . . . . . . . . . . . . 82 16.1. Normative References . . . . . . . . . . . . . . . . . . 83
16.2. Informative References . . . . . . . . . . . . . . . . . 83 16.2. Informative References . . . . . . . . . . . . . . . . . 84
Appendix A. RELAX NG Schema for NETMOD-Specific Annotations . . 86 Appendix A. RELAX NG Schema for NETMOD-Specific Annotations . . 86
Appendix B. Schema-Independent Library . . . . . . . . . . . . . 91 Appendix B. Schema-Independent Library . . . . . . . . . . . . . 91
Appendix C. Mapping DHCP Data Model - A Complete Example . . . . 92 Appendix C. Mapping DHCP Data Model - A Complete Example . . . . 92
C.1. Input YANG Module . . . . . . . . . . . . . . . . . . . 92 C.1. Input YANG Module . . . . . . . . . . . . . . . . . . . 92
C.2. Hybrid Schema . . . . . . . . . . . . . . . . . . . . . 94 C.2. Hybrid Schema . . . . . . . . . . . . . . . . . . . . . 94
C.3. Final DSDL Schemas . . . . . . . . . . . . . . . . . . . 99 C.3. Final DSDL Schemas . . . . . . . . . . . . . . . . . . . 99
C.3.1. Main RELAX NG Schema for <nc:get> Reply . . . . . . 100 C.3.1. Main RELAX NG Schema for <nc:get> Reply . . . . . . 100
C.3.2. RELAX NG Schema - Global Named Pattern C.3.2. RELAX NG Schema - Global Named Pattern
Definitions . . . . . . . . . . . . . . . . . . . . 102 Definitions . . . . . . . . . . . . . . . . . . . . 102
C.3.3. Schematron Schema for <nc:get> Reply . . . . . . . 104 C.3.3. Schematron Schema for <nc:get> Reply . . . . . . . 104
C.3.4. DSRL Schema for <nc:get> Reply . . . . . . . . . . 106 C.3.4. DSRL Schema for <nc:get> Reply . . . . . . . . . . 106
Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 107 Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 107
D.1. Changes Between Versions -05 and -06 . . . . . . . . . . 107 D.1. Changes Between Versions -06 and -07 . . . . . . . . . . 107
D.2. Changes Between Versions -04 and -05 . . . . . . . . . . 107 D.2. Changes Between Versions -05 and -06 . . . . . . . . . . 107
D.3. Changes Between Versions -04 and -05 . . . . . . . . . . 107 D.3. Changes Between Versions -04 and -05 . . . . . . . . . . 108
D.4. Changes Between Versions -03 and -04 . . . . . . . . . . 108 D.4. Changes Between Versions -03 and -04 . . . . . . . . . . 108
D.5. Changes Between Versions -02 and -03 . . . . . . . . . . 109 D.5. Changes Between Versions -02 and -03 . . . . . . . . . . 109
D.6. Changes Between Versions -01 and -02 . . . . . . . . . . 109 D.6. Changes Between Versions -01 and -02 . . . . . . . . . . 109
D.7. Changes Between Versions -00 and -01 . . . . . . . . . . 110 D.7. Changes Between Versions -00 and -01 . . . . . . . . . . 110
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 111 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 111
1. Introduction 1. Introduction
The NETCONF Working Group has completed a base protocol used for The NETCONF Working Group has completed a base protocol used for
configuration management [RFC4741]. This base specification defines configuration management [RFC4741]. This base specification defines
protocol bindings and an XML container syntax for configuration and protocol bindings and an XML container syntax for configuration and
management operations, but does not include a data modeling language management operations, but does not include a data modeling language
or accompanying rules for how to model configuration and state or accompanying rules for how to model configuration and state
information carried by NETCONF. The IETF Operations Area has a long information carried by NETCONF. The IETF Operations Area has a long
tradition of defining data for SNMP Management Information Bases tradition of defining data for SNMP Management Information Bases
(MIBs) [RFC1157] using the SMI language [RFC2578] to model its data. (MIB) modules [RFC1157] using the Structure of Management Information
While this specific modeling approach has a number of well-understood (SMI) language [RFC2578] to model its data. While this specific
problems, most of the data modeling features provided by SMI are modeling approach has a number of well-understood problems, most of
still considered extremely important. Simply modeling the valid the data modeling features provided by SMI are still considered
syntax without the additional semantic relationships has caused extremely important. Simply modeling the valid syntax without the
significant interoperability problems in the past. additional semantic relationships has caused significant
interoperability problems in the past.
The NETCONF community concluded that a data modeling framework is The NETCONF community concluded that a data modeling framework is
needed to support ongoing development of IETF and vendor-defined needed to support ongoing development of IETF and vendor-defined
management information modules. The NETMOD Working Group was management information modules. The NETMOD Working Group was
chartered to address this problem by defining a new human-friendly chartered to design a modeling language defining the semantics of
modeling language based on SMIng [RFC3216] and called YANG [YANG]. operational data, configuration data, event notifications and
operations, with focus on "human-friendliness", i.e., readability and
ease of use. The result is the YANG data modeling language [YANG],
which now serves for the normative description of NETCONF data
models.
Since NETCONF uses XML for encoding its messages, it is natural to Since NETCONF uses XML for encoding its messages, it is natural to
express the constraints on NETCONF content using standard XML schema express the constraints on NETCONF content using standard XML schema
languages. For this purpose, the NETMOD WG selected the Document languages. For this purpose, the NETMOD WG selected the Document
Schema Definition Languages (DSDL) that is being standardized as ISO/ Schema Definition Languages (DSDL) that is being standardized as ISO/
IEC 19757 [DSDL]. The DSDL framework comprises a set of XML schema IEC 19757 [DSDL]. The DSDL framework comprises a set of XML schema
languages that address grammar rules, semantic constraints and other languages that address grammar rules, semantic constraints and other
data modeling aspects, but also, and more importantly, do it in a data modeling aspects, but also, and more importantly, do it in a
coordinated and consistent way. While it is true that some DSDL coordinated and consistent way. While it is true that some DSDL
parts have not been standardized yet and are still work in progress, parts have not been standardized yet and are still work in progress,
the three parts that the YANG-to-DSDL mapping relies upon - RELAX NG, the three parts that the YANG-to-DSDL mapping relies upon - RELAX NG,
Schematron and DSRL - already have the status of an ISO/IEC Schematron and Document Schema Renaming Language (DSRL) - already
International Standard and are supported in a number of software have the status of an ISO/IEC International Standard and are
tools. supported in a number of software tools.
This document contains a specification of a mapping that translates This document contains a specification of a mapping that translates
YANG data models to XML schemas utilizing a subset of the DSDL schema YANG data models to XML schemas utilizing a subset of the DSDL schema
languages. The mapping procedure is divided into two steps: In the languages. The mapping procedure is divided into two steps: In the
first step, the structure of the data tree, signatures of RPC first step, the structure of the data tree, signatures of remote
operations and notifications is expressed as the so-called "hybrid procedure call (RPC) operations and notifications is expressed as the
schema" - a single RELAX NG schema with annotations representing so-called "hybrid schema" - a single RELAX NG schema with annotations
additional data model information (metadata, documentation, semantic representing additional data model information (metadata,
constraints, default values etc.). The second step then generates a documentation, semantic constraints, default values etc.). The
coordinated set of DSDL schemas that can be used for validating second step then generates a coordinated set of DSDL schemas that can
specific XML documents such as client requests, server responses or be used for validating specific XML documents such as client
notifications, perhaps also taking into account additional context requests, server responses or notifications, perhaps also taking into
such as active capabilities or features. account additional context such as active capabilities or features.
2. Terminology and Notation 2. Terminology and Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
The following terms are defined in [RFC4741]: The following terms are defined in [RFC4741]:
o client o client
skipping to change at page 11, line 15 skipping to change at page 12, line 15
3. Objectives and Motivation 3. Objectives and Motivation
The main objective of this work is to complement YANG as a data The main objective of this work is to complement YANG as a data
modeling language by validation capabilities of DSDL schema modeling language by validation capabilities of DSDL schema
languages, namely RELAX NG, Schematron and DSRL. This document languages, namely RELAX NG, Schematron and DSRL. This document
describes the correspondence between grammatical, semantic and data describes the correspondence between grammatical, semantic and data
type constraints expressed in YANG and equivalent DSDL patterns and type constraints expressed in YANG and equivalent DSDL patterns and
rules. The ultimate goal is to be able to capture all substantial rules. The ultimate goal is to be able to capture all substantial
information contained in YANG modules and express it in DSDL schemas. information contained in YANG modules and express it in DSDL schemas.
While the mapping from YANG to DSDL described in this document may in While the mapping from YANG to DSDL described in this document may in
principle be invertible, the inverse mapping from DSDL to YANG beyond principle be invertible, the inverse mapping from DSDL to YANG is
the scope of this document. beyond the scope of this document.
XML-based information models and XML-encoded data appear in several XML-based information models and XML-encoded data appear in several
different forms in various phases of YANG data modeling and NETCONF different forms in various phases of YANG data modeling and NETCONF
workflow - configuration datastore contents, RPC requests and workflow - configuration datastore contents, RPC requests and
replies, and notifications. Moreover, RPC operations are replies, and notifications. Moreover, RPC operations are
characterized by an inherent diversity resulting from selective characterized by an inherent diversity resulting from selective
availability of capabilities and features. YANG modules can also availability of capabilities and features. YANG modules can also
define new RPC operations. The mapping should be able to accommodate define new RPC operations. The mapping should be able to accommodate
this variability and generate schemas that are specifically tailored this variability and generate schemas that are specifically tailored
to a particular situation and thus considerably more effective for to a particular situation and thus considerably more effective for
skipping to change at page 13, line 9 skipping to change at page 14, line 9
2. In the second step, the hybrid schema from step 1 is transformed 2. In the second step, the hybrid schema from step 1 is transformed
further to a coordinated set of fully conformant DSDL schemas further to a coordinated set of fully conformant DSDL schemas
containing constraints for a particular data object and a containing constraints for a particular data object and a
specific situation. The DSDL schemas are intended mainly for specific situation. The DSDL schemas are intended mainly for
machine validation using off-the-shelf tools. machine validation using off-the-shelf tools.
4. DSDL Schema Languages 4. DSDL Schema Languages
Document Schema Definition Languages (DSDL) is a framework of schema Document Schema Definition Languages (DSDL) is a framework of schema
languages that is being developed as the International Standard ISO/ languages that is being developed as the International Standard ISO/
IEC 19757. Unlike other approaches to XML document validation, most IEC 19757 [DSDL]. Unlike other approaches to XML document
notably W3C XML Schema (XSD) [XSD], the DSDL framework adheres to the validation, most notably W3C XML Schema Definition (XSD) [XSD], the
principle of "small languages": Each of the DSDL constituents is a DSDL framework adheres to the principle of "small languages": Each of
stand-alone schema language with a relatively narrow purpose and the DSDL constituents is a stand-alone schema language with a
focus. Together, these schema languages may be used in a coordinated relatively narrow purpose and focus. Together, these schema
way to accomplish various validation tasks. 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 [RNG], Schematron [Schematron] and DSRL
[DSRL].
4.1. RELAX NG 4.1. RELAX NG
RELAX NG (pronounced "relaxing") is an XML schema language for RELAX NG (pronounced "relaxing") is an XML schema language for
grammar-based validation and Part 2 of the ISO/IEC DSDL family of grammar-based validation and Part 2 of the ISO/IEC DSDL family of
standards [RNG]. Like the W3C XML Schema language [XSD], it is able standards [RNG]. Like the W3C XML Schema language [XSD], it is able
to describe constraints on the structure and contents of XML to describe constraints on the structure and contents of XML
documents. However, unlike the DTD [XML] and XSD schema languages, documents. However, unlike the DTD [XML] and XSD schema languages,
RELAX NG intentionally avoids any infoset augmentation such as RELAX NG intentionally avoids any infoset augmentation such as
defining default values. In the DSDL architecture, the particular defining default values. In the DSDL architecture, the particular
skipping to change at page 13, line 44 skipping to change at page 14, line 46
RELAX NG is very liberal in accepting annotations from other RELAX NG is very liberal in accepting annotations from other
namespaces. With a few exceptions, such annotations may be placed namespaces. With a few exceptions, such annotations may be placed
anywhere in the schema and need no encapsulating elements such as anywhere in the schema and need no encapsulating elements such as
<xsd:annotation> in XSD. <xsd:annotation> in XSD.
RELAX NG schemas can be represented in two equivalent syntaxes: XML RELAX NG schemas can be represented in two equivalent syntaxes: XML
and compact. The compact syntax is described in Annex C of the RELAX and compact. The compact syntax is described in Annex C of the RELAX
NG specification [RNG-CS], which was added to the standard in 2006 NG specification [RNG-CS], which was added to the standard in 2006
(Amendment 1). Automatic bidirectional conversions between the two (Amendment 1). Automatic bidirectional conversions between the two
syntaxes can be accomplished using several tools, for example syntaxes can be accomplished using several tools, for example Trang
Trang [1]. [Trang].
For its terseness and readability, the compact syntax is often the For its terseness and readability, the compact syntax is often the
preferred form for publishing RELAX NG schemas whereas validators and preferred form for publishing RELAX NG schemas whereas validators and
other software tools usually work with the XML syntax. However, the other software tools usually work with the XML syntax. However, the
compact syntax has two drawbacks: compact syntax has two drawbacks:
o External annotations make the compact syntax schema considerably o External annotations make the compact syntax schema considerably
less readable. While in the XML syntax the annotating elements less readable. While in the XML syntax the annotating elements
and attributes are represented in a simple and uniform way (XML and attributes are represented in a simple and uniform way (XML
elements and attributes from foreign namespaces), the compact elements and attributes from foreign namespaces), the compact
skipping to change at page 16, line 27 skipping to change at page 17, line 27
appear in the final validation schemas. appear in the final validation schemas.
The third set are NETMOD-specific annotations. They are specifically The third set are NETMOD-specific annotations. They are specifically
designed for the hybrid schema and convey semantic constraints and designed for the hybrid schema and convey semantic constraints and
other information that cannot be expressed directly in RELAX NG. In other information that cannot be expressed directly in RELAX NG. In
the second mapping step, these annotations are converted to the second mapping step, these annotations are converted to
Schematron and DSRL rules. Schematron and DSRL rules.
5.1. Dublin Core Metadata Elements 5.1. Dublin Core Metadata Elements
Dublin Core [2] is a system of metadata elements that was originally Dublin Core is a system of metadata elements that was originally
created for describing metadata of World Wide Web resources in order created for describing metadata of World Wide Web resources in order
to facilitate their automated lookup. Later it was accepted as a to facilitate their automated lookup. Later it was accepted as a
standard for describing metadata of arbitrary resources. This standard for describing metadata of arbitrary resources. This
specification uses the definition from [RFC5013]. specification uses the definition from [RFC5013].
Dublin Core elements are qualified with namespace URI Dublin Core elements are qualified with namespace URI
"http://purl.org/dc/terms". "http://purl.org/dc/terms".
5.2. RELAX NG DTD Compatibility Annotations 5.2. RELAX NG DTD Compatibility Annotations
skipping to change at page 25, line 14 skipping to change at page 26, line 14
A complete hybrid schema for the data model of a DHCP server is given A complete hybrid schema for the data model of a DHCP server is given
in Appendix C.2. in Appendix C.2.
8.2. Modularity 8.2. Modularity
Both YANG and RELAX NG offer means for modularity, i.e., for Both YANG and RELAX NG offer means for modularity, i.e., for
splitting the contents of a full schema into separate modules and splitting the contents of a full schema into separate modules and
combining or reusing them in various ways. However, the approaches combining or reusing them in various ways. However, the approaches
taken by YANG and RELAX NG differ. Modularity in RELAX NG is taken by YANG and RELAX NG differ. Modularity in RELAX NG is
suitable for ad hoc combinations of a small number of schemas whereas suitable for ad hoc combinations of a small number of schemas whereas
YANG assumes a large set of modules similar to SNMP MIBs. The YANG assumes a large set of modules similar to SNMP MIB modules. The
following differences are important: following differences are important:
o In YANG, whenever module A imports module B, it gets access to the o In YANG, whenever module A imports module B, it gets access to the
definitions (groupings and typedefs) appearing at the top level of definitions (groupings and typedefs) appearing at the top level of
module B. However, no part of data tree from module B is imported module B. However, no part of data tree from module B is imported
along with it. In contrast, the <rng:include> pattern in RELAX NG along with it. In contrast, the <rng:include> pattern in RELAX NG
imports both definitions of named patterns and the entire schema imports both definitions of named patterns and the entire schema
tree from the included schema. tree from the included schema.
o The names of imported YANG groupings and typedefs are qualified o The names of imported YANG groupings and typedefs are qualified
skipping to change at page 27, line 33 skipping to change at page 28, line 33
In both the hybrid schema and validation RELAX NG schemas generated In both the hybrid schema and validation RELAX NG schemas generated
in the second step, the namespaces MUST be declared as follows: in the second step, the namespaces MUST be declared as follows:
1. The root <rng:grammar> MUST have @xmlns:xxx attributes declaring 1. The root <rng:grammar> MUST have @xmlns:xxx attributes declaring
prefixes of all namespaces that are used in the data model. The prefixes of all namespaces that are used in the data model. The
prefixes SHOULD be identical to those defined in the 'prefix' prefixes SHOULD be identical to those defined in the 'prefix'
statements. An implementation of the mapping MUST resolve all statements. An implementation of the mapping MUST resolve all
collisions in the prefixes defined by different input modules, if collisions in the prefixes defined by different input modules, if
there are any. there are any.
2. Each embedded <rng:grammar> element must declare the namespace of 2. Each embedded <rng:grammar> element MUST declare the namespace of
the corresponding module using the @ns attribute. This way, the the corresponding module using the @ns attribute. This way, the
names of nodes defined by global named patterns are able to adopt names of nodes defined by global named patterns are able to adopt
the local namespace of each embedded grammar, as explained in the local namespace of each embedded grammar, as explained in
Section 8.2. Section 8.2.
This setup is illustrated by the example at the end of Section 8.1. This setup is illustrated by the example at the end of Section 8.1.
DSRL schemas may declare any number of target namespaces via the DSRL schemas may declare any number of target namespaces via the
standard XML attributes xmlns:xxx. standard XML attributes xmlns:xxx.
skipping to change at page 40, line 46 skipping to change at page 41, line 46
consequently, all definitions of subelements in the hybrid schema consequently, all definitions of subelements in the hybrid schema
MUST be enclosed in the <rng:interleave> element. MUST be enclosed in the <rng:interleave> element.
The following conventions are used in this section: The following conventions are used in this section:
o The argument of the statement being mapped is denoted by ARGUMENT. o The argument of the statement being mapped is denoted by ARGUMENT.
o The element in the RELAX NG schema that becomes the parent of the o The element in the RELAX NG schema that becomes the parent of the
resulting XML fragment is denoted by PARENT. resulting XML fragment is denoted by PARENT.
10.1. The anyxml Statement 10.1. The 'anyxml' Statement
This statement is mapped to <rng:element> element and ARGUMENT with This statement is mapped to <rng:element> element and ARGUMENT with
prepended local namespace prefix becomes the value of its @name prepended local namespace prefix becomes the value of its @name
attribute. The contents of <rng:element> are attribute. The contents of <rng:element> are
<rng:ref name="__anyxml__"/> <rng:ref name="__anyxml__"/>
Substatements of the 'anyxml' statement, if any, MAY be mapped to Substatements of the 'anyxml' statement, if any, MAY be mapped to
additional children of the <rng:element> element. additional children of the <rng:element> element.
If at least one 'anyxml' statement occurs in any of the input YANG If at least one 'anyxml' statement occurs in any of the input YANG
skipping to change at page 41, line 46 skipping to change at page 42, line 46
<a:documentation>Any XML content allowed here</a:documentation> <a:documentation>Any XML content allowed here</a:documentation>
<rng:ref name="__anyxml__"/> <rng:ref name="__anyxml__"/>
</rng:element> </rng:element>
An anyxml node is optional if there is no "mandatory true;" An anyxml node is optional if there is no "mandatory true;"
substatement. The <rng:element> element then MUST be wrapped in substatement. The <rng:element> element then MUST be wrapped in
<rng:optional>, except when the 'anyxml' statement is a child of the <rng:optional>, except when the 'anyxml' statement is a child of the
'choice' statement and thus forms a shorthand case for that choice 'choice' statement and thus forms a shorthand case for that choice
(see Section 9.1.1 for details). (see Section 9.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 handling extensions in Section 9.4. for handling extensions in Section 9.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
augmented module is not processed within the same mapping session, augmented module is not processed within the same mapping session,
the top-level 'augment' statement MUST be ignored. Otherwise, the the top-level 'augment' statement MUST be ignored. Otherwise, the
contents of the statement are added to the foreign module with the contents of the statement are added to the foreign module with the
namespace of the module where the 'augment' statement appears. namespace of the module where the 'augment' statement appears.
10.4. The base Statement 10.4. The 'base' Statement
This statement is ignored as a substatement of 'identity' and handled This statement is ignored as a substatement of 'identity' and handled
within the 'identityref' type if it appears as a substatement of that within the 'identityref' type if it appears as a substatement of that
type definition, see Section 10.53.5. type definition, see Section 10.53.5.
10.5. The belongs-to Statement 10.5. The 'belongs-to' Statement
This statement is not used since the processing of submodules is This statement is not used since the processing of submodules is
always initiated from the main module, see Section 10.24. always initiated from the main module, see Section 10.24.
10.6. The bit Statement 10.6. The 'bit' Statement
This statement is handled within the "bits" type, see This statement is handled within the "bits" type, see
Section 10.53.3. Section 10.53.3.
10.7. The case Statement 10.7. The 'case' Statement
This statement is mapped to <rng:group> or <rng:interleave> element, This statement is mapped to <rng:group> or <rng:interleave> element,
depending on whether the statement belongs to an definition of an RPC depending on whether the statement belongs to an definition of an RPC
operation or not. If the argument of a sibling 'default' statement operation or not. If the argument of a sibling 'default' statement
equals to ARGUMENT, @nma:implicit attribute with the value of "true" equals to ARGUMENT, @nma:implicit attribute with the value of "true"
MUST be added to that <rng:group> or <rng:interleave> element. The MUST be added to that <rng:group> or <rng:interleave> element. The
@nma:implicit attribute MUST NOT be used for nodes at the top-level @nma:implicit attribute MUST NOT be used for nodes at the top-level
of a non-default case (see Section 7.9.3 in [YANG]). of a non-default case (see Section 7.9.3 in [YANG]).
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.
If 'choice' has the 'mandatory' substatement with the value of If 'choice' has the 'mandatory' substatement with the value of
"true", the attribute @nma:mandatory MUST be added to the <rng: "true", the attribute @nma:mandatory MUST be added to the <rng:
choice> element with the value of ARGUMENT. This case may require choice> element with the value of ARGUMENT. This case may require
additional handling, see Section 11.2.1. Otherwise, if "mandatory additional handling, see Section 11.2.1. Otherwise, if "mandatory
true;" is not present, the <rng:choice> element MUST be wrapped in true;" is not present, the <rng:choice> element MUST be wrapped in
<rng:optional>. <rng:optional>.
The alternatives in <rng:choice> - mapped from either the 'case' The alternatives in <rng:choice> - mapped from either the 'case'
statement or a shorthand case - MUST NOT be defined as optional. statement or a shorthand case - MUST NOT be defined as optional.
10.9. The config Statement 10.9. The 'config' Statement
This statement is mapped to @nma:config attribute and ARGUMENT This statement is mapped to @nma:config attribute and ARGUMENT
becomes its value. becomes its value.
10.10. The contact Statement 10.10. The 'contact' Statement
This statement SHOULD NOT be used by the mapping since the hybrid This statement SHOULD NOT be used by the mapping since the hybrid
schema may be mapped from multiple YANG modules created by different schema may be mapped from multiple YANG modules created by different
authors. The hybrid schema contains references to all input modules authors. The hybrid schema contains references to all input modules
in the Dublin Core elements <dc:source>, see Section 10.34. The in the Dublin Core elements <dc:source>, see Section 10.34. The
original YANG modules are the authoritative sources of the authorship original YANG modules are the authoritative sources of the authorship
information. information.
10.11. The container Statement 10.11. The 'container' Statement
Using the rules specified in Section 9.1.1, the mapping algorithm Using the rules specified in Section 9.1.1, the mapping algorithm
MUST determine whether the statement defines an optional container, MUST determine whether the statement defines an optional container,
and if so, insert the <rng:optional> element and make it the new and if so, insert the <rng:optional> element and make it the new
PARENT. PARENT.
The container defined by this statement is then mapped to the <rng: The container defined by this statement is then mapped to the <rng:
element> element, which becomes a child of PARENT and uses ARGUMENT element> element, which becomes a child of PARENT and uses ARGUMENT
with prepended local namespace prefix as the value of its @name with prepended local namespace prefix as the value of its @name
attribute. attribute.
Finally, using the rules specified in Section 9.1.2, the mapping Finally, using the rules specified in Section 9.1.2, the mapping
algorithm MUST determine whether the container is implicit, and if algorithm MUST determine whether the container is implicit, and if
so, add the attribute @nma:implicit with the value of "true" to the so, add the attribute @nma:implicit with the value of "true" to the
<rng:element> element. <rng:element> element.
10.12. The default Statement 10.12. The 'default' Statement
If this statement is a substatement of 'leaf', it is mapped to the If this statement is a substatement of 'leaf', it is mapped to the
@nma:default attribute of PARENT and ARGUMENT becomes its value. @nma:default attribute of PARENT and ARGUMENT becomes its value.
As a substatement of 'typedef', the 'default' statement is also As a substatement of 'typedef', the 'default' statement is also
mapped to the @nma:default attribute with the value of ARGUMENT. The mapped to the @nma:default attribute with the value of ARGUMENT. The
placement of this attribute depends on whether or not the type placement of this attribute depends on whether or not the type
definition has to be expanded when it is used: definition has to be expanded when it is used:
o If the type definition is not expanded, @nma:default becomes an o If the type definition is not expanded, @nma:default becomes an
skipping to change at page 45, line 5 skipping to change at page 46, line 5
<rng:group nma:implicit="true"> <rng:group nma:implicit="true">
<rng:element name="yam:feuille"> <rng:element name="yam:feuille">
<rng:empty/> <rng:empty/>
</rng:element> </rng:element>
</rng:group> </rng:group>
<rng:element name="yam:hoja"> <rng:element name="yam:hoja">
<rng:empty/> <rng:empty/>
</rng:element/> </rng:element/>
</rng:choice> </rng:choice>
10.13. The description Statement 10.13. The 'description' Statement
This statement MAY be ignored. Otherwise, it is mapped to the DTD This statement is mapped to the DTD compatibility element
compatibility element <a:documentation> and ARGUMENT becomes its <a:documentation> and ARGUMENT becomes its text.
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
This statement is ignored. However, it is assumed that all This statement is ignored. However, it is assumed that all
deviations are known beforehand and the corresponding changes have deviations are known beforehand and the corresponding changes have
already been applied to the input YANG modules. already been applied to the input YANG modules.
10.15. The enum Statement 10.15. The 'enum' Statement
This statement is mapped to <rng:value> element and ARGUMENT becomes This statement is mapped to <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 annotation elements, see [RNG], <rng:value> element cannot contain annotation elements, see [RNG],
section 6. section 6.
10.16. The error-app-tag Statement 10.16. The 'error-app-tag' Statement
This statement is ignored unless it is a substatement of 'must'. In This statement is ignored unless it is a substatement of 'must'. In
the latter case it is mapped to the <nma:error-app-tag> element. See the latter case it is mapped to the <nma:error-app-tag> element. See
also Section 10.35. also Section 10.35.
10.17. The error-message Statement 10.17. The 'error-message' Statement
This statement is ignored unless it is a substatement of 'must'. In This statement is ignored unless it is a substatement of 'must'. In
the latter case it is mapped to the <nma:error-message> element. See the latter case it is mapped to the <nma:error-message> element. 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 9.4. MAY be mapped as described in Section 9.4.
10.19. The feature Statement 10.19. The 'feature' Statement
This statement is ignored. This statement is ignored.
10.20. The grouping Statement 10.20. The 'grouping' Statement
This statement is mapped to a RELAX NG named pattern definition <rng: This statement is mapped to a RELAX NG named pattern definition <rng:
define>, but only if the grouping defined by this statement is used define>, but only if the grouping defined by this statement is used
without refinements and augments in at least one of the input without refinements and augments in at least one of the input
modules. In this case, the named pattern definition becomes a child modules. In this case, the named pattern definition becomes a child
of the <rng:grammar> element and its name is ARGUMENT mangled of the <rng:grammar> element and its name is ARGUMENT mangled
according to the rules specified in Section 9.2. according to the rules specified in Section 9.2.
As explained in Section 8.2, a named pattern definition MUST be As explained in Section 8.2, a named pattern definition MUST be
placed placed
skipping to change at page 46, line 28 skipping to change at page 47, line 27
expanded so that the refinements and augments may be applied in place expanded so that the refinements and augments may be applied in place
to the prescribed schema nodes. See Section 9.2.1 for further to the prescribed schema nodes. See Section 9.2.1 for further
details and an example. details and an example.
An implementation MAY offer the option of mapping all 'grouping' An implementation MAY offer the option of mapping all 'grouping'
statements as named pattern definitions in the output RELAX NG schema statements as named pattern definitions in the output RELAX NG schema
even if they are not referenced. This is useful for mapping YANG even if they are not referenced. This is useful for mapping YANG
"library" modules that typically contain only 'typedef' and/or "library" modules that typically contain only 'typedef' and/or
'grouping' statements. 'grouping' statements.
10.21. The identity Statement 10.21. The 'identity' Statement
This statement is mapped to the following named pattern definition This statement is mapped to the following named pattern definition
which is placed as a child of the root <rng:grammar> element: which is placed as a child of the root <rng:grammar> element:
<rng:define name="__PREFIX_ARGUMENT"> <rng:define name="__PREFIX_ARGUMENT">
<rng:choice> <rng:choice>
<rng:value type="QName">PREFIX:ARGUMENT</rng:value> <rng:value type="QName">PREFIX:ARGUMENT</rng:value>
<rng:ref name="IDENTITY1"/> <rng:ref name="IDENTITY1"/>
... ...
</rng:choice> </rng:choice>
skipping to change at page 47, line 46 skipping to change at page 48, line 46
<ref name="__des_des3"/> <ref name="__des_des3"/>
</choice> </choice>
</define> </define>
<define name="__des_des"> <define name="__des_des">
<value type="QName">des:des</value> <value type="QName">des:des</value>
</define> </define>
<define name="__des_des3"> <define name="__des_des3">
<value type="QName">des:des3</value> <value type="QName">des:des3</value>
</define> </define>
10.22. The if-feature Statement 10.22. The 'if-feature' Statement
ARGUMENT together with arguments of all sibling 'if-feature' ARGUMENT together with arguments of all sibling 'if-feature'
statements (with added prefixes, if missing) MUST be collected in a statements (with added prefixes, if missing) MUST be collected in a
space-separated list which becomes the value of the @nma:if-feature space-separated list which becomes the value of the @nma:if-feature
attribute. This attribute is attached to PARENT. attribute. This attribute is attached to PARENT.
10.23. The import Statement 10.23. The 'import' Statement
This statement is not specifically mapped. The module whose name is This statement is not specifically mapped. The module whose name is
in ARGUMENT has to be parsed so that the importing module is able to in ARGUMENT has to be parsed so that the importing module is able to
use its top-level groupings, typedefs and identities, and also use its top-level groupings, typedefs and identities, and also
augment the data tree of the imported module. augment the data tree of the imported module.
If the 'import' statement has the 'revision' substatement, the If the 'import' statement has the 'revision' substatement, the
corresponding revision of the imported module MUST be used. The corresponding revision of the imported module MUST be used. The
mechanism for finding a given module revision is outside the scope of mechanism for finding a given module revision is outside the scope of
this document. this document.
10.24. The include Statement 10.24. The 'include' Statement
This statement is not specifically mapped. The submodule whose name This statement is not specifically mapped. The submodule whose name
is in ARGUMENT has to be parsed and its contents mapped exactly as if is in ARGUMENT has to be parsed and its contents mapped exactly as if
the submodule text appeared directly in the main module text. the submodule text appeared directly in the main module text.
If the 'include' statement has the 'revision' substatement, the If the 'include' statement has the 'revision' substatement, the
corresponding revision of the submodule MUST be used. The mechanism corresponding revision of the submodule MUST be used. The mechanism
for finding a given submodule revision is outside the scope of this for finding a given submodule revision is outside the scope of this
document. document.
10.25. The input Statement 10.25. The 'input' Statement
This statement is handled within 'rpc' statement, see Section 10.50. This statement is handled within 'rpc' statement, see Section 10.50.
10.26. The key Statement 10.26. The 'key' Statement
This statement is mapped to @nma:key attribute. ARGUMENT MUST be This statement is mapped to @nma:key attribute. ARGUMENT MUST be
translated so that every key is prefixed with the namespace prefix of translated so that every key is prefixed with the namespace prefix of
the local module. The result of this translation then becomes the the local module. The result of this translation then becomes the
value of the @nma:key attribute. value of the @nma:key attribute.
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
with prepended local namespace prefix becomes the value of its @name with prepended local namespace prefix becomes the value of its @name
attribute. attribute.
If the leaf is optional, i.e., if there is no "mandatory true;" If the leaf is optional, i.e., if there is no "mandatory true;"
substatement and the leaf is not declared among the keys of an substatement and the leaf is not declared among the keys of an
enclosing list, then the <rng:element> element MUST be enclosed in enclosing list, then the <rng:element> element MUST be enclosed in
<rng:optional>, except when the 'leaf' statement is a child of the <rng:optional>, except when the 'leaf' statement is a child of the
'choice' statement and thus represents a shorthand case for that 'choice' statement and thus represents a shorthand case for that
choice (see Section 9.1.1 for details). choice (see Section 9.1.1 for details).
10.28. The leaf-list Statement 10.28. The 'leaf-list' Statement
This statement is mapped to a block enclosed by either <rng: This statement is mapped to a block enclosed by either <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 then added as a child element of PARENT and ARGUMENT <rng:element> is then added as a child element of PARENT and ARGUMENT
with prepended local namespace prefix becomes the value of its @name with prepended local namespace prefix becomes the value of its @name
attribute. Another attribute, @nma:leaf-list, MUST also be added to attribute. Another attribute, @nma:leaf-list, MUST also be added to
skipping to change at page 49, line 45 skipping to change at page 50, line 45
is mapped to the following RELAX NG fragment: is mapped to the following RELAX NG fragment:
<rng:oneOrMore> <rng:oneOrMore>
<rng:element name="yam:foliage" nma:leaf-list="true" <rng:element name="yam:foliage" nma:leaf-list="true"
nma:ordered-by="user" nma:ordered-by="user"
nma:min-elements="3" nma:max-elements="6378"> nma:min-elements="3" nma:max-elements="6378">
<rng:data type="string"/> <rng:data type="string"/>
</rng:element> </rng:element>
</rng:oneOrMore> </rng:oneOrMore>
10.29. The length Statement 10.29. The 'length' Statement
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. The only difference is that the @nma:leaf-list Section 10.28. The only difference is that the @nma:leaf-list
annotation either MUST NOT be present or MUST have the value of annotation either MUST NOT be present or MUST have the value of
"false". "false".
When mapping the substatements of 'list', the order of children of When mapping the substatements of 'list', the order of children of
the list element MUST be specified so that list keys, if there are the list element MUST be specified so that list keys, if there are
any, always appear in the same order as they are defined in the 'key' any, always appear in the same order as they are defined in the 'key'
substatement and before other children, see [YANG], Section 7.8.5. substatement and before other children, see [YANG], Section 7.8.5.
skipping to change at page 51, line 24 skipping to change at page 52, line 24
<rng:element name="yam:baz"> <rng:element name="yam:baz">
<rng:data type="string"/> <rng:data type="string"/>
</rng:element> </rng:element>
</rng:interleave> </rng:interleave>
</rng:element> </rng:element>
</rng:zeroOrMore> </rng:zeroOrMore>
Note that the "keygrp" grouping is expanded and the definition of Note that the "keygrp" grouping is expanded and the definition of
"yam:clef" is moved before the <rng:interleave> pattern. "yam:clef" is moved before the <rng:interleave> pattern.
10.31. The mandatory Statement 10.31. The 'mandatory' Statement
This statement may appear as a substatement of 'leaf', 'choice' or This statement may appear as a substatement of 'leaf', 'choice' or
'anyxml' statement. If ARGUMENT is "true", the parent data node is 'anyxml' statement. If ARGUMENT is "true", the parent data node is
mapped as mandatory, see Section 9.1.1. mapped as mandatory, see Section 9.1.1.
As a substatement of 'choice', this statement is also mapped to the As a substatement of 'choice', this statement is also mapped to the
@nma:mandatory attribute which is added to PARENT. The value of this @nma:mandatory attribute which is added to PARENT. The value of this
attribute is the argument of the parent 'choice' statement. attribute is the argument of the parent 'choice' statement.
10.32. The max-elements Statement 10.32. The 'max-elements' Statement
This statement is handled within 'leaf-list' or 'list' statements, This statement is handled within 'leaf-list' or 'list' statements,
see Section 10.28. see Section 10.28.
10.33. The min-elements Statement 10.33. The 'min-elements' Statement
This statement is handled within 'leaf-list' or 'list' statements, This statement is handled within 'leaf-list' or 'list' statements,
see Section 10.28. see Section 10.28.
10.34. The module Statement 10.34. The 'module' Statement
This statement is mapped to an embedded <rng:grammar> pattern having This statement is mapped to an embedded <rng:grammar> pattern having
the @nma:module attribute with the value of ARGUMENT. In addition, a the @nma:module attribute with the value of ARGUMENT. In addition, a
<dc:source> element SHOULD be created as a child of this <rng: <dc:source> element SHOULD be created as a child of this <rng:
grammar> element and contain ARGUMENT as a metadata reference to the grammar> element and contain ARGUMENT as a metadata reference to the
input YANG module. See also Section 10.49. input YANG module. See also Section 10.49.
Substatements of the 'module' statement MUST be mapped so that Substatements of the 'module' statement MUST be mapped so that
o statements representing configuration/state data are mapped to o statements representing configuration/state data are mapped to
descendants of the <nma:data> element; descendants of the <nma:data> element;
o statements representing the contents of RPC requests or replies o statements representing the contents of RPC requests or replies
are mapped to descendants of the <nma:rpcs> element; are mapped to descendants of the <nma:rpcs> element;
o statements representing the contents of event notifications are o statements representing the contents of event notifications are
mapped to descendants of the <nma:notifications> element. mapped to descendants of the <nma:notifications> element.
10.35. The must Statement 10.35. The 'must' Statement
This statement is mapped to the <nma:must> element. It has one This statement is mapped to the <nma:must> element. It has one
mandatory attribute @assert (with no namespace) which contains mandatory attribute @assert (with no namespace) which contains
ARGUMENT transformed into a valid XPath expression (see Section 9.3). ARGUMENT transformed into a valid XPath expression (see Section 9.3).
The <nma:must> element may have other subelements resulting from The <nma:must> element may have other subelements resulting from
mapping the 'error-app-tag' and 'error-message' substatements. Other mapping the 'error-app-tag' and 'error-message' substatements. Other
substatements of 'must', i.e., 'description' and 'reference', are substatements of 'must', i.e., 'description' and 'reference', are
ignored. ignored.
EXAMPLE. YANG statement in the "dhcp" module EXAMPLE. YANG statement in the "dhcp" module
skipping to change at page 52, line 38 skipping to change at page 53, line 38
} }
is mapped to is mapped to
<nma:must assert="current()&lt;=../dhcp:max-lease-time"> <nma:must assert="current()&lt;=../dhcp:max-lease-time">
<nma:error-message> <nma:error-message>
The default-lease-time must be less than max-lease-time The default-lease-time must be less than max-lease-time
</nma:error-message> </nma:error-message>
</nma:must> </nma:must>
10.36. The namespace Statement 10.36. The 'namespace' Statement
This statement is mapped in two ways: This statement is mapped in two ways:
1. To the @xmlns:PREFIX attribute of the root <rng:grammar> element 1. To the @xmlns:PREFIX attribute of the root <rng:grammar> element
where PREFIX is the namespace prefix specified by the sibling where PREFIX is the namespace prefix specified by the sibling
'prefix' statement. ARGUMENT becomes the value of this 'prefix' statement. ARGUMENT becomes the value of this
attribute. attribute.
2. To the @ns attribute of PARENT, which is an embedded <rng: 2. To the @ns attribute of PARENT, which is an embedded <rng:
grammar> pattern. ARGUMENT becomes the value of this attribute. grammar> pattern. ARGUMENT becomes the value of this attribute.
10.37. The notification Statement 10.37. The 'notification' Statement
This statement is mapped to the following subtree of the <nma: This statement is mapped to the following subtree of the <nma:
notifications> element in the hybrid schema (where PREFIX is the notifications> element in the hybrid schema (where PREFIX is the
prefix of the local YANG module): prefix of the local YANG module):
<nma:notification> <nma:notification>
<rng:element name="PREFIX:ARGUMENT"> <rng:element name="PREFIX:ARGUMENT">
... ...
</rng:element> </rng:element>
</nma:notification> </nma:notification>
Substatements of 'notification' are mapped under <rng:element Substatements of 'notification' are mapped under <rng:element
name="PREFIX:ARGUMENT">. name="PREFIX:ARGUMENT">.
10.38. The ordered-by Statement 10.38. The 'ordered-by' Statement
This statement is mapped to @nma:ordered-by attribute and ARGUMENT This statement is mapped to @nma:ordered-by attribute and ARGUMENT
becomes the value of this attribute. See Section 10.28 for an becomes the value of this attribute. See Section 10.28 for an
example. example.
10.39. The organization Statement 10.39. The 'organization' Statement
This statement is ignored by the mapping because the hybrid schema This statement is ignored by the mapping because the hybrid schema
may be mapped from multiple YANG modules authored by different may be mapped from multiple YANG modules authored by different
parties. The hybrid schema SHOULD contain references to all input parties. The hybrid schema SHOULD contain references to all input
modules in the Dublin Core <dc:source> elements, see Section 10.34. modules in the Dublin Core <dc:source> elements, see Section 10.34.
The original YANG modules are the authoritative sources of the The original YANG modules are the authoritative sources of the
authorship information. authorship information.
10.40. The output Statement 10.40. The 'output' Statement
This statement is handled within the 'rpc' statement, see This statement is handled within the 'rpc' statement, see
Section 10.50. Section 10.50.
10.41. The path Statement 10.41. The 'path' Statement
This statement is handled within the "leafref" type, see This statement is handled within the "leafref" type, see
Section 10.53.7. Section 10.53.7.
10.42. The pattern Statement 10.42. The 'pattern' 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.43. The position Statement 10.43. The 'position' Statement
This statement is ignored. This statement is ignored.
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 influences the mapping of the parent container This statement influences the mapping of the parent container
(Section 10.11): the parent container definition MUST be wrapped in (Section 10.11): the parent container definition MUST be wrapped in
<rng:optional>, regardless of its contents. See also Section 9.1.1. <rng:optional>, regardless of its contents. See also Section 9.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 MAY be ignored. Otherwise, it is mapped to This statement is mapped to <a:documentation> element and its text is
<a:documentation> element and its text is set to ARGUMENT prefixed set to ARGUMENT prefixed with "See: ".
with "See: ".
10.48. The require-instance Statement 10.48. The 'require-instance' Statement
This statement is handled within "instance-identifier" type This statement is handled within "instance-identifier" type
(Section 10.53.6). (Section 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 [YANG]. This specifies the current revision of the input YANG module [YANG]. This
date SHOULD be recorded, together with the name of the YANG module, date SHOULD be recorded, together with the name of the YANG module,
in the corresponding Dublin Core <dc:source> element (see in the corresponding Dublin Core <dc:source> element (see
Section 10.34), for example in this form: Section 10.34), for example in this form:
<dc:source>YANG module 'foo', revision 2010-03-02</dc:source> <dc:source>YANG module 'foo', revision 2010-03-02</dc:source>
The 'description' substatement of 'revision' is ignored. The 'description' substatement of 'revision' is ignored.
10.50. The rpc Statement 10.50. The 'rpc' Statement
This statement is mapped to the following subtree in the RELAX NG This statement is mapped to the following subtree in the RELAX NG
schema (where PREFIX is the prefix of the local YANG module): schema (where PREFIX is the prefix of the local YANG module):
<nma:rpc> <nma:rpc>
<nma:input> <nma:input>
<rng:element name="PREFIX:ARGUMENT"> <rng:element name="PREFIX:ARGUMENT">
... mapped contents of 'input' ... ... mapped contents of 'input' ...
</rng:element> </rng:element>
</nma:input> </nma:input>
skipping to change at page 55, line 29 skipping to change at page 56, line 24
</nma:rpc> </nma:rpc>
As indicated in the schema fragment, contents of the 'input' As indicated in the schema fragment, contents of the 'input'
substatement (if any) are mapped under <rng:element name="PREFIX: substatement (if any) are mapped under <rng:element name="PREFIX:
ARGUMENT">. Similarly, contents of the 'output' substatement are ARGUMENT">. Similarly, contents of the 'output' substatement are
mapped under <nma:output>. If there is no 'output' substatement, the mapped under <nma:output>. If there is no 'output' substatement, the
<nma:output> element MUST NOT be present. <nma:output> element MUST NOT be present.
The <nma:rpc> element is a child of <nma:rpcs>. The <nma:rpc> element is a child of <nma:rpcs>.
10.51. The status Statement 10.51. The 'status' Statement
This statement MAY be ignored. Otherwise, it is mapped to @nma: This statement MAY be ignored. Otherwise, it is mapped to @nma:
status attribute and ARGUMENT becomes its value. status attribute and ARGUMENT becomes its value.
10.52. The submodule Statement 10.52. The 'submodule' Statement
This statement is not specifically mapped. Its substatements are This statement is not specifically mapped. Its substatements are
mapped as if they appeared directly in the module the submodule mapped as if they appeared directly in the module the submodule
belongs to. belongs to.
10.53. The type Statement 10.53. The 'type' Statement
Most YANG built-in datatypes have an equivalent in the XSD datatype Most YANG built-in datatypes have an equivalent in the XSD datatype
library [XSD-D] as shown in Table 4. library [XSD-D] as shown in Table 4.
+-----------+---------------+--------------------------------+ +-----------+---------------+--------------------------------+
| YANG type | XSD type | Meaning | | YANG type | XSD type | Meaning |
+-----------+---------------+--------------------------------+ +-----------+---------------+--------------------------------+
| int8 | byte | 8-bit integer value | | int8 | byte | 8-bit integer value |
| | | | | | | |
| int16 | short | 16-bit integer value | | int16 | short | 16-bit integer value |
skipping to change at page 56, line 46 skipping to change at page 57, line 46
derived types in the standard modules [Ytypes]: "date-and-time" in derived types in the standard modules [Ytypes]: "date-and-time" in
the "ietf-yang-types" module and "uri" in the "ietf-inet-types" the "ietf-yang-types" module and "uri" in the "ietf-inet-types"
module. However, the formal restrictions in the YANG type module. However, the formal restrictions in the YANG type
definitions are rather weak. Therefore, implementations of the YANG- definitions are rather weak. Therefore, implementations of the YANG-
to-DSDL mapping SHOULD detect these derived types in source YANG to-DSDL mapping SHOULD detect these derived types in source YANG
modules and map them to "dateType" and "anyURI", respectively. modules and map them to "dateType" and "anyURI", respectively.
Details about the mapping of individual YANG built-in types are given Details about the mapping of individual YANG built-in types are given
in the following subsections. in the following subsections.
10.53.1. The empty Type 10.53.1. The "empty" Type
This type is mapped to <rng:empty/>. This type is mapped to <rng:empty/>.
10.53.2. The boolean and binary Types 10.53.2. The "boolean" and "binary" Types
These two built-in types do not allow any restrictions and are mapped These two built-in types do not allow any restrictions and are mapped
simply by inserting <rng:data> element whose @type attribute is set simply by inserting <rng:data> element whose @type attribute is set
to ARGUMENT mapped according to Table 4 above. to ARGUMENT mapped according to Table 4 above.
10.53.3. The bits Type 10.53.3. The "bits" Type
This type is mapped to <rng:list> and for each 'bit' substatement the This type is mapped to <rng:list> and for each 'bit' substatement the
following XML fragment is inserted as a child of <rng:list>: following XML fragment is inserted as a child of <rng:list>:
<rng:optional> <rng:optional>
<rng:value>bit_name</rng:value> <rng:value>bit_name</rng:value>
</rng:optional> </rng:optional>
where bit_name is the name of the bit as found in the argument of a where bit_name is the name of the bit as found in the argument of a
'bit' substatement. 'bit' substatement.
10.53.4. The enumeration and union Types 10.53.4. The "enumeration" and "union" Types
These types are mapped to the <rng:choice> element. These types are mapped to the <rng:choice> element.
10.53.5. The identityref Type 10.53.5. The "identityref" Type
This type is mapped to the following named pattern reference: This type is mapped to the following named pattern reference:
<rng:ref name="__PREFIX_BASE"/> <rng:ref name="__PREFIX_BASE"/>
where PREFIX:BASE is the qualified name of the identity appearing in where PREFIX:BASE is the qualified name of the identity appearing in
the argument of the 'base' substatement. the argument of the 'base' substatement.
For example, assume that module "des" in Section 10.21 contains the For example, assume that module "des" in Section 10.21 contains the
following leaf definition: following leaf definition:
skipping to change at page 58, line 5 skipping to change at page 59, line 5
base crypto:crypto-alg; base crypto:crypto-alg;
} }
} }
This leaf would then be mapped to the following element pattern: This leaf would then be mapped to the following element pattern:
<element name="des:foo"> <element name="des:foo">
<ref name="__crypto_crypto-alg"/> <ref name="__crypto_crypto-alg"/>
</element> </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, an empty <nma:instance-identifier> element "string". In addition, an empty <nma:instance-identifier> element
MUST be inserted as a child of PARENT. MUST be inserted as a child of PARENT.
The argument of the 'require-instance' substatement, if it exists, The argument of the 'require-instance' substatement, if it exists,
becomes the value of the @require-instance attribute of the <nma: becomes the value of the @require-instance attribute of the <nma:
instance-identifier> element. instance-identifier> element.
10.53.7. The leafref Type 10.53.7. The "leafref" Type
This type is mapped exactly as the type of the leaf given in the This type is mapped exactly as the type of the leaf given in the
argument of 'path' substatement. However, if the type of the argument of 'path' substatement. However, if the type of the
referred leaf defines a default value, this default value MUST be referred leaf defines a default value, this default value MUST be
ignored by the mapping. ignored by the mapping.
In addition, @nma:leafref attribute MUST be added to PARENT. The In addition, @nma:leafref attribute MUST be added to PARENT. The
argument of the 'path' substatement, translated according to argument of the 'path' substatement, translated according to
Section 9.3, is set as the value of this attribute. Section 9.3, is set as the value of this attribute.
10.53.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" and "decimal64". They are "uint8", "uint16", "uint32", "uint64" and "decimal64". They are
mapped to <rng:data> element with @type attribute set to ARGUMENT mapped to <rng:data> element with @type attribute set to ARGUMENT
translated according to Table 4 above. translated according to Table 4 above.
An exception is the "decimal64" type, which is mapped to the An exception is the "decimal64" type, which is mapped to the
"decimal" type of the XSD datatype library. Its precision and number "decimal" type of the XSD datatype library. Its precision and number
of fractional digits are controlled with the following facets, which of fractional digits are controlled with the following facets, which
MUST always be present: MUST always be present:
skipping to change at page 60, line 21 skipping to change at page 61, line 21
<rng:param name="minInclusive">42</rng:param> <rng:param name="minInclusive">42</rng:param>
<rng:param name="maxInclusive">42</rng:param> <rng:param name="maxInclusive">42</rng:param>
</rng:data> </rng:data>
<rng:data type="int"> <rng:data type="int">
<rng:param name="minInclusive">100</rng:param> <rng:param name="minInclusive">100</rng:param>
</rng:data> </rng:data>
</rng:choice> </rng:choice>
See Section 9.2.2 for further details on mapping the restrictions. See Section 9.2.2 for further details on mapping the restrictions.
10.53.9. The string Type 10.53.9. The "string" Type
This type is mapped to <rng:data> element with the @type attribute This type is mapped to <rng:data> element with the @type attribute
set to "string". set to "string".
The 'length' restriction is handled analogically to the 'range' The 'length' restriction is handled analogically to the 'range'
restriction for the numeric types (Section 10.53.8): restriction for the numeric types (Section 10.53.8):
If the length expression has just a single range, then If the length expression has just a single range, then
o if the length range consists of a single number LENGTH, the o if the length range consists of a single number LENGTH, the
skipping to change at page 62, line 15 skipping to change at page 63, line 15
2. If any restrictions are present, the ancestor built-in type for 2. If any restrictions are present, the ancestor built-in type for
the given derived type must be determined and the mapping of this the given derived type must be determined and the mapping of this
base type MUST be used. Restrictions appearing at all stages of base type MUST be used. Restrictions appearing at all stages of
the type derivation chain MUST be taken into account and their the type derivation chain MUST be taken into account and their
conjunction added to the <rng:data> element which defines the conjunction added to the <rng:data> element which defines the
basic type. basic type.
See Section 9.2.2 for more details and an example. See Section 9.2.2 for more details and an example.
10.54. The typedef Statement 10.54. The 'typedef' Statement
This statement is mapped to a RELAX NG named pattern definition <rng: This statement is mapped to a RELAX NG named pattern definition <rng:
define>, but only if the type defined by this statement is used define>, but only if the type defined by this statement is used
without restrictions in at least one of the input modules. In this without restrictions in at least one of the input modules. In this
case, the named pattern definition becomes a child of either the root case, the named pattern definition becomes a child of either the root
or an embedded <rng:grammar> element, depending on whether the or an embedded <rng:grammar> element, depending on whether the
'typedef' statement appears at the top level of a YANG module or not. 'typedef' statement appears at the top level of a YANG module or not.
The name of this named pattern definition is set to ARGUMENT mangled The name of this named pattern definition is set to ARGUMENT mangled
according to the rules specified in Section 9.2. according to the rules specified in Section 9.2.
skipping to change at page 62, line 37 skipping to change at page 63, line 37
ancestor built-in type for the derived type is used instead with ancestor built-in type for the derived type is used instead with
restrictions (facets) that are a combination of all restrictions restrictions (facets) that are a combination of all restrictions
specified along the type derivation chain. See Section 10.53.10 for specified along the type derivation chain. See Section 10.53.10 for
further details and an example. further details and an example.
An implementation MAY offer the option of recording all 'typedef' An implementation MAY offer the option of recording all 'typedef'
statements as named patterns in the output RELAX NG schema even if statements as named patterns in the output RELAX NG schema even if
they are not referenced. This is useful for mapping YANG "library" they are not referenced. This is useful for mapping YANG "library"
modules containing only 'typedef' and/or 'grouping' statements. modules containing only 'typedef' and/or 'grouping' statements.
10.55. The unique Statement 10.55. The 'unique' Statement
This statement is mapped to @nma:unique attribute. ARGUMENT MUST be This statement is mapped to @nma:unique attribute. ARGUMENT MUST be
translated so that every node identifier in each of its components is translated so that every node identifier in each of its components is
prefixed with the namespace prefix of the local module, unless the prefixed with the namespace prefix of the local module, unless the
prefix is already present. The result of this translation then prefix is already present. The result of this translation then
becomes the value of the @nma:unique attribute. becomes the value of the @nma:unique attribute.
For example, assuming that the local module prefix is "ex", For example, assuming that the local module prefix is "ex",
unique "foo ex:bar/baz" unique "foo ex:bar/baz"
is mapped to the following attribute/value pair: is mapped to the following attribute/value pair:
nma:unique="ex:foo ex:bar/ex:baz" nma:unique="ex:foo ex:bar/ex:baz"
10.56. The units Statement 10.56. The 'units' Statement
This statement is mapped to @nma:units attribute and ARGUMENT becomes This statement is mapped to @nma:units attribute and ARGUMENT becomes
its value. Implementations MAY ignore this statement. its value.
10.57. The uses Statement 10.57. The 'uses' Statement
If this statement has neither 'refine' nor 'augment' substatements, If this statement has neither 'refine' nor 'augment' substatements,
it is mapped to <rng:ref> element, i.e., a reference to a named it is mapped to <rng:ref> element, i.e., a reference to a named
pattern, and the value of its @name attribute is set to ARGUMENT pattern, and the value of its @name attribute is set to ARGUMENT
mangled according to Section 9.2. If the RELAX NG definition of the mangled according to Section 9.2. If the RELAX NG definition of the
referenced named pattern has not been added to the hybrid schema yet, referenced named pattern has not been added to the hybrid schema yet,
the corresponding grouping MUST be found and its mapping installed as the corresponding grouping MUST be found and its mapping installed as
a subelement of <rng:grammar>, see Section 10.20. a subelement of <rng:grammar>, see Section 10.20.
Otherwise, if the 'uses' statement has any 'refine' or 'augment' Otherwise, if the 'uses' statement has any 'refine' or 'augment'
substatements, the corresponding grouping must be looked up and its substatements, the corresponding grouping must be looked up and its
contents inserted under PARENT. See Section 9.2.1 for further contents inserted under PARENT. See Section 9.2.1 for further
details and an example. details and an example.
10.58. The value Statement 10.58. The 'value' Statement
This statement is ignored. This statement is ignored.
10.59. The when Statement 10.59. The 'when' Statement
This statement is mapped to @nma:when attribute and ARGUMENT, This statement is mapped to @nma:when attribute and ARGUMENT,
translated according to Section 9.3, becomes it value. translated according to Section 9.3, becomes it value.
10.60. The yang-version Statement 10.60. The 'yang-version' Statement
This statement is not mapped to the output schema. However, an This statement is not mapped to the output schema. However, an
implementation SHOULD check that it is compatible with the YANG implementation SHOULD check that it is compatible with the YANG
version declared by the statement (currently version 1). version declared by the statement (currently version 1). In the case
of a mismatch, the implementation SHOULD report an error and
terminate.
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
for extension handling in Section 9.4. for extension handling in Section 9.4.
11. Mapping the Hybrid Schema to DSDL 11. Mapping the Hybrid Schema to DSDL
As explained in Section 6, the second step of the YANG-to-DSDL As explained in Section 6, the second step of the YANG-to-DSDL
mapping takes the hybrid schema and transforms it to various DSDL mapping takes the hybrid schema and transforms it to various DSDL
schemas capable of validating instance XML documents. As an input schemas capable of validating instance XML documents. As an input
parameter, this step takes, in the simplest case, just a parameter, this step takes, in the simplest case, just a
specification of the NETCONF XML document type that is to be specification of the NETCONF XML document type that is to be
validated. These document types can be, for example, the contents of validated. These document types can be, for example, the contents of
a datastore, a reply to <nc:get> or <nc:get-config>, contents of a datastore, a reply to <nc:get> or <nc:get-config>, contents of
other RPC requests/replies and event notifications, and so on. other RPC requests/replies and event notifications, and so on.
In general, the second mapping step has to accomplish the following The second mapping step has to accomplish the following three general
three tasks: tasks:
1. Extract the parts of the hybrid schema that are appropriate for 1. Extract the parts of the hybrid schema that are appropriate for
the requested document type. For example, if a <nc:get> reply is the requested document type. For example, if a <nc:get> reply is
to be validated, the subtree under <nma:data> has to be selected. to be validated, the subtree under <nma:data> has to be selected.
2. The schema must be adapted to the specific encapsulating XML 2. The schema must be adapted to the specific encapsulating XML
elements mandated by the RPC layer. These are, for example, <nc: elements mandated by the RPC layer. These are, for example, <nc:
rpc> and <nc:data> elements in the case of a <nc:get> reply or rpc> and <nc:data> elements in the case of a <nc:get> reply or
<en:notification> for a notification. <en:notification> for a notification.
skipping to change at page 75, line 12 skipping to change at page 76, line 12
ignored because "leaf3" represents a non-default alternative of a ignored because "leaf3" represents a non-default alternative of a
choice and as such never becomes an implicit element. choice and as such never becomes an implicit element.
12. Mapping NETMOD-specific Annotations to DSDL Schema Languages 12. Mapping NETMOD-specific Annotations to DSDL Schema Languages
This section contains the mapping specification for the individual This section contains the mapping specification for the individual
NETMOD-specific annotations. In each case, the result of the mapping NETMOD-specific annotations. In each case, the result of the mapping
must be inserted into an appropriate context of the target DSDL must be inserted into an appropriate context of the target DSDL
schema as described in Section 11. The context is determined by the schema as described in Section 11. The context is determined by the
element pattern in the hybrid schema to which the annotation is element pattern in the hybrid schema to which the annotation is
attached. In the rest of this section, we will denote CONTELEM the attached. In the rest of this section, CONTELEM will denote the name
name of this context element properly qualified with its namespace of this context element properly qualified with its namespace prefix.
prefix.
12.1. The @nma:config Annotation 12.1. The @nma:config Annotation
If this annotation is present with the value of "false", the If this annotation is present with the value of "false", the
following rules MUST be observed for DSDL schemas of <nc:get-config> following rules MUST be observed for DSDL schemas of <nc:get-config>
reply: reply:
o When generating RELAX NG, the contents of the CONTELEM definition o When generating RELAX NG, the contents of the CONTELEM definition
MUST be changed to <rng:notAllowed>. MUST be changed to <rng:notAllowed>.
skipping to change at page 76, line 23 skipping to change at page 77, line 23
the value of "false", it is ignored. Otherwise it is mapped to the the value of "false", it is ignored. Otherwise it is mapped to the
following Schematron assert: following Schematron assert:
<sch:assert test="nmf:evaluate(.)"> <sch:assert test="nmf:evaluate(.)">
The element pointed to by "CONTELEM" must exist. The element pointed to by "CONTELEM" must exist.
</sch:assert> </sch:assert>
The nmf:evaluate() function is an XSLT extension function (see The nmf:evaluate() function is an XSLT extension function (see
Extension Functions in [XSLT]) that evaluates an XPath expression at Extension Functions in [XSLT]) that evaluates an XPath expression at
run time. Such an extension function is provided by some XSLT run time. Such an extension function is provided by some XSLT
processors, for example Saxon [3]. processors, for example Saxon [Saxon].
12.8. The @nma:key Annotation 12.8. The @nma:key Annotation
Assume this annotation attribute contains "k_1 k_2 ... k_n", i.e., Assume this annotation attribute contains "k_1 k_2 ... k_n", i.e.,
specifies n children of CONTELEM as list keys. The annotation is specifies n children of CONTELEM as list keys. The annotation is
then mapped to the following Schematron report: then mapped to the following Schematron report:
<sch:report test="CONDITION"> <sch:report test="CONDITION">
Duplicate key of list "CONTELEM" Duplicate key of list "CONTELEM"
</sch:report> </sch:report>
skipping to change at page 79, line 7 skipping to change at page 80, line 7
This annotation is mapped to the following Schematron assert: This annotation is mapped to the following Schematron assert:
<sch:assert test="EXPRESSION"> <sch:assert test="EXPRESSION">
Node "CONTELEM" is only valid when "EXPRESSION" is true. Node "CONTELEM" is only valid when "EXPRESSION" is true.
</sch:assert> </sch:assert>
where EXPRESSION is the value of @nma:when. where EXPRESSION is the value of @nma:when.
13. IANA Considerations 13. IANA Considerations
This document registers three namespace URIs in the IETF XML registry This document registers two namespace URIs in the IETF XML registry
[RFC3688]: [RFC3688]:
URI: urn:ietf:params:xml:ns:netmod:dsdl-annotations:1 URI: urn:ietf:params:xml:ns:netmod:dsdl-annotations:1
URI: urn:ietf:params:xml:ns:netmod:xpath-extensions:1 URI: urn:ietf:params:xml:ns:netmod:xpath-extensions:1
14. Security Considerations 14. Security Considerations
This document defines a procedure that maps data models expressed in This document defines a procedure that maps data models expressed in
the YANG language to a coordinated set of DSDL schemas. The the YANG language to a coordinated set of DSDL schemas. The
procedure itself has no security impact on the Internet. procedure itself has no security impact on the Internet.
skipping to change at page 81, line 9 skipping to change at page 82, line 9
validating the contents of NETCONF messages or entire datastores and validating the contents of NETCONF messages or entire datastores and
thus provide additional validity checks above those performed by thus provide additional validity checks above those performed by
NETCONF server and client implementations supporting YANG data NETCONF server and client implementations supporting YANG data
models. The strictness of this validation is directly derived from models. The strictness of this validation is directly derived from
the source YANG modules that the validated XML data adhere to. the source YANG modules that the validated XML data adhere to.
15. Acknowledgments 15. Acknowledgments
The authors wish to thank the following individuals who provided The authors wish to thank the following individuals who provided
helpful suggestions and/or comments on various versions of this helpful suggestions and/or comments on various versions of this
document: Andy Bierman, Martin Bjorklund, Jirka Kosek and Phil document: Andy Bierman, Martin Bjorklund, Jirka Kosek, Juergen
Shafer. Schoenwaelder and Phil Shafer.
16. References 16. References
16.1. Normative References 16.1. Normative References
[DSDL] ISO/IEC, "Document Schema Definition Languages (DSDL) - [DSDL] ISO/IEC, "Document Schema Definition Languages (DSDL) -
Part 1: Overview", ISO/IEC 19757-1, 11 2004. Part 1: Overview", ISO/IEC 19757-1, November 2004.
[DSRL] ISO/IEC, "Information Technology - Document Schema [DSRL] ISO/IEC, "Information Technology - Document Schema
Definition Languages (DSDL) - Part 8: Document Semantics Definition Languages (DSDL) - Part 8: Document Semantics
Renaming Language - DSRL", ISO/IEC 19757-8:2008(E), Renaming Language - DSRL", ISO/IEC 19757-8:2008(E),
12 2008. December 2008.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004. January 2004.
[RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741, [RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741,
December 2006. December 2006.
[RFC5013] Kunze, J., "The Dublin Core Metadata Element Set",
RFC 5013, August 2007.
[RNG] ISO/IEC, "Information Technology - Document Schema [RNG] ISO/IEC, "Information Technology - Document Schema
Definition Languages (DSDL) - Part 2: Regular-Grammar- Definition Languages (DSDL) - Part 2: Regular-Grammar-
Based Validation - RELAX NG. Second Edition.", ISO/ Based Validation - RELAX NG. Second Edition.", ISO/
IEC 19757-2:2008(E), 12 2008. IEC 19757-2:2008(E), December 2008.
[RNG-CS] ISO/IEC, "Information Technology - Document Schema [RNG-CS] ISO/IEC, "Information Technology - Document Schema
Definition Languages (DSDL) - Part 2: Regular-Grammar- Definition Languages (DSDL) - Part 2: Regular-Grammar-
Based Validation - RELAX NG. AMENDMENT 1: Compact Syntax", Based Validation - RELAX NG. AMENDMENT 1: Compact Syntax",
ISO/IEC 19757-2:2003/Amd. 1:2006(E), 1 2006. ISO/IEC 19757-2:2003/Amd. 1:2006(E), January 2006.
[RNG-DTD] Clark, J., Ed. and M. Murata, Ed., "RELAX NG DTD [RNG-DTD] Clark, J., Ed. and M. Murata, Ed., "RELAX NG DTD
Compatibility", OASIS Committee Specification 3 December Compatibility", OASIS Committee Specification 3 December
2001, December 2001. 2001, December 2001.
[Schematron] [Schematron]
ISO/IEC, "Information Technology - Document Schema ISO/IEC, "Information Technology - Document Schema
Definition Languages (DSDL) - Part 3: Rule-Based Definition Languages (DSDL) - Part 3: Rule-Based
Validation - Schematron", ISO/IEC 19757-3:2006(E), 6 2006. Validation - Schematron", ISO/IEC 19757-3:2006(E),
June 2006.
[XML] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and [XML] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and
F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth
Edition)", World Wide Web Consortium Recommendation REC- Edition)", World Wide Web Consortium Recommendation REC-
xml-20081126, November 2008, xml-20081126, November 2008,
<http://www.w3.org/TR/2006/REC-xml-20060816>. <http://www.w3.org/TR/2006/REC-xml-20060816>.
[XML-INFOSET] [XML-INFOSET]
Tobin, R. and J. Cowan, "XML Information Set (Second Tobin, R. and J. Cowan, "XML Information Set (Second
Edition)", World Wide Web Consortium Recommendation REC- Edition)", World Wide Web Consortium Recommendation REC-
skipping to change at page 83, line 35 skipping to change at page 84, line 33
[YANG] Bjorklund, M., Ed., "YANG - A data modeling language for [YANG] Bjorklund, M., Ed., "YANG - A data modeling language for
NETCONF", draft-ietf-netmod-yang-13 (work in progress), NETCONF", draft-ietf-netmod-yang-13 (work in progress),
June 2010. June 2010.
[Ytypes] Schoenwaelder, J., Ed., "Common YANG Data Types", [Ytypes] Schoenwaelder, J., Ed., "Common YANG Data Types",
draft-ietf-netmod-yang-types-09 (work in progress), draft-ietf-netmod-yang-types-09 (work in progress),
April 2010. April 2010.
16.2. Informative References 16.2. Informative References
[DHCPtut] Bjorklund, M., "DHCP Tutorial", November 2007, <http://
www.yang-central.org/twiki/bin/view/Main/DhcpTutorial>.
[RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin,
"Simple Network Management Protocol (SNMP)", STD 15, "Simple Network Management Protocol (SNMP)", STD 15,
RFC 1157, May 1990. RFC 1157, May 1990.
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Structure of Management Information Schoenwaelder, Ed., "Structure of Management Information
Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[RFC3216] Elliott, C., Harrington, D., Jason, J., Schoenwaelder, J., [RFC5013] Kunze, J., "The Dublin Core Metadata Element Set",
Strauss, F., and W. Weiss, "SMIng Objectives", RFC 3216, RFC 5013, August 2007.
December 2001.
[RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event
Notifications", RFC 5277, July 2008. Notifications", RFC 5277, July 2008.
[Saxon] Saxonica, Ltd., "Saxon Extensions", March 2004,
<http://saxon.sourceforge.net/saxon7.9.1/extensions.html>.
[Trang] Clark, J., "Trang: Multiformat schema converter based on
RELAX NG", 2008,
<http://www.thaiopensource.com/relaxng/trang.html>.
[Vli04] van der Vlist, E., "RELAX NG", O'Reilly , 2004. [Vli04] van der Vlist, E., "RELAX NG", O'Reilly , 2004.
[XSD] Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, [XSD] Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn,
"XML Schema Part 1: Structures Second Edition", World Wide "XML Schema Part 1: Structures Second Edition", World Wide
Web Consortium Recommendation REC-xmlschema-1-20041028, Web Consortium Recommendation REC-xmlschema-1-20041028,
October 2004, October 2004,
<http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>. <http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>.
URIs [pyang] Bjorklund, M. and L. Lhotka, "pyang: An extensible YANG
validator and converter in Python", 2010,
[1] <http://www.thaiopensource.com/relaxng/trang.html> <http://code.google.com/p/pyang/>.
[2] <http://dublincore.org/>
[3] <http://www.saxonica.com/>
[4] <http://www.yang-central.org/twiki/bin/view/Main/DhcpTutorial>
[5] <http://code.google.com/p/pyang/>
Appendix A. RELAX NG Schema for NETMOD-Specific Annotations Appendix A. RELAX NG Schema for NETMOD-Specific Annotations
This appendix defines the content model for all NETMOD-specific This appendix defines the content model for all NETMOD-specific
annotations in the form of RELAX NG named pattern definitions. annotations in the form of RELAX NG named pattern definitions.
<CODE BEGINS> file "nmannot.rng" <CODE BEGINS> file "nmannot.rng"
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<grammar xmlns="http://relaxng.org/ns/structure/1.0" <grammar xmlns="http://relaxng.org/ns/structure/1.0"
skipping to change at page 92, line 8 skipping to change at page 92, line 8
<data type="dateTime"/> <data type="dateTime"/>
</element> </element>
</define> </define>
</grammar> </grammar>
<CODE ENDS> <CODE ENDS>
Appendix C. Mapping DHCP Data Model - A Complete Example Appendix C. Mapping DHCP Data Model - A Complete Example
This appendix demonstrates both steps of the YANG-to-DSDL mapping This appendix demonstrates both steps of the YANG-to-DSDL mapping
applied to the "canonical" DHCP tutorial [4] data model. The single applied to the "canonical" DHCP tutorial [DHCPtut] data model. The
input YANG module is shown in Appendix C.1 and the output schemas in input YANG module is shown in Appendix C.1 and the output schemas in
the following two subsections. the following two subsections.
The hybrid schema was obtained by the "dsdl" plugin of the pyang [5] The hybrid schema was obtained by the "dsdl" plugin of the pyang tool
tool and the validating DSDL schemas obtained by XSLT stylesheets [pyang] and the validating DSDL schemas were obtained by XSLT
that are also part of pyang distribution. stylesheets that are also part of pyang distribution.
Due to the limit of 72 characters per line, a few long strings Due to the limit of 72 characters per line, a few long strings
required manual editing, in particular the regular expression required manual editing, in particular the regular expression
patterns for IP addresses etc. These were replaced by the patterns for IP addresses etc. These were replaced by the
placeholder string "... regex pattern ...". Also, line breaks were placeholder string "... regex pattern ...". Also, line breaks were
added to several documentation strings and Schematron messages. added to several documentation strings and Schematron messages.
Other than that, the results of the automatic translations were not Other than that, the results of the automatic translations were not
changed. changed.
C.1. Input YANG Module C.1. Input YANG Module
skipping to change at page 107, line 7 skipping to change at page 107, 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 -05 and -06 RFC Editor: remove this section upon publication as an RFC.
D.1. Changes Between Versions -06 and -07
o Mapping of 'description', 'reference' and 'units' to the hybrid
schema is now mandatory.
o Improvements and fixes of the text based on the AD review
D.2. Changes Between Versions -05 and -06
o Terminology change: "conceptual tree schema" -> "hybrid schema". o Terminology change: "conceptual tree schema" -> "hybrid schema".
o Changed sectioning markers in the hybrid schema into plain NETMOD- o Changed sectioning markers in the hybrid schema into plain NETMOD-
specific annotations. Hence the former "nmt" namespace is not specific annotations. Hence the former "nmt" namespace is not
used at all. used at all.
o Added the following NETMOD-specific annotations: @nma:if-feature, o Added the following NETMOD-specific annotations: @nma:if-feature,
@nma:leaf-list, @nma:mandatory, @nma:module, removed @nma: @nma:leaf-list, @nma:mandatory, @nma:module, removed @nma:
presence. presence.
skipping to change at page 107, line 40 skipping to change at page 108, line 5
o DHCP example: All RNG schemas are only in the XML syntax. Added o DHCP example: All RNG schemas are only in the XML syntax. Added
RNG with global definitions. RNG with global definitions.
o Added [XML-INFOSET] to normative references. o Added [XML-INFOSET] to normative references.
o Listed the terms that are defined in other documents. o Listed the terms that are defined in other documents.
o The schema for NETMOD-specific annotation is now given only as RNG o The schema for NETMOD-specific annotation is now given only as RNG
named pattern definitions, no more in NVDL. named pattern definitions, no more in NVDL.
D.2. Changes Between Versions -04 and -05
o Removed NS prefix from document element name of the DOCTYPE
declaration in the NVDL schema.
D.3. Changes Between Versions -04 and -05 D.3. Changes Between Versions -04 and -05
o Leafs that take their default value from a typedef and are not o Leafs that take their default value from a typedef and are not
annotated with @nma:default must have @nma:implicit="true". annotated with @nma:default must have @nma:implicit="true".
o Changed code markers CODE BEGINS/ENDS to the form agreed by the o Changed code markers CODE BEGINS/ENDS to the form agreed by the
WG. WG.
o Derived types "date-and-time" and "uri" SHOULD be mapped to XSD o Derived types "date-and-time" and "uri" SHOULD be mapped to XSD
"dateTime" and "anyURI" types, respectively. "dateTime" and "anyURI" types, respectively.
 End of changes. 112 change blocks. 
294 lines changed or deleted 304 lines changed or added

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