Hi, Robert Wilton <[email protected]> wrote: > 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".
This is fine with me. It is something in between (1) and (2) which people preferred. I will add this text. > 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. This is getting off-topic, but if an implementor wants to do this in order to verify his implementation, go for it! It doesn't have to be discussed on this ML. Speaking from own experience of two different implementations, I can tell you that it is a useful test to do ;-) /martin _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
