----- Original Message ----- From: "Robert Wilton" <rwil...@cisco.com> Sent: Wednesday, January 17, 2018 10:44 AM
> Hi Tom, > > > On 17/01/2018 09:52, t.petch wrote: > > ----- Original Message ----- > > From: "Alexander Clemm" <alexander.cl...@huawei.com> > > Sent: Wednesday, January 17, 2018 2:20 AM > > > >> +1 to (2) as preference, followed by (1). I don't think (3) is needed > > here. The purpose is to make this human-readable and provide readers a > > good sense of the overall structure. > > > > <tp> > > > > That's what I thought until Benoit said, and Robert agreed, that > > > > 'In the end, the tree view should be browsed with tooling.' > The text based YANG tree diagram (i.e. covered by this draft) doesn't > need to be browsable by tooling. The purpose of these diagrams should > be to go in text documents to help explain and illustrate (to human > readers) the structure of a YANG model. > > By "In the end, the tree view should be browsed with tooling.", what I > mean is that I think that tools like YANG catalog will be the long term > way of interacting with and browsing YANG modules. For example, the > link below for the RIP module. > > https://www.yangcatalog.org/yang-search/yang_tree.php?module=ietf-rip > > This provides an interactive GUI "tree view" of a YANG model, which > should be structurally equivalent as the text tree diagram, but > otherwise the information may be represented in a more visual way. This > will become even more powerful when all of the standard YANG modules are > available together in a single browsable tree. > > Hopefully, that clarifies my previous comment. Yes, thank you for the clarification, Tom Petch > > Thanks, > Rob > > > > > i.e. the tree view should be machine readable after which something is > > produced for human consumption; not a view I share. > > > > Tom Petch > > > > > > The authoritative specification is still the .yang itself. Providing > > some guidance for how to represent the tree is good but let's not > > over-engineer this; I believe retaining some flexibility is good. > >> --- Alex > >> > >>> -----Original Message----- > >> ... > >>>> Does anyone else have an opinion on this? I can see three > >>>> alternatives: > >>>> > >>>> 1) allow any number of addtional spaces > >>>> 2) allow any number of addtional spaces + define a suggested > >>>> alignment algorithm > >>>> 3) mandate the alignment algorithm > >>> Definition of symbols should be precise/consistent, so that readers > > can > >>> consistently interpret tree diagrams. > >>> > >>> I think that flexibility in layout should be OK, but the draft > > should provide > >>> guideline to ensure the output is readable, and likely to be broadly > > consistent > >>> (since consistency aids readability). > >>> > >>> If the IETF data modeling group is trying to specify text output > > precisely > >>> enough that it can be screen scraped then we may want to consider > > whether > >>> we are focusing on the right solution ;-) > >>> > >>> In summary, (2) is my preference, followed by (1), followed by (3). > >>> > >>> Thanks, > >>> Rob > >>> > >>>> > >>>> /martin > > . > > > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
