Question about JSON schema validation about json-schema-validator

[fge]

I suppose you mean 1.6.1?

Both solutions will work, however using a SyntaxValidator will analyze the file more (syntax checkers have more capabilities than schema keywords -- they will detect an invalid regex in patternProperties for instance).

But the interface is different, as you may have seen. 2.0.x will change that!

[asargento]

Yes, version 1.6.1 (1.6.2-SNAPSHOT).
The problem is that, the schema validation like I show in the issue, validates the test schema correctly when it has an error.
And if I use a SyntaxValidator like the following

List<Message> messages = new ArrayList<Message>();
SyntaxValidator syntaxValidator = new SyntaxValidator(MetaSchema.copyOf(BuiltinSchemas.DRAFTV3_CORE));
syntaxValidator.validate(messages, instanceNode);

it works fine and reports the error

domain: syntax; keyword: type; message: unknown simple type; found: "strung"; possible-values: ["array","boolean","integer","null","number","object","string"]

But if use the SyntaxValidator like the following

List<Message> messages = new ArrayList<Message>();
SyntaxValidator syntaxValidator = new SyntaxValidator(MetaSchema.builder().withURI(schemaUri).withRawSchema(schemaNode).build());
syntaxValidator.validate(messages, instanceNode);

no error is reported. This is correct?

[asargento]

Oops, by mistake I close the issue...

[fge]

In your second example you create an empty MetaSchema: you associate a URI and a raw schema to it, but no syntax checkers at all. As a result, it will validate successfully each and every object (not others since the check for non objects is done earlier).

If you need to add syntax checkers, you need to grab a metaschema and extend it:

MetaSchema.basedOn(BuiltinSchemas.DRAFTV3_CORE).addKeyword(...).withURI().withRawSchema().build();

(or just build a whole new metaschema with your own keywords etc -- why not, if the use case is very specialized! But unlikely)

[asargento]

Ok, I understand now how MetaSchema works.
But, why my test schema evaluated correctly by the following code?

JsonSchemaFactory.Builder builder = new JsonSchemaFactory.Builder();
for (BuiltinSchemas schema: BuiltinSchemas.values())
    builder.addSchema(schema.getURI(), schema.getRawSchema());

JsonNode schemaNode = JsonLoader.fromFile(<schema-above>));
ValidationReport report;

String schemaUri = schemaNode.get("$schema").textValue();
JsonSchema schema = factory.fromURI(schemaUri);
report = schema.validate(schemaNode);

[fge]

Indeed, it does not look correct. I'll try your code and see what happens. Stay tuned.

[fge]

Uh, OK, found: it is a bug in the core meta-schema!

Here is the subschema for the type keyword:

{
        "type": ["string", "array"],
        "items": {
            "type": ["string", {
                "$ref": "#"
            }]
        },
        "uniqueItems": true,
        "default": "any"
    }

For the value "strung", only the validator for type will validate here -- and succeed, since the input is a string. But it does not check whether the value of the string is one of the seven primitive types! Ouch.

OK, so the question now is how to fix it. One solution would be to add a fix to the metaschema in the package itself. For instance, like this:

https://gist.github.com/fge/4986344

This way, the report is indeed an error, as expected:

"/properties/field2/type": domain: validation; keyword: enum; message: value not found in enum; enum: ["array","boolean","integer","null","number","object","string"]; value: "strung"
"/properties/field2/type": domain: validation; keyword: type; message: instance does not match any allowed primitive type; allowed: ["array"]; found: "string"

Of course, there is an additional error message since the type keyword now only has one primitive type.

Would this fix to the metaschema be enough for you?

[fge]

Note that the syntax validator does check primitive type correctness, which is why it did detect the error where "plain validation" did not.

[asargento]

Ok, it is fine for me. Nevertheless, that schema became different from original draft v3.
This fix it will be include where? (I will introduce in my source copy).

[fge]

I have one gripe with that change but I think I can live with it. Draft v3 says (section 5.1):

Other type values MAY be used for custom purposes, but minimal validators of the specification implementation [sic] can allow any instance value on unknown type values.

But I already happily break that by declaring that unknown primitive types make for an illegal schema. OK, I guess it can be lived with, and anyway, there's $ref.

This fix it will be include where? (I will introduce in my source copy).

The file which will be changed is src/main/resources/draftv3/schema. I'll commit that on the v1.6 branch shortly. Stay tuned.

[asargento]

Fine, thanks for the help.

[fge]

OK, 1.6.2 has just been released, it should be available for download shortly.