"unevaluatedItems" should consider "contains"

[handrews]

The interaction of these seems underspecified. @Relequestual what was the problem you ran into here exactly? I've already forgotten 😬

[Relequestual]

This was me being unable to read that unevaluatedItems only applies when items is defined as an array.

With that light, there’s no valid argument that I can think of that would warrant interaction between these keywords.

--

Edit: The intent of unevaluatedItems was to be effected by all array based applicators, which includes contains. The spec as written currenltly, doesn't allow this.
#810 (comment)

[handrews]

Actually, I'm pretty sure I left out something important. Consider the following schema:

{
  "type": "array",
  "oneOf": [
    {
      "contains": {"type": "string"},
    },
    {
      "items": {"type": "integer"}
    }
  ],
  "unevaluatedItems": {"type": "boolean"}
}

The following instances should all be valid:

[true, "hello", false]
[1, 3, 4]
[true, false]

I had intended for all array child applicators to affect unevaluatedItems, and all object child value applicators to affect unevaluatedProperties. (propertyNames is an object child name applicator).

I seem to have left out the necessary specification of a contains annotation and how unevaluatedItems could use it.

Not sure if there's a use case, but logical consistency was the goal.
@Relequestual does this make sense?

[Relequestual]

Logical.
Would contains collect all items that were valid for it? As such, would unevaluatedItems only apply to those which were not valid according to contains?

Sorry, on mobile.

[handrews]

@Relequestual

Would contains collect all items that were valid for it?

Yes, there is language in the existing description that requires contains to be checked against all array items when collecting annotations. If you're using unevaluatedItems you have to collect annotations. I'll make sure that's clear, though, good question.

would unevaluatedItems only apply to those which were not valid according to contains?

That is correct. contains gets applied to all but "evaluated" really means "successfully evaluated" because annotations are dropped from failed evaluations.

[handrews]

Hm... lots of test cases there.

[Relequestual]

Well, my understanding / expectation is correct then.
I'd have to re-read the spec to understand where you're saying there's a deficit though.

[handrews]

@Relequestual if you find anywhere that makes that behavior explicit, let me know.

I don't think there's anything there that contradicts it, and it obviously won't require a meta-schema update. I made that "draft-08-patch1" milestone to collect compatible fixes based on early feedback. Or if we end up thinking that this is a kind of glaring error we can put this and whatever else we've noticed in and re-publish the core spec sooner rather than later.

[Relequestual]

I think the phrase "annotations are dropped from failed evaluations" is key here.

Does contains return an array of annotations with nulls where the annotations have been dropped (becaused of failed validation), or an object where the keys are the indexes at which the array successfully validated? Latter sounds better. I don't think it's currently defined.

It only really matters what format the annotations take for the output format data.

I guess contains is an applicator keyword like anyOf. At least the intent is clearer and should help people avoid using oneOf here... =D

The prose / explanation about how annotation results are used will need to be updated here:

json-schema-spec/jsonschema-core.xml

Lines 2209 to 2217 in 38e1606

	The behavior of this keyword depends on the annotation results of
	adjacent keywords that apply to the instance location being validated.
	Specifically, the annotations from "items" and "additionalItems",
	which can come from those keywords when they are adjacent to the
	"unevaluatedItems" keyword. Those two annotations, as well as
	"unevaluatedItems", can also result from any and all adjacent
	<xref target="in-place">in-place applicator</xref> keywords.
	This includes but is not limited to the in-place applicators
	defined in this document.

[Relequestual]

Given the proceeding paragraphs, making this fix would legalistically be a non backwards compatible change, but I think it's clearly a mistake.

json-schema-spec/jsonschema-core.xml

Lines 2219 to 2232 in 38e1606

	<t>
	If an "items" annotation is present, and its annotation result
	is a number, and no "additionalItems" or "unevaluatedItems"
	annotation is present, then validation succeeds if every instance
	element at an index greater than the "items" annotation validates
	against "unevaluatedItems".
	</t>
	<t>
	Otherwise, if any "items", "additionalItems", or "unevaluatedItems"
	annotations are present with a value of boolean true, then
	"unevaluatedItems" MUST be ignored. However, if none of these
	annotations are present, "unevaluatedItems" MUST be applied to
	all locations in the array.
	</t>

[handrews]

@Relequestual yeah, this falls under "bugfix"