Re: [yang-doctors] XPath question

[Martin Björklund <[e-mail]>]

Andy Bierman <[e-mail]> wrote:
> Hi,
> 
> RFC 7950 does not say whether unselected case-stmts are visible in XPath.
> The bbf-qos-enhanced-scheduling module has a default leaf in 1 case
> and a nested node with a must-stmt in a sibling case that references it.

This will not work, since the XPath context in this case is the
datastore, and the datastore will never contain nodes from two
different cases.  But see below.

> The issue is whether the XPath context includes the default leaf.
> Case 'queue' and 'child-schedular-queues' are siblings.
> I suspect our code is wrong and the defaults from all cases are visible
> to XPath evaluation.
> 
> 
>           case queue {
>             description
>               "The children are a list of queues.";
>             leaf contains-queues {
>               type boolean;
>               *default "true";*
>               description
>                 "Indicates the scheduler contains queues.";
>             }
>             uses bbf-qos-tm:queues;
>           }
>           case child-scheduler-queues {
>             if-feature "child-scheduler-queue-references";
>             container child-scheduler-queues {
>               description
>                 "Configuration to reference one or more queues within
>                  one or more child schedulers.";
>               list child-scheduler {
> 
>                  // ....
> 
>                 container queues {
> 
> 
> * must "../../../../bbf-qos-sched:scheduler-node"                     +
> "[bbf-qos-sched:name=current()/../name]/"                     +
> "bbf-qos-sched:contains-queues = 'true'" *{
>                     error-message
>                       "The referenced scheduler must contain queues.";
>                     description
>                       "The referenced scheduler must contain queues
>                        in order for queues to be referenced.";
>                   }

I don't have the full model in front of me, but does this really refer
to a node in a sibling case?  It looks as if it might refer to another
instance of the "scheduler-node" list (I assume it is a list).


/martin