...
- When parsing the JSON string directly to a java objects we cannot generate the xpaths of all the data nodes present in the JSON payload.
- Doing so brings its own challenges,
- The comparison is dependent on xpaths, because in the current algorithm we use xpaths to identify the data nodes that have been Removed, Updated or Added, and then check for the changes in data present as leaf node in each data node.
- So without the xpaths of the data nodes present in the JSON payload, we can only report the xpaths of data nodes that have been Removed or Updated, as those xpaths can be fetched from the data nodes present under the anchor, against which the JSON payload is being compared to.
- But the xpath of any data node newly added to the JSON payload cannot be generated without proper parsing against the schema model associated to the JSON.
Also, we want the approach to be schema free, whereas the xpath building is a schema dependent activity as can be seen from the method in CPS
Code Block title buildXpath in CPS collapse true public static String buildXpath(final YangInstanceIdentifier.PathArgument nodeIdentifier) { final StringBuilder xpathBuilder = new StringBuilder(); xpathBuilder.append("/").append(nodeIdentifier.getNodeType().getLocalName()); if (nodeIdentifier instanceof YangInstanceIdentifier.NodeIdentifierWithPredicates) { xpathBuilder.append(getKeyAttributesStatement( (YangInstanceIdentifier.NodeIdentifierWithPredicates) nodeIdentifier)); } return xpathBuilder.toString(); }- A few workarounds to this approach can be:
- Limiting the delta between Anchor and JSON payload to only one DataNode, by doing so we can always know that the xpath is limited to one data node, as it is also provided as part of the request to fetch the data node from the anchor.
- using alternative paths for delta between anchor and JSON payload like JSON path
- Not reporting the xpaths in the delta report between anchor and JSON payload
...