Re: [netmod] import-by-semver issue

[Martin Bjorklund <[e-mail]>]

Andy Bierman <[e-mail]> wrote:
> On Sun, Mar 24, 2019 at 9:14 AM Juergen Schoenwaelder <
> [e-mail]> wrote:
> 
> > On Sun, Mar 24, 2019 at 03:14:18PM +0000, Rob Wilton (rwilton) wrote:
> > >
> > > But that is true of YANG compilers today.  If there are multiple
> > revisions of a module that could be chosen, then each compiler is at
> > liberty to decide which revision to choose (last paragraph of section 5.1.1
> > in RFC 7950).
> > >
> >
> > The difference is that NBC changes are not allowed. As long as you
> > find a certain symbol, it has fixed and predictable semantics.
> >
> > Sorry, but changing the way the import statement works is an NBC
> > change of YANG and this can't be done with extensions.
> >
> >
> I strongly agree.
> The expected behavior for tools needs to be consistent, especially for
> the construction of the schema tree, which depends on the import rules.
> 
> Implementation complexity should matter in the IETF, but it does not.
> Just keep raising the complexity up to 10 and complain that the tools have
> bugs,
> as if the two are unrelated. (Simply looking for a hardwired string
> "semver:version"
> will not work since the prefix is not required to be "semver" in the
> import-stmt.)

Agreed, but it quite easy to first build a prefix map (prefix ->
module name), and then instead of "xxxx:semver" you see ("ietf-semver",
"semver"); and _this_ can be hardcoded in the compiler.  (pyang works
like this)

This said, it is a bit weird with:

    import ietf-semver {
      prefix "semver";
      semver:version 1.1.2;
    }

so in order to handle the "semver:version" statement, you need to
import the module that has the prefix "semver".  But we can't just
import it like a normal import, b/c it has the semver: statement that
modifies how we do imports!



/matrin