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

[Robert Wilton <[e-mail]>]

On 16/01/2018 15:40, Martin Bjorklund wrote:
> Vladimir Vassilev <[e-mail]> wrote:
>> On 01/16/2018 11:56 AM, Martin Bjorklund wrote:
>>
>>> Vladimir Vassilev <[e-mail]> wrote:
> [...]
>
>>>> There is also undocumented alignment space count function before
>>>> <type> that pyang uses to align the <type> fields of child data leafs
>>>> with common ancestor. If this is specified in the draft the tree
>>>> output can be deterministic and for me this is an advantage. This is
>>>> currently one of the few underspecified pieces of the tree format so I
>>>> had to check pyang implementation in oder to generate same alignment
>>>> space counts and binary identical tree output results.
>>> I think that we at least should write that there may be more than one
>>> space between <opts> and <type>:
>>>
>>>     There may be any number of additional space characters between
>>>     <opts> and <type>.
>> For the sake of the argument (at least having this on the mailing list
>> as reference):
>>
>>    <type> should be aligned at a common offset for all sibling nodes
>>    from the start of <name> by adding trailing spaces. The recommended
>>    offset is 3 plus the length of the longest node name among all
>> sibling nodes
>>    including those siblings defined under choice and case nodes.
>>
>> This is what pyang does now. It is not a perfect solution but it
>> allows identical output down to the bit.
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod
> .
>