Unify NodeIdentifier and NodeIdentifierWithPredicates
Activity
Show:

Robert Varga July 4, 2024 at 11:20 AM
This should end up with yang.common.InstanceIdentifier being defined, for which QName forms a NodeIdentifier step.

Robert Varga September 3, 2018 at 10:19 AM
While this issue deals with lists, where NodeIdentifierWithPredicates selects a certain list member, is geared towards elimination of AugmentationIdentifier – which instead becomes a child selection filter.
Details
Details
Assignee
Unassigned
UnassignedReporter

Components
Fix versions
Priority
Created August 27, 2018 at 11:46 PM
Updated July 4, 2024 at 11:21 AM
The dichotomy of these two PathArguments leads to keyed list items being addressed through two PathArguments. With YANGTOOLS-585 out of the way the presence of lists as DataTree elements is an implementation detail, as they are completely transparent to datastore operations.
Considering filtering requirements coming from RFC6241, there really are four levels of NodeIdentifier when we are considering lists:
NodeIdentifier: select all members
NodeIdentifierWithPredicates: select a single (keyed) list entry
NodeIdentifier + NodePredicates: select all nodes matching predicates
if NodePredicates is a superset of key predicates: select single entry if it is matching additional predicates
This has interplay with other types like containers, where predicates must match leaves – hence having a read() of a container using NodeIdentifier + NodePredicates would a well-defined filtering operation. We also need to consider implementation complexity and usefulness in face of the fact we want to support XPath queries at some point.