MVP: Schemas for Roofing Tiles/Slate + Prodcom

[MebinAbraham]

What is the context of this PR?

Initial PR to add unit level JSON schema definitions for Roofing Tiles, Slate and Prodcom surveys.

Ensure the initial draft makes sense.

Other SDS surveys will be added at a future date, this will formalise the main structure and expected patterns.

Links

Checklist

• Changes to the spec have been added to example schemas in examples/
• JSON Schema definitions have been updated

[berroar]

Looks good, validation working and examples schemas passing, just some minor comments

[MebinAbraham]

@jon-acker @Jon-Kent @martyncolmer @tidmanmike @ONSdigital/eq-runner

Change request to existing implementation:

At the moment, the top level and repeating items have a key_field property which is used to handle the dynamic nature of the models and also support social surveys in future. However, if we standardise the model and say all models must have an identifier property at top level and repeating level, then the key_field property can be dropped. This would make things simpler for eQ Runner and should make look up easier for SDS.

The work required by SDX shouldn't change much either way. Let me know your thoughts. If there is agreement, I will push the changes.

Note we may have to keep key_field at the top-level for data integrity checks if eQ is required to validate the response with the launch claims. This is unknown at the moment.

Before:

{
  "schema_version": "v1",
  "key_field": "ru_ref",
  "ru_ref": "50000035606",
  "items": {
    "local_units": {
      "key_field": "lu_ref",
      "values": [
        {
          "lu_ref": "3340224",
          "lu_name": "STUBBS BUILDING PRODUCTS LTD",
          "lu_address": [
            "WELLINGTON ROAD",
            "LOCHMABEN",
            "SWINDON",
            "BEDS",
            "GLOS",
            "DE41 2WA"
          ]
        },
        {
          "lu_ref": "20047673",
          "lu_name": "HOPSCOTCH INDUSTRIES UK LTD",
          "lu_address": [
            "SOUTH CERNEY WORKS",
            "SHAWELL LANE",
            "BEENHAM",
            "STAFFS",
            "BEDFORDSHIRE",
            "GL4 5YU"
          ]
        }
      ]
    }
  }
}

After:

{
  "schema_version": "v1",
  "identifier": "50000035606",
  "items": {
    "local_units": [
      {
        "identifier": "3340224",
        "lu_name": "STUBBS BUILDING PRODUCTS LTD",
        "lu_address": [
          "WELLINGTON ROAD",
          "LOCHMABEN",
          "SWINDON",
          "BEDS",
          "GLOS",
          "DE41 2WA"
        ]
      },
      {
        "identifier": "20047673",
        "lu_name": "HOPSCOTCH INDUSTRIES UK LTD",
        "lu_address": [
          "SOUTH CERNEY WORKS",
          "SHAWELL LANE",
          "BEENHAM",
          "STAFFS",
          "BEDFORDSHIRE",
          "GL4 5YU"
        ]
      }
    ]
  }
}

[kylelawsonAND]

Understood and approved in current impl - will re-review if key_field removal proposal is implemented.

[katie-gardner]

All makes sense and happy with current proposal, with or without key field, though would also favour just having the identifier

[tidmanmike]

  "identifier": "50000035606",

Happy with this approach as it gives it a global unique identifier across both social and business surveys.

[MebinAbraham]

FYI, I will be making the changes suggested here #1 (comment). Since @jon-acker, @tidmanmike and Runner team are happy with this, I will go ahead with the changes. The change in structure shouldn't really impact Author.

[MebinAbraham]

Model has been updated to use #1 (comment)

[katie-gardner]

Change to identifier made everywhere key field was previously and has been done as outlined in the comment, looks good

[kylelawsonAND]

Change to using identifier looks good and is updated throughout 👍

[Yuyuutsu]

Re-read the changes seems good to me

[martyncolmer]

Happy with this

[martyncolmer]

Happy with this

[jon-acker]

lgtm