YANG YANG YANG

The schema.act module, which implements the core of the YANG schema in, is generated from the YANG RFC 7950 by rfcgen.act. The output is concatenated with a manually written top half, in schema-manual.act

Compile

make

Things we should do (TO DO) [2/26]

• [X] TODO: drop y_ prefix
• [X] TODO: group multiple YANG modules into a tree so that the generated output has a common root for multiple modules
• [x] TODO: use DNode
• [ ] TODO: support all leaf types
  • [ ] actually support all leaf types
  • [ ] write comprehensive tests for input YANG
• [ ] TODO: populate namespace / prefix in stmt_to_snode
• [x] TODO: support schema expansion of uses / groupings
• [x] TODO: support expanding of types to the base type
• [x] TODO: support YANG parsing of multiple modules, like for imports and augment
• [x] TODO: support schema expansion of augments
• [x] TODO: rewrite - to _ in names
• [x] TODO: resolve union of various int types to largest (u)int
• [ ] TODO: detect conflicts between a_b and a-b, and name in some deterministic fashion
• [x] TODO: add simple compile() function to compile a bundle of YANG models and get a DNode tree
• [x] TODO: fix bug, duplicating content when revision statement is present
• [x] TODO: correctly map union base type, currently getting “string” and not “str” as it should be
• [ ] TODO: add test for expansion of uses/grouping, where same grouping is used in two places but in one place it is modified - we need to get copies of the content of the grouping, not mutate the grouping by “moving” it (rewriting parent etc) into uses location
• [ ] TODO: compilation must consider import dependencies when compiling modules, compile in order of dependencies!
• [ ] TODO: compilation of augments must be ordered, in a single module we can have a container /c1, then first augment which augments target path /c1 and adds in container c2, e.g. /c1/c2, then a second augment with target path /c1/c2 and adds in a third container c3 in there. Now consider the order of the augments in the YANG module, they could be in arbitrary order. We must compile the augments in order - simplest approach is to order augments by target path length, starting with shortest?
• [x] TODO: support submodules
• [ ] TODO: support submodules with different prefix than parent module or some advanced setup like that? not sure exactly what the test case should look like…
• [ ] TODO: when printing data classes, do not expand groupings into the specific path but use single Acton class that maps to grouping and reuse that in multiple places - only works when the uses is unmodified, i.e. no refines or whatnot
• [ ] TODO: check conflicts when merging submodule content into main module
• [ ] TODO: add conflicting node names, like two children called “c1” under the same container
• [ ] TODO: propagate namespace & prefix through SchemaNode tree
• [ ] TODO: augment should use prefix when resolving nodes so we can augment correct node based on namespace
  • prefix are resolved from the perspective of the module that contains the augment statement
    • but nodes are placed in target path module
      • thus all nodes in target module need to have namespace so we can correct