"Xufeng Liu" <[email protected]> wrote: > To a user of the schema-mount, it is important to be able to visualize > all key elements of the mounting mechanism: mount-point, mounted > schema module, and parent-reference. The details can be worked out, > but if any of these elements were not useful in the presentation, it > would be questionable whether it had well-specified in the schema > mount draft.
We agreed that we probably don't want to list all enums in the tree. Does that imply that enumerations are not well-specified in YANG? > > -----Original Message----- > > From: netmod [mailto:[email protected]] On Behalf Of Martin > > Bjorklund > > Sent: Monday, September 25, 2017 1:39 PM > > To: [email protected] > > Cc: [email protected] > > Subject: Re: [netmod] Proposal to enhance the YANG tree output > > > > "Acee Lindem (acee)" <[email protected]> wrote: > > > Martin, Lada, et al, > > > > > > While I don’t think we need additional annotations that Joe had > > > prototyped (at least not as the default), I strongly believe we need > > > to keep the ‘@‘ and ‘/‘ in the tree output for schema mount. > > > > Can you explain what information "/" gives the reader? Compare these > > two > > trees: > > > > +--mp vrf-root > > +--rw rt:routing/ > > +--rw rt:router-id > > > > and > > > > +--mp vrf-root > > +--rw rt:routing > > +--rw rt:router-id > > > > What did the "/" in the first tree tell me that I don't see in the > > second tree? > > [Xufeng] Because the schema mount draft allows an augmenting module > not to be listed in the mounted schema list. The following two > examples show two different configurations: > > +--mp root > +--rw rt:routing/ > | +--rw router-id? yang:dotted-quad > | +--rw control-plane-protocols > | +--rw control-plane-protocol* [type name] > | +--rw ospf:ospf/ > > where ospf augments rt, and has been listed in the mounting schema > list. > > +--mp root > +--rw rt:routing/ > | +--rw router-id? yang:dotted-quad > | +--rw control-plane-protocols > | +--rw control-plane-protocol* [type name] > | +--rw ospf:ospf > > where ospf augments rt, and has not been listed in the mounting schema > list. If the ospf module is NOT listed in the yang library data for the mount point, then it will not be present in the tree. So in this case the tree will be: +--mp root +--rw rt:routing | +--rw router-id? yang:dotted-quad | +--rw control-plane-protocols | +--rw control-plane-protocol* [type name] // no ospf here [Think about it the other way around; if we were to show all nodes from all modules that are NOT mounted, our tree would be inifinitely big...] If the ospf module *is* listed in the yang library data for the mount point, then the tree can be: +--mp root +--rw rt:routing | +--rw router-id? yang:dotted-quad | +--rw control-plane-protocols | +--rw control-plane-protocol* [type name] | +--rw ospf:ospf No need for a '/'. > > Then consider: > > > > +--ro if:interfaces@ > > > > and > > > > +--ro if:interfaces > > +-- if:interface@ > > > > and > > > > +--ro if:interfaces@ > > +-- if:interface@ > > > > > > Which ones are legal, and what do they mean? > > > [Xufeng] The display shows the result of the XPath, right? I don't know what it shows; I'm not proposing this notation. Also note that the result of the XPath is a node set of *instance data*, but the tree shows the *schema*, and mixing the two is confusing. Hopefully by looking at the trees above, the reader will understand what's behind this notation. So I ask again, what do the notations above mean? > Whether > they are legal or not should be determined by the schema-mount draft, > not by the displaying notation. The schema mount draft does not specify the rules for the '@' in the tree output. -- My points are that: (1) "/" is redundant and not needed. The same information can be conveyed w/o "/". (2) "@" is under specified, and it mixes schema and instance data. /martin > > > > > > > /martin > > > > While the former enhancement > > > provided details, the schema mount tree designations are every bit as > > > important as knowing, for example, whether or not a schema leaf is a > > > presence node. > > > > > > Thanks, > > > Acee > > > > > > > > > On 9/15/17, 9:56 AM, "Acee Lindem (acee)" <[email protected]> wrote: > > > > > > >+1 - Also it is hard enough to format the tree output to fit in a > > > >+draft > > > >w/o further annotations (even with —-tree-line-length). > > > >Thanks, > > > >Acee > > > > > > > > > > > >On 9/15/17, 6:21 AM, "netmod on behalf of Ladislav Lhotka" > > > ><[email protected] on behalf of [email protected]> 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. > > > >> > > > >>Lada > > > >> > > > >>> > > > >>> > > > >>> Andy > > > >>> > > > >>> > > > >>> On Thu, Sep 14, 2017 at 8:33 AM, Joe Clarke <[email protected]> wrote: > > > >>> > I've been hacking on pyang, and I changed tree.py to add the > > > >>> > enum > > > >>>values > > > >>> > for enumeration types and identiyref bases for identityref types. > > > >>>Here > > > >>> > is an example: > > > >>> > > > > >>> > module: yang-catalog > > > >>> > +--rw catalog > > > >>> > +--rw modules > > > >>> > | +--rw module* [name revision organization] > > > >>> > | +--rw name yang:yang-identifier > > > >>> > | +--rw revision union > > > >>> > | +--rw organization string > > > >>> > | +--rw ietf > > > >>> > | | +--rw ietf-wg? string > > > >>> > | +--rw namespace inet:uri > > > >>> > | +--rw schema? inet:uri > > > >>> > | +--rw generated-from? enumeration [mib, code, > > > >>> > not-applicable, native] > > > >>> > | +--rw maturity-level? enumeration [ratified, > > > >>> > adopted, initial, not-applicable] ... > > > >>> > +--rw protocols > > > >>> > | +--rw protocol* [name] > > > >>> > | +--rw name > > > >>> > identityref -> protocol > > > >>> > ... > > > >>> > > > > >>> > My questions are: > > > >>> > > > > >>> > 1. Is this useful? > > > >>> > > > > >>> > 2. If so, can this be added to pyang (happy to submit a PR) and > > > >>> > draft-ietf-netmod-yang-tree-diagrams? > > > >>> > > > > >>> > 3. What changes to the output format would you recommend? > > > >>> > > > > >>> > Thanks. > > > >>> > > > > >>> > Joe > > > >>> > > > > >>> > _______________________________________________ > > > >>> > netmod mailing list > > > >>> > [email protected] > > > >>> > https://www.ietf.org/mailman/listinfo/netmod > > > >>> > > > >>> _______________________________________________ > > > >>> netmod mailing list > > > >>> [email protected] > > > >>> https://www.ietf.org/mailman/listinfo/netmod > > > >>-- > > > >>Ladislav Lhotka > > > >>Head, CZ.NIC Labs > > > >>PGP Key ID: 0xB8F92B08A9F76C67 > > > >> > > > >>_______________________________________________ > > > >>netmod mailing list > > > >>[email protected] > > > >>https://www.ietf.org/mailman/listinfo/netmod > > > > > > > > > _______________________________________________ > > netmod mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/netmod > _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
