On 01/16/2018 06:34 PM, joel jaeggli wrote:
On 1/16/18 8:01 AM, Robert Wilton wrote:
On 16/01/2018 15:40, Martin Bjorklund wrote:
Vladimir Vassilev <[email protected]> wrote:
<snip>
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 ;-)
I would hope that we are not, as the diagrams are programmatically
generated if you wanted to for example validate them one should do that
from the sources.
Approaches that result in the most easily human readable, followed by
consistency between tools is probably better for that. That said this is
almost the indentation wars so the proscriptive it gets the more dissent
you can probably find (e.g. 3).
To make it clear I think 1) works with the text proposed by Martin.
As said I posted the pyang alignment algorithm description in a sort of
2) variant only for reference on the mailing list since I implemented
that too. Starting indentation war was not my intention.
As for the automated validation of the tree diagrams as an added value
to the human readability I have the following thoughts. I would like to
be able to compare unlimited line length tree outputs generated by
different YANG compilers for equality. This is mainly a way to have some
partial common denominator output for validating YANG is correctly
compiled which we did not have until now. For example as soon as I have
support for Schema mount I would compare the tree output with another
tool known to work and add some testcases based on that. I do not see
any automated alternative for doing this except writing NETCONF chat
scripts (also module specific), or writing not only YANG module specific
but also API specific test cases as 3rd option. 1) does not compromise
this automated validation option since space sequences can be collapsed
to single space. If the alignment algorithm was creating a possibility
for nontrivial output variation then I would have supported strongly 3)
but this is not the current case.
Vladimir
In summary, (2) is my preference, followed by (1), followed by (3).
Thanks,
Rob
/martin
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
