|
3 | 3 |
|
4 | 4 | **Contributors:** Anees Shaikh, Rob Shakir, Kristian Larsson, Darren Loher |
5 | 5 | **October 26, 2015**<br> |
6 | | -*Updated: June 12, 2025* |
| 6 | +*Updated: January 9th 2026* |
7 | 7 |
|
8 | 8 | ## Background |
9 | 9 | This document describes conventions adopted in the OpenConfig operator group |
@@ -49,6 +49,7 @@ and released soon. |
49 | 49 | - [`choice`](#choice) |
50 | 50 | - [XPath](#xpath) |
51 | 51 | - [Regular expressions](#regular-expressions) |
| 52 | + - [Schema Usability](#schema-usability) |
52 | 53 | - [Appendix](#appendix) |
53 | 54 | - [Example groupings for containers](#example-groupings-for-containers) |
54 | 55 | - [OpenConfig YANG module template](#openconfig-yang-module-template) |
@@ -476,6 +477,40 @@ reference for [regular |
476 | 477 | expressions](http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#regexs). |
477 | 478 | However, this is not a commonly used standard for implementors. |
478 | 479 |
|
| 480 | +## Schema Usability |
| 481 | + |
| 482 | +Some elements of the OpenConfig style guide are implemented in order to provide |
| 483 | +consistent programmatic handling of the schema. For instance, the `config` and |
| 484 | +`state` containers used for operational state, and surrounding containers for |
| 485 | +YANG `list` statements. In some cases (e.g., programmatically generating |
| 486 | +configuration), this schema verbosity negatively impacts usability -- e.g., |
| 487 | +requiring programmers to reference longer paths than are necessary. Tooling |
| 488 | +generating programmatic APIs around OpenConfig can improve usability by |
| 489 | +transforming the schema. Such transformations rely on consistency in the |
| 490 | +modelling approach. |
| 491 | + |
| 492 | +The following rules MUST be adhered to within the OpenConfig models to |
| 493 | +ensure that downstream tooling does not break. |
| 494 | + |
| 495 | +* **A `list` node MUST NOT share its identifier with any sibling of its |
| 496 | + parent container.** It is not legal for `/a/foos/foo` and `/a/foo` to |
| 497 | + exist, or for `/interfaces/interface` and `/interface` to exist, where |
| 498 | + `/a/foos/foo` and `/interfaces/interface` are `list` nodes. This rule |
| 499 | + exists to allow the (style-guide-required) "surrounding" container of a |
| 500 | + list to be removed during schema transformation. |
| 501 | +* **A leaf node MUST NOT share its identifier with any of the children of |
| 502 | + its grandparent node.** It is not legal for `/a/config/leaf` and `/a/leaf` |
| 503 | + to both exist nor for `/b/state/leaf` and `/b/leaf` to both exist. The |
| 504 | + single exception to this rule is the OpenConfig list key pattern: a leaf |
| 505 | + inside the `config` or `state` container is permitted to share its name |
| 506 | + with the `leafref` node acting as the `key` of the parent list. The node |
| 507 | + acting as the key of the `list` MUST be of type `leafref` as specified |
| 508 | + elsewhere in this guide. This rule ensures that the `config` and `state` |
| 509 | + containers can be removed during schema transformation. |
| 510 | + |
| 511 | +An example of programmatic compression is implemented for the generation of |
| 512 | +code in ygot -- both for Go and Protobuf artifact generation |
| 513 | +([reference](https://github.com/openconfig/ygot/blob/master/docs/design.md#openconfig-path-compression)). |
479 | 514 |
|
480 | 515 | ## Appendix |
481 | 516 |
|
|
0 commit comments