Re: [yang-doctors] XPath question

[Andy Bierman <[e-mail]>]

On Mon, Jun 6, 2022 at 11:34 PM Martin Björklund <[e-mail]> wrote:

> 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.
>


XPath evaluation also includes defaults.
pyang, yanglint, and yangdump-pro all accept this module:

container top {
     choice A {
       leaf A1 {
          type int32;
          default 10;
       }
       container A2 {
         leaf A2.1 {
           type string;
           must "../../A1 = 10";
         }
         leaf A2.2 {
           type string;
           must "../../A3 = 100";
         }
       }
       leaf A3 {
          type int32;
          default 100;
       }
     }
  }

That seems correct because at compile-time only the schema nodes are known
and they are used correctly.

The issue is whether the defaults (10 and 100) exist in XPath evaluation or
not.
Sec. 7.9.3 indicates that these defaults are not present (see bold).
It seems clear that only the defaults in the default-case are used in XPath
evaluation,
and only if no explicit case is used.

The BBF XPath is fine because a different list entry can be selected, but
only if the
leaf is set explicitly (since no default case in these examples).


7.9.3 <https://datatracker.ietf.org/doc/html/rfc7950#section-7.9.3>.
The choice's "default" Statement

   The "default" statement indicates if a case should be considered as
   the default if no child nodes from any of the choice's cases exist.
   The argument is the identifier of the default "case" statement.  If
   the "default" statement is missing, there is no default case.

   The "default" statement MUST NOT be present on choices where
   "mandatory" is "true".

   The default case is only important when considering the "default"
   statements of nodes under the cases (i.e., default values of leafs
   and leaf-lists, and default cases of nested choices).  The default
   values and nested default cases under the default case are used if
   none of the nodes under any of the cases are present.

   There MUST NOT be any mandatory nodes (Section 3
<https://datatracker.ietf.org/doc/html/rfc7950#section-3>) directly
under the
   default case.

   *Default values for child nodes under a case are only used if one of
   the nodes under that case is present or if that case is the default
   case.  If none of the nodes under a case are present and the case is
   not the default case, the default values of the cases' child nodes
   are ignored.*


 Andy


> 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
>