> Michal Vaško <mva...@cesnet.cz> wrote:
> > Hello,
> > > I would like to get some input for a use-case I came across, which to> me
> > > does not seem to have any consistent rules that can be applied.
> > > module mod_b {
> > namespace "x:example:mod_b";
> > prefix "mb";
> > > grouping mylist_wrapper {
> > list mylist {
> > key "name";
> > unique "value";
> > leaf name {
> > type string;
> > }
> > leaf value {
> > type uint32;
> > }
> > }
> > }
> > > list mylist2 {
> > key "a";
> > leaf a {
> > type string;
> > }
> > leaf b {
> > type string;
> > }
> > }
> > }
> > > > 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";
> > }
> > }
> > }
> > > The focus is on the "unique" statements and how to resolve
> > non-prefixed identifiers. RFC 7950 says that the argument is a "list
> > of schema node identifiers"[1], which use "current module" for
> > non-prefixed identifiers[2]. I have asked on this mailing list a few
> > years back what current module means and the answer I got was the
> > module where the statement is defined.
> > > So let's get to the examples. As they are written, the unique in
> > "mylist" should be wrong because the node "value" belongs to the
> > module "mod_a" when the grouping is instantiated there, but unique is>
> > defined in the module "mod_b".
> > > But even if we use the other understanding of current module and
> > interpret is as the module of the context node of the statement
> > (corresponds to the "current()" XPath function), then the other
> > "unique" in the deviation cannot be resolved. It is referencing node
> > "c", which belongs to the module "mod_a" (added by an augment) but the
> > current module would then be "mod_b".
> > > To summarize, if strictly following the specs, the "unique" in the
> > "mylist" should probably reference "value" with a prefix, but that is> not
> > possible because "mod_a" is not even imported and it generally
> > does not make sense. But then I cannot think of any consistent rule to
> > successfully resolve both "unique" statements in this example. Can
> > anyone help me with this, please?
>
> Compare with this:
>
> grouping mylist_wrapper {
> list mylist {
> key "name";
> unique "value";
> must "value > 42";
> leaf name {
> type string;
> }
> leaf value {
> type uint32;
> }
> }
> }
>
> I think the rules for the prefixes in "unique" should be the same as
> for "must". So I think that the correct syntax is to not use any
> prefix in "unique".
>
> And the deviation that adds a unique statement look correct.
Thanks for the reply but I do not think you have answered my question. Please
formulate a formal rule how to assign modules to non-prefixed identifiers,
whether they be in "unique", "must", or any other statement with identifiers.
That is what I need to implement it properly and I am simply not able to come
up with any that would be consistent and compliant with the specification.
> /martin
>
> > Finally, I am asking because I am trying to implement this correctly
> > in yanglint. I have also tried to test these examples with pyang,
> > which, however, seems to not have any consistent rules applied because
> > it loads these examples without warnings. No warnings are printed even
> > if the "unique" in the deviation is changed to "b c", which is
> > definitely wrong since node "b" belongs to "mod_b" and node "c"
> > belongs to "mod_a".
> > > Thanks,
> > Michal
> > > [1] https://datatracker.ietf.org/doc/html/rfc7950#section-7.8.3
> > [2] https://datatracker.ietf.org/doc/html/rfc7950#section-6.5
> > > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
