Michal Vaško <[email protected]> wrote:
> > Michal Vaško <[email protected]> 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.
Interpret the unique argument the same way as an XPath expression, and
apply (from 6.4.1):
o Names without a namespace prefix belong to the same namespace as
the identifier of the current node. Inside a grouping, that
namespace is affected by where the grouping is used
So "value" in the unique statement will refer to "value" in "mod_a"
when the grouping is used in "mod_a".
/martin
>
> > /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
> > > [email protected]
> > > https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
