2 * Copyright (c) 2014 Cisco Systems, Inc. and others. All rights reserved.
4 * This program and the accompanying materials are made available under the
5 * terms of the Eclipse Public License v1.0 which accompanies this distribution,
6 * and is available at http://www.eclipse.org/legal/epl-v10.html
8 package org.opendaylight.yangtools.yang.data.api.schema;
10 import org.eclipse.jdt.annotation.NonNull;
11 import org.opendaylight.yangtools.concepts.Identifiable;
12 import org.opendaylight.yangtools.yang.common.QName;
13 import org.opendaylight.yangtools.yang.data.api.YangInstanceIdentifier.PathArgument;
16 * Node which is normalized according to the YANG schema
17 * is identifiable by a {@link org.opendaylight.yangtools.yang.data.api.YangInstanceIdentifier}.
20 * See subinterfaces of this interface for concretization of node.
23 * FIXME: 7.0.0: NormalizedNode represents the perfectly-compliant view of the data, as evaluated by an implementation,
24 * which is currently singular, with respect of its interpretation of a SchemaContext. This includes
25 * leaf values, which are required to hold normalized representation for a particular implementation,
26 * which may be affected by its understanding of any YANG extensions present -- such as optional type
27 * handling hints and bindings.
29 * Implementations (i.e. the reference implementation and parsers) will need to start using
30 * yang.common.Uint8 and friends and, if possible, express data validation in terms
31 * of yang.common.CanonicalValue and yang.common.CanonicalValueValidator.
33 * This notably means that to efficiently implement any sort of lenient parsing, we need a separate
34 * concept which contains an unverified, potentially non-conformant data tree, which the consumer needs
35 * to check/fixup if it wishes to use it as a NormalizedNode. Such a concept should be called
38 * FIXME: 7.0.0: Once we have UnverifiedData, we should really rename this to "NormalizedData" or similar to unload
39 * some "Node" ambiguity. "Node" should be a generic term reserved for a particular domain -- hence 'node'
40 * can be used to refer to either a 'schema node' in context of yang.model.api, or to
41 * a 'normalized data node' in context of yang.data.api.
43 * FIXME: 7.0.0: Well, not quite. The structure of unverified data is really codec specific -- and JSON and XML
44 * do not agree on details. Furthermore things get way more complicated when we have a cross-schema
45 * boundary -- like RFC8528. Hence we cannot really have a reasonably-structured concept of unverified
46 * data. Nevertheless, this interface should be named 'NormalizedData'.
48 public interface NormalizedNode extends Identifiable<PathArgument> {
50 * QName of the node as defined in YANG schema.
52 * @return QName of this node, non-null.
54 // FIXME: YANGTOOLS-1074: eliminate this method: the problem is that it down not with with AugmentationIdentifier
55 // At least we need a 'QNameModule namespace()' method, as that is the common contract.
56 @Deprecated(forRemoval = true)
57 default @NonNull QName getNodeType() {
58 return getIdentifier().getNodeType();
62 // We override here, so that NormalizedNode.getIdentifier() has fewer implementations
63 PathArgument getIdentifier();
66 * Returns the body of this node. While the return value specifies {@link Object}, this method's return value has
67 * further semantics. The returned object must be a well-published contract, such as {@code String},
68 * {@code Collection<NormalizedNode>} or {@code DOMSource}.
70 * @return Returned value of this node.
72 @NonNull Object body();