Hi,
I think the reason this was rejected is because you cannot control
which "uses" of the grouping should get the augmenting nodes.
They all get the nodes. There is no way for the uses-stmt to "opt-in"
to the new changes, except manually:
grouping foo { ... }
grouping new-foo {
uses foo;
// add new nodes via augment or data-def-stmt;
}
By forcing the "uses foo" to change to "uses new-foo",
the data model designer is explicitly accepting the new changes.
Note that import-without-revision can also cause the uses-stmt
to expand differently as the imported module changes over time.
This is a separate problem.
Andy
On Thu, Mar 23, 2017 at 5:50 PM, Dale R. Worley <[email protected]> wrote:
> Martin Bjorklund <[email protected]> writes:
> >> I notice that "augment" is not allowed to target a "grouping", despite
> >> that naively seems to be an operation that a module designer might like
> >> to do. I expect that there is a reason why this is not allowed.
> >
> > There were lots of debate over this one when we first designed YANG.
> > The main reason for not allowing this is that it can easily have
> > unintended consequences. Module A uses a grouping G b/c it fits the
> > purpose. Later someone augments G with some nodes; at this point it
> > is not at all clear that the additional nodes are suitable for module
> > A.
>
> True... But assuming that the grouping G has clean semantics, it
> corresponds to some facility in the device, which in some way or another
> appears in multiple places in the device's data model. And a module
> that augments G adds semantics about that facility, and would only be
> implemented by a device for which the facility uniformly has that
> additional semantics. So it would be suitable for every place where the
> grouping is used.
>
> It seems like this consideration applies to the "Yang mount" facility
> also -- if a module A augments another module B, and module B is mounted
> in several places in the full data model, then all the instances of
> module B will be augmented.
>
> > Ok. Well, if you want to add a sibling node to the nodes in the
> > grouping it is trivial:
> >
> > grouping foo {
> > leaf a { ... }
> > }
> >
> > uses foo;
> > leaf b { ... }
> >
> > gives you:
> >
> > leaf a { ... }
> > leaf b { ... }
>
> Of course, that works. But what I'm considering is a modification of
> the grouping which implicitly applies to all "uses" of that grouping --
> because you don't want to have duplicate declarations of the added nodes
> in every place the grouping is used.
>
> > Well, the syntax of descendant-schema-nodeid looks like an XPath path
> > expression in abbreviated form, but it is not defined in terms of
> > XPath, hence there is no text about any XPath context. See also
> > section 6.5
>
> OK, "context node" isn't the right term, but the idea still applies --
> if the schema node identifier is descendant, the starting point for
> reckoning the descending path has to be specified.
>
> Juergen Schoenwaelder <[email protected]> writes:
> > On Wed, Mar 22, 2017 at 02:26:53PM -0400, Dale R. Worley wrote:
> > This is not at all clear. You only import 'foo' - so why would the
> > augment of /foo:target (which is not exactly defined either) done in
> > 'bar' apply to uses foo:target in baz?
>
> I'd say because that's what one would expect "augmenting" of a grouping
> to mean. Again, it looks like there will be similar behavior in "Yang
> mount".
>
> > Augments are restricted to things that have a well defined name in the
> > data tree because this makes it clear what is being augmented. One
> > would have to create additional language constructs to make
> > augmentations of groupings work.
>
> It's clear that *groupings* have well-defined names, because "uses"
> statements can refer to them. RFC 7950 section 7.13 isn't particularly
> clear about how the argument string of the statement is to be
> interpreted, but going back over 7950, I'm getting the idea that the
> names of groupings are not descendant-schema-nodeid's, that is, named
> based on where the grouping statement sits in the syntactic hierarchy,
> but are in a separate namespace which is flat regarding equality and
> inequality comparisons, but has elaborate scoping rules regarding which
> groupings are visible in which locations.
>
> OK, that clarifies why you can't apply "augment" to a grouping --
> groupings (and thus the things defined within them) don't have names
> that can be expressed by descendant-schema-nodeid's.
>
> Dale
>
> _______________________________________________
> netmod mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/netmod
>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
