Fix additionalItems behavior when items is not in tuple form.

[gazpachoking]

Made a quick test runner for the new json validation tests and already found an issue.

The spec states that additionalItems should not do anything when items is not in tuple form. Fixed this behavior and added an old style test for now. This also showcased an issue with the error message checking (and error message generation) for additionalItems which I also fixed.

[Julian]

Nice, glad that's paying off already :). Haven't looked at this yet but any idea what the merge conflict is?

[gazpachoking]

Looks like I didn't branch from your latest master, I merged it.

EDIT: Hmm, diff looks curious, maybe I didn't do that right.

[Julian]

Ah, OK. Also this sounds a bit odd – is the behavior for additionalProperties also supposed to be this way, because if so I'm pretty sure it isn't. Or does the schema have some bizarre asymmetry here?

[gazpachoking]

Well, since properties doesn't have 2 forms, there is no equivalent there.

[Julian]

Not sure I understood that, sorry. Why is [1, 2] valid under {"additionalItems" : False} but {"foo" : "bar"} is invalid under {"additionalProperties" : False}?

[gazpachoking]

[1, 2] is valid under {"additionalItems": False} because the default for items is {}, so the actual schema is {"items": {}, "additionalItems": False}, and additionalItems only applies when items is in tuple (array) form.

[Julian]

Heh. So ugly asymmetry it is then. Alrighty, if that's what the schema says I guess.

[gazpachoking]

I don't really see it as asymmetry, it's just that additionalItems doesn't come into play when items is validating all of the items. There can't possibly be additional items when items is a schema.

[Julian]

This looks good, merged. Thanks.

[Julian]

Two seemingly analogous schemas/instances (the ones I asked about) have different validations due to a hidden default for another property. I'd say that's really ugly. But hey, no room to complain at this point I guess.

[gazpachoking]

I guess the way I look at it is that additionalItems must look at items to see if all values are already validated, and additionalProperties must look at properties and patternProperties to see if all values are validated. The difference between what exactly must be looked at is inherent to the difference between arrays and objects.

EDIT: Maybe I'm just trying to justify it because I can't think of a better way. :P

[gazpachoking]

Actually, maybe I understand what you are saying, and maybe I can think of a better way. If default for items was [], then items would be validated by default by additionalItems. Similar to how when properties and patternProperties are not defined, then property values are validated by additionalProperties.

EDIT: Actually, now that I think about it some more, it seems like the schema form for items is totally superfluous. {"items": {a schema}} is completely analogous to {"items": [], "additionalItems": {a schema}}

[gazpachoking]

I opened a ticket over at json-schema to discuss this. json-schema/json-schema#29