Subtype validation via links with describedBy.

[thatjpk]

I'm trying to validate objects that are serialized from different types that share a common super-type. Every object has a collection of common fields, and then depending on the value of a type field, additional type-specific fields. I'm using a schema like this:

{
    "$schema": "http://json-schema.org/draft-04/hyper-schema#",
    "title": "Common Schema",
    "type": "object",
    "properties": {
        "type": {
            "enum": ["foo", "bar"]
        },
        "commonField": {
            "type": "string"
        }
    },
    "required": [
        "type", "commonField"
    ],

    "links": [
        {
            "rel": "describedBy",
            "href": "#/definitions/{type}"
        }
    ],

    "definitions": {
        "foo": {
            "$schema": "http://json-schema.org/draft-04/hyper-schema#",
            "title": "Foo Schema",
            "type": "object",
            "properties": {
                "fooField": {
                    "type": "string"
                }
            },

            "required": [ "fooField" ]
        },

        "bar": {
            "$schema": "http://json-schema.org/draft-04/hyper-schema#",
            "title": "Bar Schema",
            "type": "object",
            "properties": {
                "barField": {
                    "type": "string"
                }
            },

            "required": [ "barField" ]
        }
    }
}

And trying to validate an object like:

{
    "type": "foo",
    "commonField": "asdf",
    "fooField": 123
}

This message passes validation even though fooField is a number instead of a string. It seems that the common fields are validated just fine, but none of the type-specific schemas take effect. I see this behavior both in my application (using json-schema-validator v2.2.5), and in the online demo at http://json-schema-validator.herokuapp.com/.

Is my schema valid, and does it correctly reflect my intent? If so, is the validator's behavior here expected? Thanks for your help!

[fge]

The behaviour is expected; note that describedBy is a hyper schema keyword, it does not affect instance validation in any way!

In order to do what you require here, you can use a combination of allOf and anyOf. For instance:

{
    "allOf": [
        { "$ref": "baseschemaURIhere" },
        {
            "anyOf": [
                { "$ref": "subschema1" },
                { "$ref": "subschema2" }
            ]
        }
    ]
}

[thatjpk]

Ah, gotcha. I guess I greatly misunderstand the purpose of links/describedBy. (Like, if it doesn't affect instance validation... what does it do?)

Anyway, using anyOf or oneOf seems to work. The only downside is the error report has a bunch of useless stuff in it if validation fails. For instance, if there are five sub-schemas you only care about validation errors on the sub-schema that matched the type field, if any, but the report will contain all the errors for all five sub-schemas. I realize this is to be expected, it's just kind of a drag that I have to write stuff to filter the superfluous errors out of the validation report. My hope with describedBy was that I could trigger validation against only the sub-schema that mattered for the given type. Is there no way to do that?

[fge]

Uh yeah, that's part of the problem; when I wrote this API, I didn't know what people expected to do with error reports! Right now I only display them.

I'm not sure how to "fix" the API there; since I don't know what people will use!

[thatjpk]

Yeah, that's understandable. I think the API here is fine. I can see use cases where you would want validation errors for all the schemas referenced in a oneOf, it's just in my case I only care about one of them. The API does the right thing by exposing ProcessingReport for client code to comb through to get what it needs. If there was a helper class or something to make this easier it would be nice since the code for traversing the report's JsonNodes is fairly verbose.

Ultimately, I think my use case doesn't map perfectly to json schema features. So unless there's a better way than anyOf/oneOf to implement an inheritance-like chain of schemas based on the value of a field, I just have to deal with the impedance mismatch in my error reporting code. I guess I'd probably run into the same issue with other validators as well.

Anyway, you can close this issue if you'd like. Thanks!