On 16/01/2018 15:40, Martin Bjorklund wrote:
Vladimir Vassilev <vladi...@transpacket.com> wrote:
On 01/16/2018 11:56 AM, Martin Bjorklund wrote:

Vladimir Vassilev <vladi...@transpacket.com> 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
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
.


_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Reply via email to