Andy Bierman <[email protected]> wrote:
> On Sun, Mar 24, 2019 at 9:14 AM Juergen Schoenwaelder <
> [email protected]> 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
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
