SDK metadata to assist migration of existing notices #1226

In our implementation, we effectively do a comparison between two versions of the fields.json and extract the nodes and fields that have been added, moved or removed and then use that information to generate xslt files we can apply to achieve the necessary transformation of our data structure.

Having this information provided to us in the SDK would probably not have a huge impact on our approach, but it would at least allow us to cut out the "cherry picking" part.

We are looking into adding such data into SDK 2+ in a "migration" folder of the SDK you will have an index.json:

{
 "baseline" : "2.0",
 "deltas" : [ "2.1" ]
}

This is an entry point. From there you can find a "2.1.json" file for example (dummy data for illustration):

{
 "sdkVersion" : "2.1",
 "replaced" : {
 "fields" : [ {
 "from" : "BT-123-Lot",
 "to" : "BT-124-Lot"
 }, {
 "from" : "BT-512-Organization",
 "to" : "BT-512-Company"
 } ],
 "nodes" : [ {
 "from" : "ND-OldGroup",
 "to" : "ND-NewGroup"
 } ],
 "codelists" : [ {
 "from" : "eforms-currency",
 "to" : "currency"
 } ],
 "codes" : [ {
 "from" : "eforms-currency.EUR",
 "to" : "currency.EUR"
 }, {
 "from" : "main-activity.gas-oil",
 "to" : "main-activity.gas-extraction"
 }, {
 "from" : "main-activity.gas-oil",
 "to" : "main-activity.oil-extraction"
 }, {
 "from" : "old-list.combined-a",
 "to" : "new-list.unified"
 }, {
 "from" : "old-list.combined-b",
 "to" : "new-list.unified"
 } ]
 }
}

As you can see this can also handle a many to one or one to many, which can be useful for code list codes for example.
A simple add or remove is not the most interesting as it can be inferred by a diff on the SDKs (as some already do), but a replacement via the provided "replaced" is more interesting as it helps with automatic notice migration. Full automation is difficult due to the case of one to many, but that case is rare and knowing it exists is also of interest as it shows some decision must be taken or that migration may be impossible.

With this format we can also support "added" and "removed":

 "added" : {
 "fields" : [ {
 "id" : "BT-123",
 "remarks" : "New field introduced in SDK 2.2.0"
 } ],
 "nodes" : [ {
 "id" : "ND-456",
 "remarks" : "New node for xyz"
 }, ... ]
 }

Any of the items may have a "remarks" key value which we could provide for human readers.
This may be the definitive JSON format unless we come up with better ideas.
For a start we will focus on the "replaced" as this is hard to infer from simple asset removals and additions.