Re: [netmod] WGLC - draft-ietf-netmod-yang-tree-diagrams

["t.petch" <[e-mail]>]

----- Original Message -----
From: "Robert Wilton" <[e-mail]>
Sent: Wednesday, January 17, 2018 10:44 AM

> Hi Tom,
>
>
> On 17/01/2018 09:52, t.petch wrote:
> > ----- Original Message -----
> > From: "Alexander Clemm" <[e-mail]>
> > 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
> > .
> >
>