Michal Vaško <mva...@cesnet.cz> writes:
>> Michal Vaško <mva...@cesnet.cz> wrote:
>> > > > Michal Vaško <mva...@cesnet.cz> wrote:
>> > > > > > 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.
>> > > > > > > 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".
>> > > > > I see. Okay, this should be possible to implement, thanks.
>> > > I was too hasty with the reply, this is not working because of the
>> > "unique" in the deviation I have in the example. What is the "current>
>> > node" in that case? I suppose that can only be "mylist2", so the
>> > namespace will be that of "mod_b". But this is wrong, the "c" node
>> > belongs to "mod_a", so the "unique" in the deviation would be wrong.
>>
>> Right; I was thinking that since "c" didn't have a prefix, it would
>> belong to "mod_a", and thus work as expected.
>>
>> I think it is ok to solve this by requiring a prefix in this case.
>
> What you are saying is that you would be fine with the deviation not working
> with no prefix in the example and stick to the rule of using the current
> (context) node to get modules for non-prefixed identifiers?
>
> @Lada You seem to suggest some special handling of paths in deviations (or
> what exactly)?
Not really. If we wanted to extend the rule from sec. 6.4.1 that Martin cited
to deviations, the only candidate for the "current node" is the root node.
On the other hand, sec. 6.4.1 is about XPath context, and the argument of
"unique" contains schema node identifiers, i.e. NOT XPath.
>
> Neither really seem like a proper solution and, more importantly,
> interpreting "unique" paths (non-prefixed identifiers) according to XPath
> contradicts what I was told those few years back (I will try to find the
> mailing list communication if necessary), which is that for "schema node
> identifiers" the current module is the module where the statements are
> "physically" written, not that of the current node.
>
> We keep hitting these problems because the use-cases vary greatly and the
> most complex ones were probably not anticipated when writing the specs.
> Still, the code must handle all the use-cases somehow and we have huge
> problems with that.
>
> 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.
Lada
>
> Michal
>
>> > > > > /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
>> > > > > > > netmod@ietf.org
>> > > > > > > https://www.ietf.org/mailman/listinfo/netmod
>> > > > > _______________________________________________
>> > > 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
--
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
