[YANGTOOLS-1063] Make DataSchemaNode.isConfiguration() tri-state

Relates — Fri, 4 Dec 2020 15:53:50 +0000

The idea that isConfiguration() boils down to a simple boolean is flawed, as DataSchemaNodes defined under a grouping can be either. There are three basic models here:

module foo {

  grouping foo {
    container indeterminate {
       // ancestors is neither true or false, hence we do not know
    }
  }

  container cfg {
    // No config, defaults to true
    grouping foo {
      container indeterminate {
        // ancestor is config=true, but this may be used in config=false
      } 
    }
  }

  container oper {
    // Explicitly false
    config false;

    grouping foo {
      container false {
        // ancestor is config=false and hence this can only be referenced
        // by other config=false nodes.
      }
    }
  }
}

For the purposes of modeling, though, DataSchemaNodes defined within a grouping hierarchy should have a isConfiguration=UNDEF.

Semantically the question is what happens to nodes in notifications/actions/RPCs – they are not inherently tied to a particular data store, although RFC7950 would seem to imply these are runtime constructs and hence would be config=false. Since ODL extends the invocation model to allow RPC/action/notifications on any datastore, these should end up being undefined, too.

OpenDaylight JIRA

[YANGTOOLS-1063] Make DataSchemaNode.isConfiguration() tri-state