New keyword: postfixItems

[Relequestual]

I suggested this could be possible and we would consider it if a real-world use case appears: #864 (comment)

Real-world use case: https://stackoverflow.com/questions/65660787/how-to-set-one-schema-for-n-1-elements-and-another-for-the-nth-element

[gregsdennis]

I see your comment, but I still think that this seems edge-case-y.

This also doesn't cover the edge case when someone asks how to make the last two items match a schema. Or three, or...

It occurs to me that we may need some sort of "match A for a items, then B for b items, then C for c items... then some more items.... and the last x have to match X" functionality. Not sure how to pull that off, though, without a complex definition and horrible syntax.

[notEthan]

how to make the last two items match a schema

I assume postfixItems would be an array like prefixItems, to match the last n items in the instance array.

I'm not sure one stack overflow post is compelling enough to add this to the spec, but it has a pleasant symmetry to prefixItems.

[karenetheridge]

I agree with Jason's reply in the SO question that altering the data model would be more appropriate -- i.e. shift the data so that the outlier item(s) are at the beginning of the array rather than at the end, and then prefixItems and items are sufficient to specify the structure.

[awwright]

(Or suffixItems?)

[gregsdennis]

Got a StackOverflow question where the OP is asking about this (see the comments on my answer), so there's definitely a need.

[notEthan]

one more https://stackoverflow.com/questions/69543229/describe-last-item-of-array-in-json-schema

[colincadams]

we have a schema that supports conditionals of the form:

[
  {
    "if": "...",
    "then": "..."
  },
  {
    "else_if": "...",
    "then": "..."
  },
  ...
  {
    "else": "..."
  },
]

Moving else to the start is a bit non-sensical, so supporting postfixItems / suffixItems would be great!

[Relequestual]

@colincadams Could you explain how you see this relates? I'm afraid I'm missing something 😅.

We have prefixItems in the latest version of JSON Schema.
This replaced the tuple form of items.
It's unrelated to the conditional applicators if/then/else.

[colincadams]

oh sorry @Relequestual I see how this is confusing. The if/else_if/else I was referring to are not the json-schema constructs, but valid fields in our schema that we have defined in json-schema. So the example I posted above is JSON that we are validating against our schema.

So our actual json schema looks a bit like this:

"type": "array",
"prefixItems": [
  {
    "$ref": "#/definitions/$if"
  }
],
"items": {
  "oneOf": [
    {
      "$ref": "#/definitions/$else_if"
    },
    {
      "$ref": "#/definitions/$else"
    }
  ]
}

which isn't as strict as it could be. with postfixItems it could be:

"type": "array",
"prefixItems": [
  {
    "$ref": "#/definitions/if"
  }
],
"items": {
  "$ref": "#/definitions/else_if"
},
"postfixItems": [
  {
    "$ref": "#/definitions/else"
  }
]

[M-Reimer]

Another one in need of this feature here.

We have a data structure which can describe different signal forms. We use the same structure for all signal forms as this significantly simplifies how the data can be handled internally.
One signal form is a linear signal where each object in the array defines the values at this point and the time "distance" to the following item.
For the linear type of signal this means that the last "distance" field is no longer relevant (there is always one more "distance" than data tuples).
I now would like to describe that the "distance" field for the very last item in this list is optional so it can be left out altogether.

[gregsdennis]

Closing this in favor of the more general ☝️ that also solves this particular problem.