From c5e5406cfb595523474c7a37035968af8610de37 Mon Sep 17 00:00:00 2001 From: Robert Varga Date: Sat, 19 Sep 2020 15:32:16 +0200 Subject: [PATCH] Add clarification around NormalizedNode being identifiable While we do not have enough time to address the entire issue, update at least documentation so as we have a bit more progress towards splitting identifier from NormalizedNode. JIRA: YANGTOOLS-1074 Change-Id: Icc742a1b1a5ab65fd01f13abfcba68af0e3eea43 Signed-off-by: Robert Varga --- .../rfc8528/data/api/MountPointContext.java | 13 ++++++++++--- .../yangtools/rfc8528/data/api/MountPointNode.java | 2 +- .../yang/data/api/schema/NormalizedNode.java | 11 ++++++++--- 3 files changed, 19 insertions(+), 7 deletions(-) diff --git a/yang/rfc8528-data-api/src/main/java/org/opendaylight/yangtools/rfc8528/data/api/MountPointContext.java b/yang/rfc8528-data-api/src/main/java/org/opendaylight/yangtools/rfc8528/data/api/MountPointContext.java index a71e88aa93..de5226c76f 100644 --- a/yang/rfc8528-data-api/src/main/java/org/opendaylight/yangtools/rfc8528/data/api/MountPointContext.java +++ b/yang/rfc8528-data-api/src/main/java/org/opendaylight/yangtools/rfc8528/data/api/MountPointContext.java @@ -14,15 +14,15 @@ import org.opendaylight.yangtools.yang.model.api.EffectiveModelContextProvider; /** * 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. * *

* 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 @@ -45,6 +45,13 @@ import org.opendaylight.yangtools.yang.model.api.EffectiveModelContextProvider; * To support this case, MountPointContext really wants to be Identifiable, 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 { diff --git a/yang/rfc8528-data-api/src/main/java/org/opendaylight/yangtools/rfc8528/data/api/MountPointNode.java b/yang/rfc8528-data-api/src/main/java/org/opendaylight/yangtools/rfc8528/data/api/MountPointNode.java index 2a02e527f4..82db4f2130 100644 --- a/yang/rfc8528-data-api/src/main/java/org/opendaylight/yangtools/rfc8528/data/api/MountPointNode.java +++ b/yang/rfc8528-data-api/src/main/java/org/opendaylight/yangtools/rfc8528/data/api/MountPointNode.java @@ -25,7 +25,7 @@ import org.opendaylight.yangtools.yang.data.api.schema.MixinNode; * seamless. */ /* - * FIXME: 6.0.0: The above is not quite right. DataTree instances should be able to handle mount points and correctly + * FIXME: 7.0.0: The above is not quite right. DataTree instances should be able to handle mount points and correctly * handle them, provided they get enough support from MountPointContext. */ @Beta diff --git a/yang/yang-data-api/src/main/java/org/opendaylight/yangtools/yang/data/api/schema/NormalizedNode.java b/yang/yang-data-api/src/main/java/org/opendaylight/yangtools/yang/data/api/schema/NormalizedNode.java index e7ae0eeebc..f00cf1184d 100644 --- a/yang/yang-data-api/src/main/java/org/opendaylight/yangtools/yang/data/api/schema/NormalizedNode.java +++ b/yang/yang-data-api/src/main/java/org/opendaylight/yangtools/yang/data/api/schema/NormalizedNode.java @@ -23,7 +23,7 @@ import org.opendaylight.yangtools.yang.data.api.YangInstanceIdentifier.PathArgum * @param 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 @@ -38,15 +38,18 @@ import org.opendaylight.yangtools.yang.data.api.YangInstanceIdentifier.PathArgum * 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 and K type argument + * FIXME: YANGTOOLS-1074: eliminate V type argument */ public interface NormalizedNode extends Identifiable { /** @@ -54,6 +57,7 @@ public interface NormalizedNode extends Identifiable< * * @return QName of this node, non-null. */ + // FIXME: YANGTOOLS-1074: eliminate this method QName getNodeType(); /** @@ -69,5 +73,6 @@ public interface NormalizedNode extends Identifiable< * * @return Value of the node, may be null. */ + // FIXME: YANGTOOLS-1074: eliminate this method @NonNull V getValue(); } -- 2.36.6