On 14/12/2021 14:04, Ladislav Lhotka wrote:
Michal Vaško <[email protected]> writes:

Michal Vaško <[email protected]> wrote:
Michal Vaško <[email protected]> wrote:
Michal Vaško <[email protected]> wrote:

[snip]

module mod_a {
     namespace "x:example:mod_a";
     prefix "ma";
     import mod_b { prefix "mb"; }
     container root {
         uses mb:mylist_wrapper;
     }
     augment /mb:mylist2 {
         leaf c {
             type string;
         }
     }
     deviation /mb:mylist2 {
         deviate add {
             unique "mb:b c";
         }
     }
}

[snip]

I would appreciate any exact rules that we can agree on.

The existing rules in RFC 7950 seem unclear/contradictory.

This is in sec. 7.12 on "grouping":

    Identifiers appearing inside the grouping are resolved relative to
    the scope in which the grouping is defined, not where it is used.
    Prefix mappings, type names, grouping names, and extension usage
    are evaluated in the hierarchy where the "grouping" statement
    appears.

And this is then in sec. 7.13 on "uses":

    The identifiers defined in the grouping are not bound to a namespace
    until the contents of the grouping are added to the schema tree via a
    "uses" statement that does not appear inside a "grouping" statement,
    at which point they are bound to the namespace of the current module.

Just my .02EUR, in OpenDaylight we deal with this particular case in two steps:

1. the argument to unique is interpreted in scope of mod_a, hence "mb:b c" interprets the same as "mb:b ma:c", just as it would in any other declaration site

2. in the particular case of "deviate add", the statement is then copied verbatim to deviation target site

i.e. this works similar to how an augment would work -- and hence the quoted example works as one would expect from just a cursory glance at the model without giving it a second thought :)

Regards,
Robert

Attachment: OpenPGP_signature
Description: OpenPGP digital signature

_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod

Reply via email to