Robert Wilton <[email protected]> wrote: > > > On 19/09/2017 14:28, Lou Berger wrote: > > > > On 9/19/2017 7:29 AM, Martin Bjorklund wrote: > >> Lou Berger <[email protected]> wrote: > >>> Martin, > >>> > >>> Speaking as a contributor: > >>> > >>> > >>> On 9/15/2017 7:40 AM, Martin Bjorklund wrote: > >>>> Robert Wilton <[email protected]> wrote: > >>>>> On 15/09/2017 11:21, Ladislav Lhotka wrote: > >>>>>> Andy Bierman píše v Čt 14. 09. 2017 v 08:43 -0700: > >>>>>>> Hi, > >>>>>>> > >>>>>>> > >>>>>>> Actually I liked the early pyang output that was concise and easy to > >>>>>>> remember. > >>>>>>> The current format gets very cluttered and there are too many little > >>>>>>> symbols > >>>>>>> to remember them all. > >>>>>> I agree. > >>>> Me too. The current draft adds three new magic symbols: "mp" "@" and > >>>> "/". > >>>> > >>>> "mp" is for a mount point, and it can be generated directly from the > >>>> YANG modules. > >>>> > >>>> Directly under a "mp", "/" and "@" are used to indicate that a node is > >>>> mounted > >>>> or available through a parent reference, respectively. > >>>> > >>>> I actually question the usability of "/" and "@". > >>> I agree that / and @ are something new, and enabled by schema mount. > >>> There have been repeated comments in the RTG WG that there needs to be > >>> some way for vendors to convey what they have implemented with Schema > >>> mount > >> If that's the requirement, using the tree diagram is probably not the > >> best way. The tree diagram is intended to provide an overview of a > >> given (set of) YANG module(s). > >> > >> A perhaps better way to convey the information is to create a file > >> with an instantiated /schema-mounts tree. > > using what syntax? JSON and XML really isn't that easy for the > > (human) > > reader to parse. > Perhaps there needs to be multiple versions of the generated tree > output? > > 1) A normative tree diagram that shows the structure of the model. > 2) A subsequent example that demonstrates what it looks like with the > schema mounted modules. Within the confines of a text document, the > tree format still seems like a reasonable way to illustrate this, and > I would say it is preferable to the verbosity of JSON or XML. > > I note that RFC 8022 includes an overview tree model in section 4 with > some branches pruned, and then the complete representation in an > appendix, which seems like a pragmatic approach.
Sure, but the question is about what special symbols we define. Do we need the extra symbols "/" and "@", and do we agree on what they mean? /martin _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
