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

[Robert Wilton <[e-mail]>]

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.

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
> .
>