/* * Copyright (c) 2023 PANTHEON.tech, s.r.o. and others. All rights reserved. * * This program and the accompanying materials are made available under the * terms of the Eclipse Public License v1.0 which accompanies this distribution, * and is available at http://www.eclipse.org/legal/epl-v10.html */ package org.opendaylight.yangtools.yang.data.api.schema.stream; import static java.util.Objects.requireNonNull; import java.io.InputStream; import java.util.List; import org.eclipse.jdt.annotation.NonNullByDefault; import org.opendaylight.yangtools.yang.common.UnresolvedQName.Unqualified; import org.opendaylight.yangtools.yang.data.api.YangInstanceIdentifier; import org.opendaylight.yangtools.yang.data.api.YangInstanceIdentifier.NodeIdentifier; import org.opendaylight.yangtools.yang.data.api.YangInstanceIdentifier.PathArgument; import org.opendaylight.yangtools.yang.data.api.schema.ContainerNode; import org.opendaylight.yangtools.yang.data.api.schema.NormalizedNode; import org.opendaylight.yangtools.yang.model.api.EffectiveStatementInference; /** * Interface to parsing of {@link InputStream}s containing YANG-modeled data. While the design of this interface is * guided by what a typical implementation of a RESTCONF server or * client might require, and it is not limited solely to that use case and should be used wherever its methods provide * the required semantics. * *
* The core assumption is that the user knows the general context in which a particular document, provided as an * {@link InputStream}, needs to be interpreted. * *
* In RESTCONF that context is provided by the HTTP request method and the HTTP request URI. On the server side these * expect to be differentiated between requests to *
* This method's signature is a bit counter-intuitive. {@code rootNamespace} and {@code rootName} collectively * encode the expected root element, which may not be expressed in the underlying YANG data model. * *
* The reason for this is that YANG does not define an explicit {@link NodeIdentifier} of the datastore root * resource, but protocol encodings require this conceptual root to be encapsulated in protocol documents and the * approaches taken differ from protocol to protocol. NETCONF operates in terms of YANG-modeled RPC operations, * where this conceptual root is given an anchor -- {@code get-config} output's {@code anyxml data}. RESTCONF * operates in terms of HTTP payloads and while it models such an anchor, it is rather unnatural * {@code container data} with description defining its magic properties and it is not feasible for YANG parser * to help us with that. * *
* Therefore this method takes the name of the root element in two arguments, which together define its value in * both JSON-based (module + localName} and XML-based (namespace + localName) encodings. Implementations of this * method are expected to use this information and treat the root element outside of their usual YANG-informed * processing. * *
* For example, XML parsers will pick {@code containerName.getNodeType().getNamespace()} to match the root element's
* namespace and {@code containerName.getNodeType().getLocalName()} to match the element's local name. JSON parsers,
* on the other hand, will use {@code moduleName} and {@code rootName.getLocalName()} to match the top-level JSON
* object's sole named member.
*
* @param containerName expected root container name
* @param moduleName module name corresponding to {@code containerName}
* @param stream the {@link InputStream} to parse
* @return parsed {@link ContainerNode} corresponding to the data store root, with its {@link ContainerNode#name()}
* equal to {@code containerName}.
* @throws NullPointerException if any argument is {@code null}
* @throws NormalizationException if an error occurs
*/
NormalizationResult