Uploaded image for project: 'yangtools'
  1. yangtools
  2. YANGTOOLS-1356

Introduce model.api.stmt.DataNodeIdentifier

XMLWordPrintable

    • Icon: New Feature New Feature
    • Resolution: Won't Do
    • Icon: Highest Highest
    • None
    • None
    • None

      We are faced again and again with the problem of interfacing various constructs which boil down to addressing YANG-modeled data.

      The usual solution involves YangInstanceIdentifier, but that has non-trivial mapping to YANG due to its addressing mode of operation, which takes into account keyed list entries as well as augmentations. It also accumulated weird things like:

      • wildcards, i.e. the use of NodeIdentifier to say 'match all MapEntryNodes'
      • partial matches, i.e. NodeIdentifierWithPredicates without all the keys corresponding to schema present

      In yang-model-api we have had a similar (but different) problem with SchemaPath, which we solved through introduction of SchemaNodeIdentifier and EffectiveStatementInference, each of which has a narrow scope of what it solves and how it operates.

      At the end of the day, at least where NETCONF/RESTCONF is concerned, we really need an identifier which works strictly on YANG data tree addressing, pure and simple. At the heart of it is something like:

      class DataTreeStep {
        QName nodeId;
        Map<QName, Object> predicates; // may be empty
      }
      
      class DataTreeIdentifier {
        List<DataTreeStep> steps; // at least one
      }
      

      Taking the YangInstanceIdentifier/wildcard case to heart, though, we need two dedicated specializations of that structure:

      1. one for read requests, where it is treated like a NETCONF subtree filter
      2. one for read responses, where it is treated like a proper instance identifier, i.e. predicates for list keys are fully populated.
        The specializations must not share a (publicly visible) superclass, so that there is no way of confusing the request and response side. The DataTreeIdentifier -> DataTreeFilter conversion is trivial.

      We then should provide schema-assisted utilities to covert:

      • DataTreeFilter -> DataTreeIdentifier, which validates the filter specifies all key list predicates
      • DataTreeIdentifier <-> exact YangInstanceIdentifier
      • DataTreeFilter -> wildcard YangInstanceIdentifier which matches the superset of the DataTreeFilter (plus a structure describing what are the parts where a DataTreeChangeListener is providing a superset)
      • partial/wildcard YangInstanceIdentifier -> DataTreeFilter

      This toolkit should make life a lot easier for our downstreams.

            rovarga Robert Varga
            rovarga Robert Varga
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated:
              Resolved: