Re: [yang-doctors] XPath question

[Ladislav Lhotka <[e-mail]>]

Andy Bierman <[e-mail]> writes:

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

Section 7.6.1 in RFC 7950:

   o  Otherwise, if this ancestor is a case node, the default value MUST
      be used if any node from the case exists in the data tree or the
      case node is the choice's default case, and if no nodes from any
      other case exist in the data tree.

So if instance nodes from other cases exist, the default value is not in use.

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

There is nothing wrong with it, except that either of the must expressions always evaluates to false, if it is evaluated at all. This is by definition, because the must expressions are evaluated only if instances of leaves A2.1 or A2.2 exist in the data tree, in which case the defaults for A1 and A3 are not in use.

Lada

>
> 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
>>
> _______________________________________________
> yang-doctors mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/yang-doctors

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67