"Rob Wilton (rwilton)" <[email protected]> wrote:
> [Copying Balazs because this discussion is moving to instance-data
> document schema definitions.]
>
> > -----Original Message-----
> > From: Schönwälder, Jürgen <[email protected]>
> > Sent: 04 October 2019 10:36
> > To: Rob Wilton (rwilton) <[email protected]>
> > Cc: Christian Hopps <[email protected]>; Mahesh Jethanandani
> > <[email protected]>; [email protected]
> > Subject: Re: [netmod] References to the "tags" typedef
> >
> > On Fri, Oct 04, 2019 at 08:17:33AM +0000, Rob Wilton (rwilton) wrote:
> > >
> > > To use the "tags:tag" typedef, ietf-yang-package had an import on
> > > "ietf-
> > module-tags" which both defines a tags type and also a "module-tags"
> > container as well. I want the typedef, but not the container, because
> > I
> > don't want the schema for the package file to be:
> > > +--ro yang-package <-- I do want this
> > > | +--ro name yang:yang-identifier
> > > | ...
> > > +--ro module-tags <-- I don't want this
> > > +- ...
> > >
> >
> > Isn't import-only-module in YANG library take care of this?
> [RW]
> Yes, that is one solution.
>
> The instance data document (probably in JSON, but I've given an XML
> snippet below) could use the "inline-spec" for specifying the schema.
>
> But this means that every package instance file, needs to have some
> boilerplate like this before the actual package definition.:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <instance-data-set xmlns=
> "urn:ietf:params:xml:ns:yang:ietf-yang-instance-data">
> <name>some-yang-package</name>
> <inline-spec>[email protected]</inline-spec>
> <inline-content-schema>
> <yang-library xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-library">
> <module-set>
> <name>all</name>
> <module>
> <name>ietf-yang-package</name>
> <revision>2019-09-11</revision>
> </module>
> <import-only-module>
> <name>ietf-yang-package-types</name>
> <revision>xxxx-xx-xx</revision>
> </module>
> <import-only-module>
> <name>ietf-module-tags</name>
> <revision>xxxx-xx-xx</revision>
> </module>
> <import-only-module>
> <name>ietf-yang-revisions</name>
> <revision>xxxx-xx-xx</revision>
> </module>
> <module>
> <name>ietf-yang-structure-ext</name>
> <revision>xxxx-xx-xx</revision>
> </module>
> <module>
> <name>ietf-yang-types</name>
> <revision>xxxx-xx-xx</revision>
> </module>
> <module>
> <name>ietf-yang-library</name>
> <revision>xxxx-xx-xx</revision>
> </module>
> <module>
> <name>ietf-inet-types</name>
> <revision>xxxx-xx-xx</revision>
> </module>
> </module-set>
> </yang-library>
> </inline-content-schema>
> <content-data>
> // Actual package information goes here.
> </content-data>
> </instance-data-set>
>
> https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-instance-file-format/?include_text=1
>
> 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.
I prefer this solution for the packages document.
> (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.
Ugh, I haven't paid enough attention to the instance data
document... I will comment on this design in a separate email.
> 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": [ "[email protected]" ],
> "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
> "[email protected]". 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).
You shouldn't have to do that. You should use the appriopriate
types.
> 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?
By reusing appriopriate typedefs you get clearer semantics. In the
extreme case everyting is just strings with some descripton statements
(you might think that this is absurd, but this approach has been taken
by some data model designers (not necessarily yang) ...)
/martin
>
> Thanks,
> Rob
>
>
> >
> > /js
> >
> > --
> > Juergen Schoenwaelder Jacobs University Bremen gGmbH
> > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> > Fax: +49 421 200 3103 <https://www.jacobs-university.de/>
>
> _______________________________________________
> netmod mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/netmod
>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
