Re: [netmod] References to the "tags" typedef

[Schönwälder, Jürgen <[e-mail]>]

On Fri, Oct 04, 2019 at 10:04:56AM +0000, Rob Wilton (rwilton) wrote:
> 
> The YANG instance data draft provides some other choices:
> (1) (External Method) Don't define the schema, just assume that clients know what it will be for YANG packages.  E.g. it would be specified in the YANG packages RFC.
> (2) (URI method) Put the schema in a separate instance data document and reference that.  This could be defined in the YANG packages RFC, but it might open the question of what URI can you use to retrieve it.
> (3) Simplified inline schema.
> 
> It is the third one that I would ideally like to use.
> 
> Here, the package data would like something like this (sorry, in JSON this time):
> 
>   "ietf-yang-instance-data:instance-data-set": {
>     "name": "example-ietf-network-device-pkg",
>     "module": [ "[e-mail]" ],
>     "description": "YANG package definition",
>     "content-data": {
>       "ietf-yang-package:yang-package": {
>         "name": "example-ietf-network-device-pkg",
>         // Actual package information goes here.
>       }
>     }
>   }
> 
> Here, the schema is defined by the "module" line "[e-mail]".  I think that there are some details to work out, but I think that the import dependencies for "ietf-yang-package.yang" could be automatically resolved as import-only YANG modules.  I have also tried to minimize the required imports (e.g. don't import YANG library, perhaps don't import from module-tags).

The import vs. implement distinction is today in the schema. If people
invent other ways to express schemas, then they will likely have to
find a way to express that distinction. Right now, there is no rule
that says import only definitions must be in separate modules. (In
fact, in several cases, you will only learn over time what people
import only.)

> In terms of typedefs, are two typedefs equivalent if they have exactly the same definition in two different modules?  Or does the fact that they are named given them a slightly different meaning?

Two typedefs foo:t1 and bar:t2 may be semantically the same but they
also remain to be two different definitions. Equivalence of typedefs
may mean two different things, depending on the context (or the kind
of equivalence you care about in a certain context).

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <https://www.jacobs-university.de/>