Problem Definition

Use case: From B2Share. Communities can have record submitted to them. Records are validated with the Community's JSON Schema. This JSON Schema can change, every modification create a new version.

Problem: We want to make sure that searching records by field names is consistent and that all blocks of metadata having the same schema can be analyzed the same way (fields type is the same).

Solution: We can develop a function which makes sure that the new JSON schema version is backward compatible with the previous schemas.

Who needs it: B2Share

Design notes:

For B2Share a schema is backward compatible if:

• The fields' type remain the same in all JSON schemas declaring it.
• JSON Schemas are type consistent within themselves too, i.e. A JSON Schema cannot validate two fields with different types which would be referenced with the same JSON pointer.

The definition of "backward compatible" can vary for other users. Thus we should have either different functions checking the possible constraints (ex: fields cannot be removed, fields have to be type consistent, etc...) or one function with parameters to enable specific checks.

JSON Schema allows to specify a different type/structure for different indexes of an array. However there should be an option to ignore array indices as some tools like Elasticsearch can specify only one mapping for all array values (see Example 3).

Function Prototype:

• Arguments:
  • a list of JSON Schemas ordered from first version to last.
  • an optional argument to ignore array indexes (see Example 3).
• Exceptions: The function raises an exception when a contraint is violated. It should always say which JSON Schemas in the list conflict and on which field(s).
• Returns: (optional) an incremental state which can be used to validate faster the next JSON Schema versions. This state would be given as an optional argument.

Examples:

Example 1: Type consistency example:
The following schema is not type consistent because it would accept "field_A" to be either a "string" or an "integer".

{
   "type": "object",
   "oneOf": [{
       "type": "object", 
       "properties": {
           "field_A": { "type": "string" }
       }
   }, {
       "type": "object", 
       "properties": {
           "field_A": { "type": "integer" }
       }
   }]
}

Example 2: Backward type compatibility example:*
In the following example, Version 3 is not backward type compatible because it redefines field_A which was defined in Version 1 with a different type.
However Version 1 and Version 2 are type compatible because it is allowed to add/remove fields and change the required fields.

Version 1

{
    "type": "object",
    "properties": {
        "field_A": { "type": "string" }
    },
    "required": ["field_A"]
}

Version 2

{
    "type": "object",
    "properties": {
        "field_B": { "type": "string" }
    },
    "required": ["field_B"]
}

Version 3

{
    "type": "object",
    "properties": {
        "field_B": { "type": "string" },
        "field_A": { "type": "number" }
    },
    "required": ["field_B"]
}

Example 3: Ignore array index:
Fields can conflict only if they can be referenced with the same JSON pointer in the validated JSON.
JSON Schema allows to specify a different type/structure for different indexes of an array. However there should be an option to ignore array indexes because some tools like Elasticsearch can specify only one mapping for all array values.

In the following JSON Schema the two field_A should have different JSON pointers, respectively experiment_info["0"].field_A and experiment_info["1"].field_A. If we enable the ignoring of array indices however, they should both be considered as experiment_info[*].field_A and conflict.

{
    "type": "object",
    "properties": {
        "experiment_info": {
            "type": "array",
            "items": [
                {
                    "type": "object",
                    "properties": {
                        "field_A": { "type": "string" }
                    }
                },
                {
                    "type": "object",
                    "properties": {
                        "field_A": { "type": "number" }
                    }
                }
            ]
        }
    }
}

In the following JSON Schema however, the two fields will always conflict as the JSON Schema does not specify the indices.

{
    "anyOf": [
        {
            "type": "object",
            "properties": {
                "experiment_info": {
                    "type": "array",
                    "items": {
                        "type": "object",
                        "properties": {
                            "field_A": { "type": "string" }
                        }
                    }
                }
            }
        },
        {
            "type": "object",
            "properties": {
                "experiment_info": {
                    "type": "array",
                    "items": {
                        "type": "object",
                        "properties": {
                            "field_A": { "type": "integer" }
                        }
                    }
                }
            }
        }
    ]
}