schemaReferenced in ValidationListener not returning the proper location

[afranzi]

It seems that from version 1.10.0 to the hash commit 5722c0f4a1306705a56a4d9c11c82bb5709cc57a some behaviour about how the SchemaReferenced works changed.

In the 1.10.0 the SchemaReferenced was returning the location of the schema referenced:

override def schemaReferenced(event: SchemaReferencedEvent): Unit = {
    event.getReferredSchema.getSchemaLocation == "#/allOf/0/properties/product"
}

Now, it's returning the schema Id

    event.getReferredSchema.getSchemaLocation == "/schemas/objects/Product/1.json"

I've been trying to figure out where was the change, but I didn't manage to found it.

The event, I'm validating is

{
  "user": {
    "id": "5a34008f8cece4000764cd5a"
  },
  "device": {
    "id": "5a34008f8cece4000764cd5a",
    "platform": "Android"
  },
  "product": {
    "id": "remixprototype",
    "version": "0.0.1"
  },
  "deploymentEnv": "prod",
  "createdAt":"2018-07-19T13:37:28+02:00",
  "schema": "/schemas/events/device-sensor-event/1.json",
  "source": "sensor",
  "data": {
    "type": "light",
    "level": 0.8
  }
}

And the schema is

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "$id": "/schemas/events/base-event/1.json",
  "additionalProperties": true,
  "description": "Base schema for all user-generated events (on device)",
  "properties": {
    "user": {
      "description": "User information",
      "$ref": "/schemas/objects/User/1.json"
    },
    "product": {
      "description": "Product information",
      "$ref": "/schemas/objects/Product/1.json"
    },
    "deploymentEnv": {
      "description": "Deployment environment in use",
      "enum": [
        "dev",
        "test",
        "stage",
        "prod"
      ]
    },
    "createdAt": {
      "description": "Timestamp when the event was generate (following rfc 3339 format)",
      "type": "string",
      "format": "date-time"
    },
    "schema": {
      "description": "Name of the schema to validate against",
      "type": "string"
    },
    "source": {
        "description": "Source of the data point",
        "type": "string",
        "enum": ["sensor", "questionnaire"]
    }
  },
  "required": [
    "source",
    "schema",
    "user",
    "product",
    "deploymentEnv",
    "createdAt"
  ],
  "type": "object"
}

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "$id": "/schemas/events/device-sensor-event/1.json",
  "additionalProperties": true,
  "allOf": [
    {
      "$ref": "/schemas/events/base-event/1.json"
    }
  ],
  "description": "User event including sensor data",
  "properties": {
    "data": {
      "oneOf": [
        {"$ref": "/schemas/objects/sensors/SensorAccelerometer/1.json"},
        {"$ref": "/schemas/objects/sensors/SensorActivity/1.json"},
...
        {"$ref": "/schemas/objects/sensors/SensorWalk/1.json"},
        {"$ref": "/schemas/objects/sensors/SensorWifi/1.json"}
      ]
    }
  },
  "required": [
    "data",
    "device",
    "product",
    "user"
  ]
}

[afranzi]

This behavior change seems related with the issue #233, regarding how the ReferenceLookup is being calculated.

https://github.com/everit-org/json-schema/blob/master/core/src/main/java/org/everit/json/schema/loader/ReferenceLookup.java#L164

                .pointerToCurrentObj(SchemaLocation.parseURI(absPointerString))```

    SchemaLoader childLoader = ls.initChildLoader()
            .pointerToCurrentObj(SchemaLocation.parseURI(absPointerString))
            .resolutionScope(!isInternal ? withoutFragment(absPointerString) : ls.id)
            .schemaJson(result.getQueryResult())
            .rootSchemaJson(result.getContainingDocument()).build();

[erosb]

Hello @afranzi can you please check if event.schema.getSchemaLocation fits your needs? In case of SchemaReferencedEvent instances it will be the location of the reference (ReferenceSchema) itself.

Your PR unfortunately can't be merged because it breaks the existing API. 1.10.0 has already been released and you might not be the only one implementing listeners, so we shouldn't change the signature of visit* methods.

[afranzi]

Hi @erosb,

I wanted to share how are we using the JSON-Schemas to Validate, Evolve and anonymize the data.
The Datum VEA - Validate, Evolve and Anonymize your data with Data Schemas

[erosb]

Awesome. Thanks for sharing!