ModuleSet cases analysis

Table of contents

1 Using multiple YANG files cases
- 1.1 Augmentation
  - 1.1.1 base.yang
  - 1.1.2 augment.yang
  - 1.1.3 augment.json
- 1.2 Imports
  - 1.2.1 importer.yang
  - 1.2.2 exporter.yang
  - 1.2.3 importer.json (valid)
  - 1.2.4 exporter.json (also valid)
- 1.3 Assembly
  - 1.3.1 assembly.yang
  - 1.3.2 component.yang
  - 1.3.3 assembly-1.json (valid)
  - 1.3.4 assembly-2.json (also valid)
  - 1.3.5 assembly.json (invalid)
2 Data tree root mismatches model root issue
- 2.1 Issue description

Addresses CPS-43: VSE: Introduce Module Sets (groups of modules)Closed

Using multiple YANG files cases

Below are most common cases expected to be handled.
Sample files were used to validate the expected flows and possible issues.

The sample files are attached here yang-test.zip

Augmentation

The augmentation is mainly used to extends an existing model. The augmentation is encapsulated within separate
module file, having own namespace and revision. Example:

base.yang

module base {
    yang-version 1.1;

    namespace "org:onap:cps:test:base";
    revision "2020-01-01";
    prefix "base";

    container base-container {
        leaf name {
            type string;
        }
        leaf description {
            type string;
        }
    }
}

augment.yang

module augment {
    yang-version 1.1;

    namespace "org:onap:cps:test:augment";
    revision "2020-01-02";
    prefix "augment";

    import base {
        prefix "base";
    }

    grouping augment-group {
         leaf augmented-leaf {
             type string;
         }
    }

    augment "base:base-container" {
        uses augment-group;
    }
}

augment.json

{
  "base-container": {
    "name": "test name",
    "description": "test description",
    "augmented-leaf": "more information"
  }
}

Empty module issue

When files are processed the effective schema context the target model is referenced by name, namespace and revision of a base module, which are not
changed and remain same. At the same time the augment module became extra, because it contains no model so it won't be ever referenced (directly) for data validation.

Imports

The imports are mainly used to re-use definitions from existing modules.

importer.yang

exporter.yang

importer.json (valid)

exporter.json (also valid)

Multiple valid models issue

When the data is being decomposed using a schema context built from these two yang files, there will be no any error
if the incoming JSON matches any of models within . The appropriate module (for validation/parsing) could be chosen
dynamically. It also possible there could be collision if root container elements of both modules are having same name.

Current validation approach (no exception on data) seems being insufficient enough. Additional validation of root container
type will be necessary in order to ensure the correct model was chosen to process the data.

Assembly

Assembly case is mainly used to for organizational purposes when large module file is split to logical peaces (submodules)
for better maintainability. Submodules may have own revision but the namespace is shared with assembly module (the submodule belongs to).

assembly.yang

component.yang

assembly-1.json (valid)

assembly-2.json (also valid)

assembly.json (invalid)

Submodule issue

This issue is similar to the one of augmentation case: once the files are processed into an effective schema context the submodule has no use.

Multiple containers issue

As it was figured out it could be an issue if data has multiple

Data tree root mismatches model root issue

Issue description

This issue was determined on assembly case analysis - see the assembly.json example above.

The actual set of yang files was successfully parsed into effective schema context. However on data processing into NormalizedNode<?, ?>
fails if there are multiple top level containers provided with data JSON.