/**
* A context of either an explicit (RFC8528 Schema Mount instance) or implicit (system root). It encapsulates a data
- * {@link org.opendaylight.yangtools.yang.model.api.SchemaContext} and information resident in {@code schema-mounts}
- * within this hierarchy.
+ * {@link org.opendaylight.yangtools.yang.model.api.EffectiveModelContext} and information resident in
+ * {@code schema-mounts} within this hierarchy.
*
* <p>
* Note this interface should be part of yang-data-api, as it really defines how a NormalizedNode-containerized data
* operates w.r.t. mount points. Further evolution is expected.
*/
/*
- * FIXME: 6.0.0: consider yang-data-api integration
+ * FIXME: 7.0.0: consider yang-data-api integration
*
* The above note does not give the subject enough attention. RFC8528 redefines the YANG data metamodel is significant
* ways in that it ties it with RFC8525/RFC7895. The content of 'schema-mounts' is critical to interpreting
* To support this case, MountPointContext really wants to be Identifiable<MountPointIdentifier>, where it would also
* provide a 'default NodeIdentifier getRootIdentifier()' method. In PathArgument contexts, MountPointIdentifier is
* directly usable anyway.
+ *
+ * 6.0.0-timeframe review:
+ *
+ * The idea with Identifiable is not really that grand, as it goes against our desire to peel identifiers from nodes,
+ * as detailed in YANGTOOLS-1074. This will end up meaning that the root of a NormalizedNode tree does not have to have
+ * an identifier and very much can live on its own -- solving both the SchemaContext name problem as well as NETCONF
+ * interoperability.
*/
@Beta
public interface MountPointContext extends EffectiveModelContextProvider {
* @param <V> Value of node
*/
/*
- * FIXME: 6.0.0: NormalizedNode represents the perfectly-compliant view of the data, as evaluated by an implementation,
+ * FIXME: 7.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
* 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
+ * FIXME: 7.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
+ * FIXME: 7.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'.
+ *
+ * FIXME: YANGTOOLS-1074: eliminate Identifiable<K> and K type argument
+ * FIXME: YANGTOOLS-1074: eliminate V type argument
*/
public interface NormalizedNode<K extends PathArgument, V> extends Identifiable<K> {
/**
*
* @return QName of this node, non-null.
*/
+ // FIXME: YANGTOOLS-1074: eliminate this method
QName getNodeType();
/**
*
* @return Value of the node, may be null.
*/
+ // FIXME: YANGTOOLS-1074: eliminate this method
@NonNull V getValue();
}
Code Review / yangtools.git / commitdiff