[YANGTOOLS-1402] Consider adding YangInstanceIdentifier+NormalizedNode-based codec utilities

Issue split — Mon, 21 Feb 2022 19:33:32 +0000

Users are baffled, time after time, by intricacies of YANG addressing, leading to the need to explain the difference between data tree and schema tree time and time again. When coupled with our additional addressing modes, like YangInstanceIdentifier (which does not match the data tree) and MD-SAL's InstanceIdentifier (which is different still), people tend to do weird things along the lines of "hey, I can get a yang.common.QName, surely that is enough to make this translation, wheee!!!!".

For the most part, such ill-advised attempts seem to work, but in 100% of cases they lead to bugs, just as soon as they encounter edge cases – like what it means to enter a child node or exit to a parent.

This is most apparent when they get the combination of YangInstanceIdentifier and a NormalizedNode and now they are want to correctly instantiate a codec, where they need to supply a proper root pointing at a data tree node in yang.model.api addressing.

In those settings, there typically is enough schema information already available at the call site or the surrounding code (but perhaps not exposed due to the said code failing to understand what is required and hence not propagating the relevant context), as evidenced by ~~YANGTOOLS-1401~~ (and many others before that).

Consider enriching all codecs (XML, JSON, binfmt) with the ability to do a one-shot, no questions asked, execution on a combination of YangInstanceIdentifier and a matching NormalizedNode.

This should use a single static method performing the task, without leaving any residue in terms of AutoCloseable or worrying about performance aspects like reusing the codecs (XML/JSON) or data/schema dictionary (binfmt).

OpenDaylight JIRA

[YANGTOOLS-1402] Consider adding YangInstanceIdentifier+NormalizedNode-based codec utilities