Re: [netmod] YANG 1.1: clarify nested submodule behavior

[Andy Bierman <[e-mail]>]

On Thu, May 8, 2014 at 12:54 AM, Martin Bjorklund <[e-mail]> wrote:

> Ladislav Lhotka <[e-mail]> wrote:
> >
> > On 07 May 2014, at 22:21, Martin Bjorklund <[e-mail]> wrote:
> >
> > > Andy Bierman <[e-mail]> wrote:
> > >> On Wed, May 7, 2014 at 9:11 AM, Martin Bjorklund <[e-mail]>
> > >> wrote:
> > >>> I am confused.   There are no additional namespaces today - just one,
> > >>> introduced by the module.  What did you agree on?
> > >>>
> > >>>
> > >> There are 2 issues -- we agree on 1
> > >>
> > >> 1) how to indicate that submodule contents are exported from the main
> > >> module
> > >>     to external modules?
> > >>
> > >>    a) include must be in main module
> > >>    b) include must be in main module or submodule
> > >>
> > >> 2) what definitions are visible within a submodule?
> > >>
> > >>    a) only self and includes
> > >>    b) main module, self, and includes
> > >
> > > Thank you, this is a clear summary of the alternatives.
> > >
> > > I think we were all over the map when we discussed this during the
> > > initial design of YANG.  We looked at all these alternatives, and
> > > ended up with what we have today.  I'll go back and look in the
> > > archives to see how much of the discussions are captured.
> >
> > I wasn't there. :-)
> >
> > >
> > > One design rule we had was that we wanted it to be possible to compile
> > > / check each submodule on its own (only follow explicit
> > > import/include), w/o having to bring in the complete module.  With
> > > option 2b, this is no longer possible.
> >
> > I don't think this is important - the top-level definitions from the
> > main module and all submodules are easy to look up. On the other hand,
> > submodules cannot use conflicting names even if they don't include
> > each other, so it doesn't help submodule writers in this respect.
> >
> > >
> > > Re. issue 1, it seems to me no real problem is solved by going from 1a
> > > to 1b.
> >
> > I agree. It would be different if a submodule tree could be grafted to
> > a non-root node, but it is not the case.
> >
> > >
> > > Re. issue 2, solution 2b actually solves a real problem - today you
> > > have to place common definitions in a separate submodule; they cannot
> > > go into the main module.  Since circular includes are not possible,
> > > references within a module (across submodules) have to be done
> > > carefully, and might impose a non-intuitive submodule design.
> >
> > Right, this is a serious contender for the most peculiar rule in YANG.
> >
> > >
> > > So I think we need to think more about this, but solution 2b seems
> > > attractive to me.
> >
> > With 1a, the following is a logical option:
> >
> > 2c) main module and all submodules included from it.
>
> Yes, that's how I interpreted 2b!  Essentially each submodule has
> access to all definitions in all other submodules.
>
>
This is what I wanted from the start.
That is why I do not agree that the include-stmts need to be in the main
module.

module A {
   prefix a;
   include B;
   container foo;
 }
 submodule B {
    belongs-to A { prefix a; }
    include C;
 }
 submodule C {
    belongs-to A { prefix a; }
    leaf top { type string; }
    augment /a:foo {
       leaf should-be-ok { type string; }
     }
 }

IMO, the include-stmts just say "go find this file and add all the
definitions to the module namespace". Therefore, leaf 'top'
is visible in the main module and also to external modules.
This is the detail we do not agree on.  Forcing the include-stmt
to also appear in the main module seems like a CLR.

It is not really OK to declare that submodules can use definitions
without include-stmts, unless we don't care about the self-compiling
sub-modules. (IMO a real low priority). If so, then it is also
OK to allow submodules to access the main module definitions.


> /martin
>

Andy