Page Comparison

Grouping of create and remove operations in delta report is fairly straightforward because the two do not Grouping of create and remove operations in delta report is fairly straightforward because the two do not lead to complex scenarios. If a data node is added all its child nodes are also added, same applies in case of remove operation where if a parent node is removed all its child nodes are also removed. Similarly, operations on parent-child nodes like create+update, create+remove, remove+update and remove+createare not possible because if a parent is added or removed the child cannot be added, removed or updated. Hence, the grouping of data nodes which are either added or removed is simpler.

...

• In order to find the values that have been updated between two data nodes, each leaf node present under the source data node is to be accessed and compared to the leaf node present under the target data node. In doing so all the information about the data nodes relation to other data nodes is lost, because the algorithm first flattens all the data nodes into a linear structure for easier comparision.

• Then the algorithm accesses each the source and target data node based on their xpath, then accesses

• When it finds source and target data nodes having the same xpath, we fetch the individual leaves nodes of the said data node, which these leaves are then compared and based on if any changes detected the leaves are added to the delta report.
  Since the data is accessed at a low level (leaf node) to generate the delta report, it becomes impossible to reconstruct the data node back and represent the updated data in the original JSON/XML structure. Therefore, the best approach is to provide the delta of updated nodes individually irrespective of the fact that they are in a parent-child relationship.

• Reconstructing the data node to represent the original data structure would require some kind of data manipulation which is not suitable as it could lead to discrepancies in the delta that is generated.

• The same is described below in form of the flowchart.

For the following scenarios we take the following source and target data as a common starting point

[
  {
    "parent": {
      "leaf-1": "leaf-1 data",
      "leaf-2": "leaf-2 data",
      "child": {
        "child-1 data": "child-1 data",
        "child-2 data": "child-2 data"
      }
    }
  }
]

[
  {
    "parent": {
      "leaf-1": "leaf-1 data",
      "leaf-2": "leaf-2 updated data",
      "child": {
        "child-1 data": "child-1 updated data",
        "child-2 data": "child-2 data"
      }
    }
  }
]

Mechanism for comparison

Flattening of Data Nodes before comparing

Flowchart: Mechanism for comparison of Data Nodes to check for updates

...

If a parent and its child are updated, then both of them should be reported as 2 separate update operations. This is because when comparing data nodes that have been updated, it is not possible to maintain the parent-child relation of the 2 data nodes as explained above.

[
  {
    "

parent":

 {
      "

leaf-1": "

leaf-1 data",
      "

leaf-2":

 "leaf-2 data",
      "child": {
        "

child-1 data": "

child-1 data",
      

  "child-2 data": "child-2 data"
 

}

    }
  

}
]

[
  {
    "

parent": 

{

"leaf-1": "leaf-1 data",
  

"

leaf-2": "

leaf-2 updated data",
    

  "

child

":

 {
        "child-1 data": "

child-1 updated data",
      

  "child-2 data": 

"child-2 data"
      

}

    }
  

}
]

[
  {
    "dataaction": "updated dataupdate",
      }"xpath": "/parent",
    "sourceData": [
      {
    ]   }
]

Scenario 2: Parent is updated, child is added or removed

In a scenario where parent node is updated and its child node either added or removed, then in such a scenario each node must be reported separately and grouped based on their respective operation. For example, if a parent is updated and 2 child nodes are either added. Then the delta report should have 2 entries, first an update entry containing details of the updated parent node and the second a create entry containing both the child nodes, grouped together.

[ "leaf-2": "leaf-2 data"
      }
    ],
    "targetData": [
      {
        "leaf-2": "leaf-2 updated data"
      }
    ]
  },
  {
    "action": "update",
    "xpath": "/parent/child",
    "sourceData": [
      {
        "child-1 data": "oldchild-1 data"
      }
    ],
    "targetData": [
      {
        "child-1 data": "child-1 updated data"
      }
    ]
  },
  {
    "action": "create",
    "xpath": "/parent/child",
    "targetData": [
      {
        "data": "child data",
        "grand-child": [
          
]

Scenario 2: Parent is updated, child is added or removed

In a scenario where parent node is updated and its child node either added or removed, then in such a scenario each node must be reported separately and grouped based on their respective operation. For example, if a parent is updated and 2 child nodes are either added. Then the delta report should have 2 entries, first an update entry containing details of the updated parent node and the second a create entry containing both the child nodes, grouped together.

[
  {
    "parent": {
      "

leaf-1": "

leaf-1 data",
      "leaf-2": "leaf-2 data"
    }
  }
]

[
  {
  

  "parent": {
   

   "leaf-1": 

"leaf-1 data",
  

Scenario 3: Parent is updated, child 1 is added or removed, child 2 is updated (Siblings scenario) 

If the parent and one of its children are updated while another child is added or removed then in such a case, the parent and updated child will be reported individually as two update operations while the added/removed child would be reported as a separate create/remove operation.

    "leaf-2": "leaf-2 updated data",
      "child": {
        "child-1 data": "child-1 data",
        "grand-child": [
          {