Expose SchemaInferenceStack.effectiveConfig()

Description

Current parser does not accurately process config statements, relying on DocumentedNode's and explicit lookups in parent. This means that users looking through EffectiveStatement hierarchy do not always see the config substatement when they should.

For example, given the following model:

module foo {
  prefix foo;
  namespace foo;

  grouping grp {
    container foo;
    container bar {
      config false;
    }
  }

  container baz {
    uses grp;
  }

  container oper {
    uses grp;
    config false;

    container cont;
  }

  rpc xyzzy {
    input {
      uses grp;
    }
  }
}

Should observe the following:

baz should have an implicit 'config true' substatement (as it is the default)
baz/foo should have an implicit 'config true' substatement (as it is the default/implied by parent)
oper/foo should have an implicit 'config false' substatement (as it is implied by parent)
oper/cont should have an implicit 'config false' substatement (as it is implied by parent)
xyzzy/input/bar should not have a config substatement (as it is instantiated in a context which ignores config)

Note this has implications on memory efficiency and general lifecycle of uses/augment mechanics, hence we need to carefully evaluate the solution.

Linked issues

relates to

YANGTOOLS-1272

Expose SchemaInferenceStack.effectiveStatus()

Activity

Show:

Robert Varga January 25, 2023 at 3:16 AM

The last sentence is okay. What we need to ensure is that we document EffectiveConfigStatement mechanics explicitly – both in its description and call it out in the general model.api.stmt contract description.

Robert Varga December 12, 2021 at 7:18 PM

The current requirement is really driven by DataSchemaNode.effectiveConfig(), i.e. the statement itself needs to know its effective configuration. This is important in SchemaNode world, as all its users usually work on a single SchemaNode, with the odd exception here and there where also the parent DataNodeContainer is considered.

In EffectiveStatement world, though, having this knowledge directly in the statement is not as critical. Users here typically work with EffectiveStatementInference, which conceptually captures the path from root. We also have SchemaInferenceStack as the baseline utility for all sorts of inferences on the statement tree.

Hence if we take SchemaNodes out of the picture, we could expose this information from SchemaInferenceStack, i.e. host DataSchemaNode.effectiveConfig() there and calculate the result based on stack. With such a design we can almost ditch the flags field from effective statements, allowing for a much more aggresive statement reuse in the parser.

Unfortunately this is somewhat counter-intuitive from object model perspective, as config/status end up not being strictly effective