Hi Reshad,
I follow your opinion on types and enums, we can always discuss how we can
visualize this, maybe even defining different types of coverage and so.. we are
just starting the discussion at the end.
Regarding choice/cases, yes , the idea is to cover them all and rely on the
already defined yang tree to visualize them well.
I created a toy example, since I was curious of how it could look like in the
prototypes, I am attaching the output after my signature.
Thanks,
Camilo C
Module:
module example-ietf-wg-choice {
namespace http://example.com/ietf-wg-choice;
prefix wg;
organization
"IETF";
container ietf-member {
description "";
choice favorite-working-group {
description
"Pick one working group to join: NETMOD or NETCONF.";
case netmod {
leaf netmod-draft {
type string;
description "Name a draft";
}
}
case netconf {
leaf netconf-server {
type string;
description "Name a server";
}
leaf netconf-rfc {
type string;
description "Name a rfc";
}
}
}
}
}
A Couple of examples:
{
"example-ietf-wg-choice:ietf-member": {
"netmod-draft": "draft-cool-yang-module-00"
}
}
{
"example-ietf-wg-choice:ietf-member": {
"netconf-rfc": "RFC6241"
}
}
Basically we are covering both options but not covering a leaf in one.
Here is what our prototype shows for the NON-covered tree, it might not be
printing the choices correctly (prints them as normal leafs). This is fine for
now, but it should be clear that favorite-working-group and Netconf are a
choice/case…
module: example-ietf-wg-choice (uncovered nodes only)
+--rw ietf-member
+--rw favorite-working-group
+--rw netconf
+--rw netconf-server?
Here is what yangson shows. The output is a proper tree this time. Probably
yangson does not “visit” the choice/case intermediate nodes, that’s something
that needs to be tune in the future for easily showing the non-covered tree..
+--rw example-ietf-wg-choice:ietf-member {2}
+--rw (favorite-working-group)? {0}
+--:(netconf) {0}
| +--rw netconf-rfc? {1}
| +--rw netconf-server? {0}
+--:(netmod) {0}
+--rw netmod-draft? {1}
From: Reshad Rahman <[email protected]>
Reply to: Reshad Rahman <[email protected]>
Date: Thursday, 13 November 2025 at 09:37
To: NetMod WG <[email protected]>,
"[email protected]"
<[email protected]>, Camilo Cardona
<[email protected]>
Subject: Re: Comments on draft-cardona-claise-onion-yang-coverage-00
Resent from: <[email protected]>
Resent to: <[email protected]>, <[email protected]>
Resent date: Thu, 13 Nov 2025 06:37:30 -0800 (PST)
Hi Camilo,
For unions, I agree it can be tricky. The reason I mentioned unions is because
there may be restrictions (must-stmt) on the different union branches. But this
is probably not the most common case.
For enums, I was/am not convinced we need to cover all values but thought it'd
be good to get some thoughts on it.
I didn't ask about choice/case, I assume all nodes under them are counted as if
there was no choice/case?
Regards,
Reshad.
On Tuesday, November 11, 2025 at 07:35:50 PM EST, Camilo Cardona
<[email protected]> wrote:
Hello Reshad,
Thanks for the support!
Also, thanks for starting to imagine how the coverage tool should work
(therefore also how coverage should be defined), here are my initial thoughts
on your points:
- Presence container: this should be a must, also noting that presence
containers can also be empty, therefore, we cannot count only on the leaves
within to account for coverage.
- coverage in groupings: Benoit and I were thinking about this one too. We
might need to think about how to define this, but it is indeed a very practical
application, and we really want this to be a practical tool.
- Types in a union: this can be a bit tricky to visualise, but it can certainly
be useful, let us think about it.
Thanks!
Camilo C
From: Reshad Rahman <[email protected]>
Reply to: Reshad Rahman <[email protected]>
Date: Friday, 7 November 2025 at 12:42
To: NetMod WG <[email protected]>,
"[email protected]"
<[email protected]>
Subject: Comments on draft-cardona-claise-onion-yang-coverage-00
Resent from: <[email protected]>
Resent to: <[email protected]>, <[email protected]>
Resent date: Fri, 7 Nov 2025 09:42:51 -0800 (PST)
Hi Camilo, Benoit,
As (I think) I mentioned in the meeting chat, I support this work, very useful.
Often when reviewing documents containing YANG modules, I've asked myself how
complete the examples are. Some authors do include minimal examples just to be
able to tick the checkbox... So thanks from all YANG reviewers and YANG Doctors.
I would like coverage to include more than simple calculation on leaf nodes,
for example:
- If a leaf is of type union, all union variants should be counted. e.g. if a
module has 1 leaf node which has 2 union variants (string and int) and the
example covers only 1 union variant for that leaf, IMO the coverage should be
50%.
- Presence containers. I think they should be included in the calculation since
they're often equivalent to "enable" flag.
- Enums. Should all enum values be covered or just 1 is enough?
- If a module has groupings which aren't used in the document, the coverage
should include leaf nodes in the groupings (can be done by an example module
which uses the groupings).
Regards,
Reshad.
_______________________________________________
netmod mailing list -- [email protected]
To unsubscribe send an email to [email protected]
