Push out FIXMEs to 6.0.0
[yangtools.git] / yang / yang-data-api / src / main / java / org / opendaylight / yangtools / yang / data / api / schema / NormalizedNode.java
index c1aa3bbf50deb17fc8d4fce225b890a63b1cb886..e7ae0eeebc7605ae7272d0b1f00c8c3a50812e31 100644 (file)
@@ -7,22 +7,48 @@
  */
 package org.opendaylight.yangtools.yang.data.api.schema;
 
+import org.eclipse.jdt.annotation.NonNull;
 import org.opendaylight.yangtools.concepts.Identifiable;
 import org.opendaylight.yangtools.yang.common.QName;
-import org.opendaylight.yangtools.yang.data.api.YangInstanceIdentifier;
+import org.opendaylight.yangtools.yang.data.api.YangInstanceIdentifier.PathArgument;
 
 /**
- *
  * Node which is normalized according to the YANG schema
- * is identifiable by {@link YangInstanceIdentifier}.
+ * is identifiable by a {@link org.opendaylight.yangtools.yang.data.api.YangInstanceIdentifier}.
  *
- * See subinterfaces of this interface for concretization
- * of node.
+ * <p>
+ * See subinterfaces of this interface for concretization of node.
  *
  * @param <K> Local identifier of node
  * @param <V> Value of node
  */
-public interface NormalizedNode<K extends YangInstanceIdentifier.PathArgument, V> extends Identifiable<K> {
+/*
+ * FIXME: 6.0.0: NormalizedNode represents the perfectly-compliant view of the data, as evaluated by an implementation,
+ *               which is currently singular, with respect of its interpretation of a SchemaContext. This includes
+ *               leaf values, which are required to hold normalized representation for a particular implementation,
+ *               which may be affected by its understanding of any YANG extensions present -- such as optional type
+ *               handling hints and bindings.
+ *
+ *               Implementations (i.e. the reference implementation and parsers) will need to start using
+ *               yang.common.Uint8 and friends and, if possible, express data validation in terms
+ *               of yang.common.CanonicalValue and yang.common.CanonicalValueValidator.
+ *
+ *               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: 6.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: 6.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'.
+ */
+public interface NormalizedNode<K extends PathArgument, V> extends Identifiable<K> {
     /**
      * QName of the node as defined in YANG schema.
      *
@@ -43,5 +69,5 @@ public interface NormalizedNode<K extends YangInstanceIdentifier.PathArgument, V
      *
      * @return Value of the node, may be null.
      */
-    V getValue();
+    @NonNull V getValue();
 }