Page History

...

[
  {
    "action": "ADD",
    "xpath": "/bookstore/categories/[@code=3]",
    "target-data": {
      "code": 3,
      "name": "kidz"
    }
  },
  {
    "action": "DELETE",
    "xpath": "/bookstore/categories/[@code=1]",
    "source-data": {
      "code": 1,
      "name": "Fiction"
    }
  },
  {
    "action": "UPDATE",
    "xpath": "/bookstore/categories/[@code=2]",
    "source-data": {
      "name": "Funny"
    },
    "target-data": {
      "name": "Comic"
    }
  }
]

Reporting of xpaths in Delta between Anchor and JSON payload

In the first API for delta report generation, we have fetch the data nodes from 2 anchors and perform a comparison between each data node present under both anchors. The advantage of this approach is that we get information about the xpaths from the respective data node and hence we can report the Removed, Updated and Added xpaths in the delta report.

For the second API, we will have one anchor and a JSON payload, and here we need to perform the comparison between the data from an anchor and the json payload.

• In order to do so we need to first parse the JSON string provided by the user to some Java Object for comparison with objects returned by the anchor.
• To parse the JSON data we have following options:
  • Parse it to Data Nodes, but doing so requires us to provide the schema of the associated JSON data every time a request is made therefore making the approach schema dependent
  • Parsing to a generic Java object, like a Map, parsing the json data to a Java object would make the approach schema independent but in the process we cannot generate the xpaths of the data nodes present in the JSON payload, as the generation on xpaths is dependent on the Yang data model associated to the JSON
    • By not having the xpaths of all the data nodes of the JSON payload, we can only report the xpaths of Removed and Updated data nodes as those can be fetched from the data nodes present in the anchor. 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.

Problems when parsing to a generic Java Object

...

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

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();
    }

Alternative approach for schema free delta report.

Problem Statement

The problem with 2nd Delta API is that it needs to compare any JSON payload to data stored under an anchor. This JSON payload can be coming from any source and regardless of its schema a delta should be generated between the payload and the data under the anchor.

The preferable approach here would be to parse the JSON payload into DataNodes and then compare the generated DataNodes against the DataNodes under the anchor. This would allow us to have a delta report which is in line with CPS and would enable us to provide crucial detail about the data nodes that is their xpath.

But since the second API accepts any JSON string as an input, one cannot be always sure that the payload will have the same schema as the anchor. And hence the approach of parsing to DataNodes can only happen when the schemas are identical.

In cases where schemas are not identical, there as soon as we attempt to parse the payload to DataNode, CPS will throw an exception terminating the parsing.

The most feasible alternative is to make use of JSON Nodes along with JSON path. Where JSON Nodes and JSON Path are used as a replacement for DataNodes and xPaths respectively.

Use of JSON Nodes and JSON Path

Another alternative approach can be use of JSON Nodes and JSON Path as a replacement for DataNodes and xPaths respectively. In this approach, we can use JSON Paths to identify if a JSON Node has been added or deleted and if two identical JSON Paths exist in source anchor and the JSON payload then a comparison of JSON Nodes will be performed.

In order to achieve this the overall approach will be divided into two parts,

First, we determine if the JSON payload has the same schema as the data within the anchor. To do so the payload will be parsed against the schema information retrieved from the anchor and DataNodes will be formulated using this schema. If the parsing of JSON payload to DataNodes fails, then this would mean the schema differs and we switch to the alternative approach. If the parsing is successful we can go ahead with generating delta between the DataNodes.

If the parsing fails then, the data from source anchor needs to be fetched as a JSON string. And then both the JSON payload and the data from the anchor will be parsed to JSON Nodes and their respective JSON paths.

Once this is done a separate algorithm will be used to find the delta between JSON Nodes

...

• 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 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

Pros and Cons of each workaround

...

• Limited to only 1 data node at a time

...

• CPS is dependent and built around xpath, hence this will be a major inconsistency
• If implemented, we will need to generate JSON paths for both, the data from anchor and the JSON payload,
• making the operation more expensive

...

.

...