Hi Tom,
On 17/01/2018 09:52, t.petch wrote:
----- Original Message -----
From: "Alexander Clemm" <[email protected]>
Sent: Wednesday, January 17, 2018 2:20 AM
+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.
<tp>
That's what I thought until Benoit said, and Robert agreed, that
'In the end, the tree view should be browsed with tooling.'
The text based YANG tree diagram (i.e. covered by this draft) doesn't
need to be browsable by tooling. The purpose of these diagrams should
be to go in text documents to help explain and illustrate (to human
readers) the structure of a YANG model.
By "In the end, the tree view should be browsed with tooling.", what I
mean is that I think that tools like YANG catalog will be the long term
way of interacting with and browsing YANG modules. For example, the
link below for the RIP module.
https://www.yangcatalog.org/yang-search/yang_tree.php?module=ietf-rip
This provides an interactive GUI "tree view" of a YANG model, which
should be structurally equivalent as the text tree diagram, but
otherwise the information may be represented in a more visual way. This
will become even more powerful when all of the standard YANG modules are
available together in a single browsable tree.
Hopefully, that clarifies my previous comment.
Thanks,
Rob
i.e. the tree view should be machine readable after which something is
produced for human consumption; not a view I share.
Tom Petch
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.
--- 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
