https://jira.opendaylight.org This file is an XML representation of an issue en-us 8.20.10 820010 22-06-2022 https://jira.opendaylight.org/browse/YANGTOOLS-1415 yangtools <p>We currently expect the inference to correctly point to the schema tree parent of the node that is being parsed.</p> <p>This unfortunately is not entirely correct, as RESTCONF demonstrates: after parsing the data tree path (from URL), it also has to peek at the document to determine the additional YangInstanceIdentifier steps required for the document root to be reached and adjust the inference it passes to XmlParserStream. JSON codec does something different – it seems to be able to recover and we adjust the path after the parser result. See JsonNormalizedNodeBodyReader and XmlNormalizedNodeBodyReader for details.</p> <p>What we really want to achieve is a single-pass parsing environment, where RESTCONF will give us the data tree identifier (e.g. YangInstanceIdentifier) and we figure out the missing steps as part of initialization – and communicate those back to it.</p> <p> </p> YANGTOOLS-1415

Deal with leading YangInstanceIdentifier fragment

Improvement High In Progress Unresolved Robert Varga Robert Varga pt Mon, 28 Mar 2022 21:27:49 +0000 Thu, 18 Jan 2024 10:42:40 +0000 11.0.6 13.0.2 codecs 0 2 <p>The trouble here is that NormalizedNodeResult, from whence we take the resulting payload is a NormalizedNode implementation contract, which is not concerned with actual addressing.</p> <p>The contract here revolves around XmlParserStream.parse() and JsonParserStream.parse(): these are invoked after setting up the pipeline and end up processing a single document. As such, their current return value, which is the stream itself, is never used.</p> <p>As such, we need to define some sort of interface that both parsers implement, so that aside from setup (which should be a staged builder), the final bit of execution and evaluating the result is the same.</p> <p>This goes a bit deeper. RESTCONF essentially has two modes of parsing:</p> <ol> <li>PUT, where we know the exact YangInstanceIdentifier of the resource</li> <li>POST, where we know the YangInstanceIdentifier of the parent (sans the prefix mentioned here)</li> </ol> <p>At least the XML codec fails to detect when the body of a PUT request does not match the identifier, for which we have a rather ugly dance (involving first parsing to org.w3c.dom.Document).<br/> At the end of the day, I think we can get away with just providing two static methods, which will do the correct thing &#8211; so that we do not have to worry about the intermediate setup leaking.</p> <p>The first method should deal with a PUT, validating whether the document element matches the requested Inference. There is a twist here, as while this method is universally useful, the way it deals with empty YangInstanceIdentifier is different between NETCONF and RESTCONF &#8211; while the former wants a revision of SchemaContext.NAME, the latter wants the ietf-restconf:name.<br/> The second method should deal with a POST, and should be returning the path prefix described above.</p> <p>There is also a slight wrinkle we need to deal with: PUT on YangInstanceIdentifier.empty() needs to take an expected NodeIdentifier, as the datastore resource in RESTCONF has a different name than in NETCONF.<br/> We therefore need two methods here &#8211; and the one taking YangInstanceIdentifier must reject empty instance identifiers with IAE.</p> <p>We should capture this contract in an interface ... somewhere, somehow.</p> Blocks NETCONF-911 Development Rank 0|i041w7: