On 17/01/2018 07:43, Martin Bjorklund wrote:
Alexander Clemm <[email protected]> wrote:
+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. 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.
The last sentence summarizes my personal view. I prefer (1), followed
by (2).
OK, so the "Providing some guidance for how to represent the tree is
good" is along the lines of what I was thinking for the "algorithm"
would be for 2.
E.g. something along the lines of:
"Arbitrary whitespace is allowed between any of the whitespace separated
fields (e.g. <opts> and <type>). Additional whitespace may be used to
column align fields (e.g. within a list or container) to improve
readability".
But just saying implementations can use arbitrary whitespace is also
fine with me. I certainly err on the side of not being overly
prescriptive on this ..
I'm not really a fan of the comparing tree output as a method of
verifying a YANG parser idea.
Thanks,
Rob
/martin
--- 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
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
.
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
.
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
