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.
> -----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. > > > > 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? Whether they are legal or not should be determined by the schema-mount draft, not by the displaying notation. > > > /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
