We've had a bug for a while where strict validation didn't work for
draft1 and draft2 schemas. Strict validation should raise errors if
there are properties in the data that are not defined in the
schema. However, this was only happening with draft3 and draft4
schemas.
This error slipped through because the tests for strict validation
were silently switching to either draft4 or the default schema
version, and draft3 and draft4 did implement strict validation
correctly. So in practice we were never really testing draft1 and
draft2 with strict validation.
I've fixed this by refactoring the code that draft3 and draft4 used
for handling unrecognized properties (under strict validation) such
that it could also be used by draft1 and draft2, and fixed up the
strict validation tests so that they use the correct json-schema
draft.
We've had a bug for a while where strict validation didn't work for draft1 and draft2 schemas. Strict validation should raise errors if there are properties in the data that are not defined in the schema. However, this was only happening with draft3 and draft4 schemas.
This error slipped through because the tests for strict validation were silently switching to either draft4 or the default schema version, and draft3 and draft4 did implement strict validation correctly. So in practice we were never really testing draft1 and draft2 with strict validation.
I've fixed this by refactoring the code that draft3 and draft4 used for handling unrecognized properties (under strict validation) such that it could also be used by draft1 and draft2, and fixed up the strict validation tests so that they use the correct json-schema draft.