JSON Schema Core - 11.2/13.1, 13.2 - inconsistent treatment of multiple schema items

[hrennau]

JSON Schema Core, 11.2, about the media type parameter "schema":
"Multiple schemas are whitespace separated, and indicate that the instance conforms to all of the listed schemas:"
This statement is followed by an example using content type "application/json".

In 13.1 and 13.2, however, dealing with media types "application/schema+json" and "application/schema-instance+json", the role of the media type parameter "schema" is defined slightly differently:
"The instance SHOULD successfully validate against at least one of these meta-schemas." (13.1)
"The instance SHOULD successfully validate against at least one of these schemas." (13.2)

PROPOSAL

• If the different treatment of multiple "schema" values in media type "application/json" versus media types "application/schema+json" and "application/schema-instance-json" is intended, make the (surprising) difference explicit, e.g. adding a note to 11.2
• Otherwise, correct 11.2 (presumably)

[handrews]

11.2 needs to be fixed, thanks.

[Relequestual]

@handrews I would imagine this SHOULD be "at least one of", right?

Consider the expansion into multiple vocabuarlies or even providing multiple draft versions.
A client could look at each in the list, and it may determine that some are not supported, and as such it could try using the ones that it does support / understand how to process.

Are you in agreement?
Other considerations?

[handrews]

@Relequestual yes, "at least one of." The other change is that it needs to talk about application/schema-instance+json rather than application/json as we cannot impose new parameters on the application/json media type (only the media type itself can impose such parameters, and the JSON RFC does not allow for any).

[Relequestual]

Referenced the wrong issue in my PR... oops!

[handrews]

OK, I forgot some stuff and now it's coming back to me.

Ideally, with media type parameters we want to be able to both ask for "I want something that is valid against all of schemas X, Y, and Z" and be able to ask for "I want something that is valid against schema A or B or C".

So the idea was that a space-separated list of schemas in the media type paramter was the AND, and then using multiple Accept header values was the OR, so given:

Accept: application/schema-instance+json; schema="X Y Z",
        application/schema-instance+json; schema="W"

this was to mean "I would like an instance that either satisfies X AND Y AND Z, or it satisfies W (or all four).

That works fine on Accept, but on Content-Type, you can't repeat the header or give it multiple values. Well, syntactically I suppose you can, but I'm pretty sure most implementations would choke on it b/c it's weird.

The idea behind saying the space-separated "X Y Z" meant at least one had to do with content negotiation and versioning. Something about representations likely conforming to multiple versions, but not knowing exactly which? I'm struggling to remember the use case now. It might be in the text but it's not jumping out at me at the moment.

---

So let's think this through in terms of requirements:

• I need to be able to ask for a representation matching any of several schemas, e.g. "I can accept any of schemas v1.0, v1.1, or v2.0"
• I need to be able to ask for a representation matching multiple schemas, e.g. "I need the representation to be both a boat and an airplane"
• I need to know that a representation conforms to multiple schemas, e.g. "This representation is both a boat and an airplane"
• When asked for something conforming to at-least-one-of, I need to know which schema the representation is actually expected to conform to in practice (e.g. v1.1 rather than v1.0 or v2.0)

I need to think a bit more on this. For example, is there a solution allowing you to ask for something that is both a boat (v1, v2, or v3) and an airplane (v1.2, v2, or v2.2)? Is that even desirable? At some point this gets too complex.

[Relequestual]

So the idea was that a space-separated list of schemas in the media type paramter was the AND, and then using multiple Accept header values was the OR...

This meakes sense to me, inc your requirements laid out.
Want me to handle this or happy for me to take another crack at it?

[Relequestual]

In the interest of being able to publish draft 2020 without undue delay, I'm removing these parts from the spec.
I've never heard anyone talk about them till now. If there's a problem, we can re-add them later.
I believe this use was mostly for Hyper Schema, which is not included in draft 2020.

[Relequestual]

Removal commit for reference: 5eda485