Re: [NGO] external module properties

Martin Bjorklund writes:
>But when it
>comes to data/rpc/notifs the device must choose one version to
>implement.  It would have to be a version no earlier than the latest
>version referenced by any other module implemented on the device.

Right, and it may be "none".  Consider that I may implement
modules that import a module that I simply don't implement.
The data/rpc/notifs in the module are not present in my implementation.

A module imports another module for four reasons:
- to reuse types
- to reuse groupings
- to augment content
- um...  er....  wait, I know there was another one

In all these cases, I want to reuse/augment a specific revision
of the module.  I may even implement both a module that imports
an older revision of the module and the most modern revision of
the module.  But the imported revision will make clear what content
I'm bringing in.

>Maybe it's not a problem...  but the schema discovery mechanism will
>have to support these cases.  There would be two separate lists of
>schemas; one list with the data/rpc/notifs that the device implements,
>and an extended list which includes older versions and
>type/grouping-only modules.

Exactly.  And if module B only used groupings/types/etc from A,
I could implement B without implementing A at all.

>Yes.  A couple of solutions have been mentioned already, and another
>alternative is to keep this limitation, and force people to define new
>groupings in this case; essentially putting the version into the name:

This becomes an impediment to readability, and readers are our
highest priority.

Thanks,
 Phil
_______________________________________________
NGO mailing list
NGO@ietf.org
https://www.ietf.org/mailman/listinfo/ngo