Polymorphic types about json-schema-validator

[fge]

I see no reason why this cannot be doable, the trick however would be to generate the schemas correctly.

At the schema level, what you can already do is this:

{
    "properties": {
        "type": { "enum": [ "dog" ] },
        "etc": "etc"
    }
}

This would ensure that only dogs are permitted.

I have a prototype for a processing chain ready, so I'll let @reinert know when I am ready and see how we can help you solving this.

Would you mind providing some sample JSON data?

[fge]

-ETIMEOUT...

[fge]

Well, it is not my implementation which supports such a feature, but JSON Schema itself, with the "extends" keyword in draft v3 and the "allOf" keyword in draft v4. For instance:

{
    "title": "animal",
    "id": "some://where/animal#",
    "etc": "etc"
}

and

{
    "title": "dog",
    "id": "some://where/dog#",
    "allOf": [ { "$ref": "animal#" }, { "specific": [ "dog", "elements", "here" ] } ]
}

If this is what you are asking, the library currently does not have an API to build schemas out of other schemas (save for using JsonNodeFactory to manipulate the JSON Schema directly).

Here again, JJSchema looks like it does what you want. I am curious: what is your target use of JSON Schema? It seems to me like you come from the "Java XML world", where options are aplenty and where you can do everything save for coffee...

Can you take some time to explain what you are trying to achieve?

[dportabella]

currently we are using xml for communicating between partners,
and we use an XSD to validate a xml, and we use JAXB to serialize/deserialize a xml, and JAXB to generate Java classes from the XSD.
We would like to communicate between partners also with json,
so need to do the same as before with json, instead of xml.

if i understood correctly, allOf just indicates that the type must conforms to all the schemas.
that's not what i meant,
I meant that we have a json file with a list of animals, and some of them are dogs and some of them are cats.
dog inherits from animal, and defines some more attributes.

the dog instance in the json file needs to indicate somehow that it is a dog (as it is done in xml with xsi:type).
in the previous jackson example, this is done by adding a new field called "type", with possible values "dog" or "cat".
http://programmerbruce.blogspot.de/2011/05/deserialize-json-with-jackson-into.html
{
"animals":
[
{"type":"dog","name":"Spike"},
{"type":"cat","name":"Fluffy"}
]
}

[dportabella]

{
  "type" : "object",
  "additionalProperties": false,
  "properties" : {
    "animals" : {
      "type" : "array",
      "items" : { "type" : "#/animal" }
    }
  },
  
  "animal" : {
    "type" : "object",
    "additionalProperties": false,
    "properties" : {
      "name" : { "type" : "string", "required": true }
    }
  },
  
  "dog" : {
    "type" : "object",
    "additionalProperties": false,
    "extends" : "#/animal"
    "properties" : {
      "breed" : { "type" : "string", "required": true },
      "leashColor" : { "type" : "string", "required": true }
    }
  },
 
  "cat" : {
    "type" : "object",
    "extends" : "#/animal"
    "additionalProperties": false,
    "properties" : {
      "favoriteToy" : { "type" : "string", "required": true }
    }
  }
}
I would expect that this passes:
{  
  "animals":  
  [  
    {"type":"dog","name":"Spike",  "breed":"mutt",  "leash_color":"red"},  
    {"type":"cat","name":"Fluffy", "favorite_toy":"spider ring"}  
  ]  
}  
and that if you remove the "favorite_toy" from the cat, then it should not pass.
but somehow, the json schema needs to know that the property "type" asserts the type of the instance (dog or cat),
and validate the instance with its schema.

[fge]

No, the type keyword in JSON Schema does not work like this. It only checks the primitive types of the instances (in v3, it also played the role of v4's anyOf).

You need to make use of subschemas instead. Another thing is that schemas are not additive, they are all evaluated in their own context. Which means, writing, for instance (draft v4):

{
    "type": "object",
    "allOf": [
        { "properties": { "p": {} }, "additionalProperties": false },
        { "properties": { "q": {} } }
    ]
}

will fail to validate:

{ "p": "foo", "q": "bar" }

All schemas are evaluated in their own context. Therefore, the first schema checking p sees q and yells.

This is quite different from XML Schema!

[fge]

Back to your problem a little. What you want is really definitions. It is defined as a placeholder for subschemas. You can write:

{
    "definitions": {
        "type1": { "schema": "here" },
        "type2": { "schema": "here" }
    }
}

And then, from your schema, you refer to them using $ref:

{
    "$ref": "#/definitions/type1"
}

An example of such a subdivision can be found in a schema I wrote for GeoJSON:

https://github.com/fge/json-schema-validator-demo/blob/master/src/main/resources/geojson/geometry.json

As to the general status of my project: I have the processing chain mechanics sorted and tested; after I am done porting all validation keywords etc to it, I'll attack the next steps, and that includes making a processor to generate a JSON Schema from a POJO (using JJSchema) and the reverse (using jsonschema2pojo).

Which means I'll have a pretty complete chain... But there will be package split: the validation engine parts will still be independent.

[fge]

OK, so it appears the package to use here is jsonschema2pojo. Note that Jackson proper can do it (your link to programmerbruce above tells how and I have even implemented it myself), but the question appears to be: do you want to generate schemas for validation, deserialize directly, serialize, all of them, generate schemas from classes, all of them?

Also, and that is important: where do you expect this type information to be carried? In instances or in schemas? With XSD this is in schemas. Deserializing from instances can be done with Jackson. With some work, JJSchema can be adapted to generate schemas according to some "pivot value" in instances which would guide the process of generating schemas.

In short: what are your inputs, what are your outputs?