Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Table of Contents

Issues & Decisions

#Sub InterfaceMethodScenario

HTTP Response codes

to be implemented

Notes1Data

Proposed API:

GET-/v2/dataspaces/

#

Issue

Notes 

Decision

1Add or Delete leaves (optional leaves) handle as UPDATE or ADD/DELETE?

The delta report proposed follows the Json Patch format of representing the differences between 2 json. Going by the general convention, referring RFC-6902:

  • Add: If the target location in the source document specifies an object member that does not already exist, and a new member is added to the object, then its an add operation
  • Remove: if the target location in the source document already had a member and the member was removed from the target document then its remove operation
  • Replace/Update: If the target location specifies an object member that does exist, and that member's value is replaced, then its a replace operation
  • Here target location is equivalent to the path of particular leaf
  • So, there it should be Add/Delete.
  • Discussed in detail below
Add/Delete as per notes on the left2How to handle multiple changes at different levels?
Example: 
  • if you compare multiple levels and say a grandchild of a the node you are comparing has been added or deleted is that an UPDATE  or just a ADD/DELETE at that level

There could be Many more complex scenarios....

Replied below

3More scenarios need to be explored and documented in detail. Such as handling arrays within a json, handling child/grandchild changes.

CPS Delta feature Exceptions

Where ever possible the Delta Feature will throw the same exceptions as defined in CPS core. If any new exception for the delta feature are required the following will be updated here.

HTTP response codes for Delta between 2 Anchors API

The proposed API will be part of the CPS Data Interface. The following response codes will be returned by the API:

JSON data. Apart from this the delta is dependent on individual data nodes of the JSON data, this is because the delta report will contain the action, xpath and the source/target data. And since the xpaths are unique to data nodes and not leaf data, every delta entity in delta report will be between 2 data nodes. Going by the general convention and referring RFC-6902:

  • Add: If a data node exists only in the target location (target anchor or JSON payload) then it will be considered an ADD action and all the leaf data under this data node and the child data nodes of the aforementioned data node will be considered as newly added data.
    • The child data nodes will be reported separately in the delta report because these data nodes can be individually identified with their unique xpaths.
  • Remove: If a data node exists only in the source location (source anchor) but is not in the target location (target anchor or JSON payload) then this will be considered as a REMOVE operation. All the leaf data under this data node and the child data nodes of the aforementioned data node will be considered as removed.
    • The child data nodes will be reported separately in the delta report because these data nodes can be individually identified with their unique xpaths.
  • Update: If a data node exists both, in the source and target location then the individual leaf nodes of this data node are compared to find any changes in the data. If the data is changed then it is reported as an UPDATE action because leaf data of an already existing data node are updated here.
    • only the leaves which are added, deleted or modified are reported in delta report. Any unmodified leaf is not reported.
    • Child data nodes are evaluated individually, if a child node is added it's an ADD action, if a child node is removed its REMOVE action and if a child node exists in both locations, then the leaves are evaluated for any changes which are reported as UPDATE action.
Updated as per notes.
2How to handle multiple changes at different levels?
Since the delta report will contain the xpaths of data nodes changed, so for changes at multiple levels i.e., parent and child data nodes, the approach will be to handle each data node individually and report them in the delta report. 

3More scenarios need to be explored and documented in detail. Such as handling arrays within a json, handling child/grandchild changes.
scenarios such as data nodes at multiple levels, arrays and lists are covered.

CPS Delta feature Exceptions

Wherever possible the Delta Feature will throw the same exceptions as defined in CPS core. If any new exception for the delta feature is required, the following will be updated here.

HTTP response codes for Delta between 2 Anchors API

The proposed API will be part of the CPS Data Interface. The following response codes will be returned by the API:

#Sub InterfaceMethodScenario

HTTP Response codes

to be implemented

Notes
1Data

Proposed API:

GET-/v2/dataspaces/{dataspace-name}/anchors/{anchor-name}/delta?anchor2={anchor-name}?xpath={xpath}&descendants={descendants}

Proposed method name:  getDeltaByDataspaceAndAnchors()

Generate a delta report between 2 anchors in a given dataspace.

  • 200 (OK)
    • success
  • 400
    • dataspace not found
      DataspaceNotFoundException
    • anchor not found
      AnchorNotFoundException
    • Data node not found
      DataNodeNotFoundException
    • invalid xpath
      CpsPathException
  • 500
    • unexpected error
AnchorNotFoundException should provide the name of missing anchor from the given two anchor names.

...

Code Block
titleResponse body should contain anchors delta report (added/deleted/modified configuration) as below.
collapsetrue
[
  {
    "action": "ADD",
    "xpath": "/bookstore/categories/[@code=3]",
    "target-data": {
      "code": 3,
      "name": "kidz"
    }
  },
  {
    "action": "DELETEREMOVE",
    "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"
    }
  }
]

...

Gliffy
size600
displayNameCPS Delta Flowchart
nameCPS Delta Flowchart
pagePin2

...

Additional Details

Format/Conventions to be used for Delta Report

There are several ways of representing the differences between JSON but here we discuss the JSON Patch format of representing these differences because the proposed Delta report closely represents JSON patch with a few differences. This approach focuses in producing another JSON document that represents the differences between the two JSON's that have been compared.The delta report format is based on two RFCs namely RFC 6902 and RFC 9144 . A detailed comparison of the RFCs can be found here.

RFC 6902 JSON Patch

JSON Patch defines a JSON document structure for expressing a sequence a sequence of operations to apply to a JavaScript Object Notation(JSON) document; it is suitable for use with the HTTP PATCH method. The "application/json-patch+json" media type is used to identify such patch documents.

But in it can also be used to get the differences between two JSON as the JSON patch document represents an array of objects. where each object represents a single operation(op), path and value.

Here the The notation of "operation" is used as because the same JSON Patch document can be used to perform HTTP Patch operations. But The the operations field can be used as a reference to decide how the "action" field should function in the implementation of Delta report.

...

OperationDescriptionDelta report equivalent
addAdds the value at the target location; if the value exists in the given location, it’s replacedif the value is not present in the source json, but was found in the comparand json, then it should be considered an "add" action.
removeRemoves the value at the target locationif a value was present at the source json, but was not found in the comparand json, then it should be considered as "delete" action.
replaceReplaces the value at the target locationif a value is present in the source json, but an updated value is present in the comparand json, then it will be considered as "update" action.
moveRemoves the value at a specified location and adds it to the target locationN/A
copyCopies the value at a specified location to the target locationN/A
testTests that a value at the target location is equal to a specified valueN/A

...

RFC 9144 YANG data model that defines RPCs intended to be used in conjunction with NETCONF [RFC6241] or RESTCONF [RFC8040]. These RPCs RFCs allow a client to request a server to compare two NMDA datastores and report any differences.

...

  • The core of the RFC 9144 solution is a new management operator, <compare>, that compares the data tree contents of two datastores. The operation checks whether there are any differences in values or in data nodes that are contained in either datastore and then returns any differences as output. The output is returned in the format specified below.
  • The RFC6902 approach to Delta report generation follows the JSON patch format. A JSON Patch document represents an array of objects, where each object contains exactly one operation, path and associated values. The operation can have following values: add, remove, replace, move, copy and test. The path represents the JSON patch format and the values contain the difference in source and target values.

...

CPS Delta Report Format

Based on the RFC documentations mentioned above, CPS Delta Report is designed in the format specified in the following code block. This Delta Report takes the features from both RFCs that are best suited for CPS and fulfill it's requirementson the RFC documentations mentioned above, CPS Delta Report is designed in the format specified in the following code block. This Delta Report takes the features from both RFCs that are best suited for CPS and fulfill its requirements.

The format of Delta report has following key take aways from the above mentioned RFCs:

  • The "op" field from RFC 6902 is replaced with "action" field becaus in CPS we want to report the action that was performed on the data. And this field can have 3 predefined values: ADD, REMOVE and UPDATE.
  • The xpath is used in CPS to uniquely identify individual data nodes and is used in place of JSON path as defined in the two RFCs
  • The source-data and target-data fields are used from RFC9144 to report the data that has been added, removed or updated. This approach properly categorizes the data instead of grouping it under the one "value" field as in RFC6902.
Code Block
titleDelta Report Format for CPS
collapsetrue
[
  {
    "action": "ADD",
    "xpath": "/bookstore/categories/[@code=3]",
    "target-data": {
      "code": "3,",
      "name": "kidz"
    }
  },
  {
    "action": "REMOVE",
    "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"
    }
  }
]

...