Martin Bjorklund <m...@tail-f.com> 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 <j.schoenwael...@jacobs-university.de> 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
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
