Walk in ItemsValidator202012 uses different path than ItemValidator about json-schema-validator HOT 4 CLOSED

So in general passing null as instance data is not valid since the walk actually walks the instance data, it doesn't walk the schema. So null means that there's nothing to walk. The walk listeners can end up with null as the instance node, typically when processing items or properties, this is more so that they can potentially set the node value. If the null instance ends up being passed to the validation functions this is going to throw as they generally don't handle that scenario.

If you are referring to

from json-schema-validator.

My use case is to walk the schema for different purposes than validation - I know this is not the main use case for your library :)

I have created a minimal use case I was trying to explain above: https://gist.github.com/bartoszm/5bdcebe01c59742ad40165c1a78a8966

What the use case demonstrates is how the walk works when data instance is provided and when data is not provided.
As you can see there is a glitch in the Matrix when you use V202012.

The result for VersionFlag.V201909:
-- with data --
$.name
$.children[0].name
$.children[0]
$.children
-- with no data --
$.name
$.children[0].name
$.children[0]
$.children

The result for VersionFlag.V202012:
-- with data --
$.name
$.children[0].name
$.children[0]
$.children
-- with no data --
$.name
$.children.name
$.children
$.children

from json-schema-validator.

As I highlighted, the walk is walking the instance data, it doesn't walk the schema, so passing null and expecting it to walk the schema just wouldn't work. For instance a ref could make a schema cyclic, and also cases where a tuple schema is used eg. with prefixItems. It only appears to work due to your specific schema and data by coincidence. There's also discrepancies in behavior when passing null and with validation turned on to walk for instance.

If there's anything to fix it would be to make the V202012 processing to be the same as the processing with V201909. Would this solve your issue, because it sounds like what you want is the opposite.

from json-schema-validator.

@justin-tay having the V202012 processing to be the same as the processing with V201909 would solve my issue.

from json-schema-validator.