+ * This notably means that to efficiently implement any sort of lenient parsing, we need a separate
+ * concept which contains an unverified, potentially non-conformant data tree, which the consumer needs
+ * to check/fixup if it wishes to use it as a NormalizedNode. Such a concept should be called
+ * "UnverifiedData".
+ *
+ * FIXME: 8.0.0: Once we have UnverifiedData, we should really rename this to "NormalizedData" or similar to unload
+ * some "Node" ambiguity. "Node" should be a generic term reserved for a particular domain -- hence 'node'
+ * can be used to refer to either a 'schema node' in context of yang.model.api, or to
+ * a 'normalized data node' in context of yang.data.api.
+ *
+ * FIXME: 8.0.0: Well, not quite. The structure of unverified data is really codec specific -- and JSON and XML
+ * do not agree on details. Furthermore things get way more complicated when we have a cross-schema
+ * boundary -- like RFC8528. Hence we cannot really have a reasonably-structured concept of unverified
+ * data. Nevertheless, this interface should be named 'NormalizedData'.