Move "applicability" keywords to core

[handrews]

The keywords in Section 3.1 "Applicability" of the Validation spec are not specific to Validation. Let's either move them to core or make them into their own vocabulary specificaton.

Any non-trivial vocabulary will need these applicability keywords, or a set of keywords with roughly equivalent functionality. Standardizing on this set will encourage interoperable vocabularies. If we want a truly minimal core specification, then factoring out applicability into its own document will still clarify what is recommended as the base for most vocabularies (core + applicability) while still allowing for a different approach to applicability based on a minimal core for vocabularies that really want to re-imagine this functionality.

Notably, with the applicability keywords factored out, the Hyper-Schema spec will no longer directly depend on the Validation spec. It will only need core (or core + applicability), and the general notion of assertions and annotations already described in core. This eliminates a "design smell" in the current system where hyper-schema requires implementing a specific set of assertions that are unrelated to the task of annotating a JSON document with hyperlinks.

---

In terms of the content, the first sentence of §3.1:

Validation begins by applying the root schema to the complete instance document.

can be changed to:

Schema evaluation begins by applying the root schema to the complete instance document.

The remainder of the section talks about "assertions" in general, rather than the validation vocabulary in particular.

The third paragraph currently has to awkwardly list the child applicability keywords out as they are mixed in with the array and object assertions. In the core spec or their own spec they would be grouped as a section and we could drop the list and just refer to the section. Another indication that this is a good idea: it simplifies the text.

Section 3.1.1 Keyword Independence would also be simplified, as it universally applies to all current assertions, but is not universal across applicability keywords. Right now we treat the additional* applicability keywords as exceptions to an assertion-oriented concept, which muddles things a bit.

---

Putting these keywords in core would make the minimum extensible JSON Schema implementation requirements involve:

• identifying, organizing, and linking schemas ($ref, $id, $schema, and if Move "definitions" to core (as "$defs"?) #512 is accepted definitions)
• providing an interface to evaluate assertions
• providing an interface to collect annotations
• applying subschemas to instances and combining assertion results and annotation data accordingly

Putting them in their own spec would leave the first three bullets as the minimal implementation, with the fourth being a strongly recommended baseline extension required for all json-schema.org assertion and annotation vocabularies (of which we currently have two).

[handrews]

We could re-name these keywords with the $ prefix, but that would be very disruptive. I think it's easy enough to consider these keywords their own classification to explain why they do not use the prefix. But I'm open to changing them if we think we can sell that to the community.

[handrews]

@Anthropic would doing this allow UI schema, as you currently have it designed, to be specified independent of Validation? As with Hyper-Schema, obviously they could still be used together, but I'm interested if UI schema can be defined based on core (with the general concept of assertion and annotation keywords) and applicability.

[erayd]

I don't think that the applicability keywords belong in core. If they are going to be split away from validation, then I think they should live in their own document.

[handrews]

@erayd a third approach could be to put them in the core document but as a separate vocabulary from the $ keywords that are necessary for the media type to function. This would be effectively the same as putting them in their own document in terms of implementation requirements, but also indicate that this particular vocabulary is strongly recommended and required by all other proposed standard vocabularies so far.

I'm not set on any of these three options (part of core, a separate vocabulary in the core document, or a separate vocabulary in its own document). Just mulling the options.

[erayd]

@handrews That works too :-)

[handrews]

@epoberezkin what in particular is motivating your confused/sad reaction? This shouldn't actually have any impact on Ajv, it's just helping other uses of JSON Schema be more modular and clarifying the document boundaries (as we did with Validation and Hyper-Schema in draft-07)

[handrews]

My primary motivation for this proposal is to allow for vocabularies that do not want to use validation (in the form of assertions that can fail) in any way, but still want to apply keywords via subschemas.

For instance, you could write a hyper-schema without any validation assertions. It would apply links wherever the instance has an appropriate location. But it would never fail validation. At most it would simply not be able to apply links if no locations match.

Perhaps more realistic would be data definition vocabularies, such as defining a UI without validation (@Anthropic ?).

Leaving these keywords in the validation spec means that you have to reference the validation spec even when your application will never fail validation for anything. That seems a bit odd.

Putting them either in the core spec (whether required or optional- I do agree that requiring this exact set of keywords may be too restrictive) or as a separate spec would allow building both non-validating vocabularies and would allow using a completely different set of custom assertions. So that would be a validation approach that is independent of our standard approach.

These all seem like good things, given that they can be accomplished without impact to any known implementation (at least, I'm not aware of anything that implements core and not validation- the closest I can think of is implementations of JSON Reference that also support ids for changing the base URI, which might be a good argument to make the keyword set optional to support as @erayd suggests).

[epoberezkin]

@handrews what keywords exactly we are talking about here?

[handrews]

The ones listed under applicability keywords. For everyone's convenience since the list is kinda buried and some keywords are given by section rather than explicitly, here is the complete list as of draft-07:

• Boolean logic: allOf, anyOf, oneOf, not
• Conditional: if, then, else
• Object structure: properties, patternProperties, additionalProperties, propertyNames
• Array structure: items, additionalItems, contains

[epoberezkin]

@handrews Can you show an example of using, for example, if/then/else with some other custom vocabulary (doesn't have to be real) but without having any validation keywords?

[handrews]

@epoberezkin Good question! The answer has to do with thinking about assertion keywords, as defined in both core and validation, that are not part of the current validation vocabulary.

Thinking of a UI schema vocabulary (which I know you disagree with but please bear with me, I can work up another example later if you'd like), such a vocabulary could define an assertion keywords for user-agent properties.

{
    "if": {"userAgent": "mobile"},
    "then": {...},
    "else": {...}
}

I'm not sure that's actually a good UI approach, but hopefully the idea comes across: a vocabulary may define its own assertions, which are just as useful with applicability keywords as the validation assertions.

Of course a UI schema could use the regular validation vocabulary, but it does not have to.

Even if some applications would want to use the UI vocabulary with the validation vocabulary, others may not need to, in which case an implementation of the UI vocabulary could be optimized by not implementing validation keywords at all. This gives implementations more flexibility to define and use what is needed, and choose the most performant implementation approach for their application.

Just like I would probably not use a hyper-schema implementation unless I actually needed hyper-schema, because there's a lot of extra logic in finding and building links that is not needed for validation. I'd rather use an optimized validation implementation if that is all I need. So the UI schema application may prefer to use an optimized ui-only implementation.

This is straightforward if applicability keywords are defined separate from validation. It is awkward if they are included in validation because now you are supporting part but not all of a specification.

[epoberezkin]

The problem with that approach is that even if a vocabulary defines its own assertions, it still makes sense to use assertions from the validation vocabulary, even for UI. Otherwise vocabulary will have to redefine the assertions. E.g., a very common use case for UI is to show some part of UI based on the value of some other field (e.g. dropdown). With validation vocabulary you will just be able to use it to change how UI looks.

To me the attempt to separate applicability from validation assertions seems very artificial and completely unnecessary. I can't come up with any idea for a vocabulary that uses JSON as the underlying data structure and would not benefit from the availability of validation vocabulary to define any logic based on the data that it uses for whatever other purpose.

To me validation assertions seem to be the minimal necessary foundation on top of which any other functionality can be built.

[Anthropic]

@handrews I agree it's worth looking into, I've never really liked structural keywords being lumped in with validation, always seemed illogical to me. The boolean logic group doesn't seem specifically tied and the conditional I was never really comfortable with in its current form anyway. I'm sure there's plenty of areas outside the box of my own project remit that would prefer this if/when there's any form of extensibility too perhaps.

I'm about to fly to Japan for three weeks snowboarding, so sorry, but I won't really get much chance to think it through or respond further for nearly a month.

[Relequestual]

To be honest, I've always found this a little strange, but it is how it is. I guess when you're only thinking about validation, it's OK, but we have other concerns now, and we should allow them to use these control or "applicability" keywords, without needing to redefine them.

I'm not 100% clear on how each class of word could be used outside of validation. @handrews if you could provide an example for each class, I would feel happier in my understanding, and more able to review any PRs that arrise from this issue.

[handrews]

@Relequestual sounds good!

Let's define properSpelling and properGrammar as assertions that take an ISO language code indicating what rules to use. Those assertions are far too complex and ambiguous to put into the standard validation vocabulary, but someone might want to use JSON Schema to apply checks of this sort to text within a JSON document. They can define their own vocabulary and use whatever spelling / grammar checking implementations they want.

Here's a schema that our other examples will reference. It defines schemas that mean if the instance is an object with a "title" property, then that title is correctly spelled English, or correctly spelled Chinese ("zh" is the ISO language code for written Chinese).

{
    "$id": "https://example.com/schemas/titles",
    "definitions": {
        "englishTitle": {
            "properties": {"title": {"properSpelling": "en"}}
        },
        "chineseTitle": {
            "properties": {"title": {"properSpelling": "zh"}}
        }
    }
}

Here is a schema that checks all objects in the document, regardless of other structure, and ensures that each object either does not have a "title" field, or if it does, that it is either properly spelled English or properly spelled Chinese:

{
    "oneOf": [
        {"properties": {"title": false}},
        {"$ref": "https://example.com/schemas/titles#/definitions/englishTitle"},
        {"$ref": "https://example.com/schemas/titles#/definitions/chineseTitle"}
    ],
    "allOf": [
        {   
            "items": {"$ref": "#"},
            "additionalProperties": {"$ref": "#"}
        }   
    ]
}

Here is a schema that verifies that if an object has a properly spelled English "title", or a properly spelled Chinese "title", then any "exampleSentence" property is properly spelled and grammatically correct in that same language, while "exampleErrorSentence" is properly spelled and not grammatically correct in that same language:

{
    "anyOf": [
        {   
            "if": {"$ref": "https://example.com/schemas/titles#/definitions/englishTitle"},
            "then": {
                "properties": {
                    "exampleSentence": {"properGramar": "en"},
                    "exampleErrorSentence": {"not": {"properGrammar": "en"}}
                }   
            }   
        },  
        {   
            "if": {"$ref": "https://example.com/schemas/titles#/definitions/chineseTitle"},  
            "then": {
                "properties": {
                    "exampleSentence": {"properGrammar": "zh"},
                    "exampleErrorSentence": {"not": {"properGrammar": "zh"}}
                }   
            }   
        }   
    ],
    "allOf": [
        {   
            "items": {"$ref": "#"},
            "additionalProperties": {"$ref": "#"}
        }   
    ] 
}

Like the oneOf example, this checks all objects in the document regardless of structure. Unlike the oneOf example, an object with a title that is neither properly spelled English nor properly spelled Chinese is always valid (with no constraints imposed on the other fields).

Technically, you could condense this last example down and avoid the if/then, but given the expense of checking spelling/grammar, the if/then encourages implementations to first check the (presumably short) "title", and only check the other properties if relevant.

---

These examples use at least some of each of the combinatorial logic, conditional, object, and array applicability keyword sub-categories. Admittedly the items usage, which is the lone array keyword used, does not directly involve the hypothetical vocabulary, but hopefully it's clear that it's not significantly different than using properties.

The examples do not use any assertions or annotations from the Validation spec. Recall that the boolean schemas are defined in the Core spec.

[Relequestual]

I think I understand what you're saying here, but when I said outside of validation, I meant general validation, not the spec validation. The examples you've given seem to be about validating instances.
I guess it's OK, but I was looking for say how it could be used with a spec which handles something like form generation or JHyperS. But nevermind.
I think I'd probably be OK to review PRs on this.

I should have been more explicit that I was looking for an example per key word class, rather than all together. JUST to make it super clear for my feeble mind. KISS =]

[handrews]

@Relequestual OK, sorry, that wasn't clear particularly given @epoberezkin's immediately prior assertion that:

even if a vocabulary defines its own assertions, it still makes sense to use assertions from the validation vocabulary, even for UI. Otherwise vocabulary will have to redefine the assertions.

Hopefully my example has at least addressed that objection. I would expect systems that need the features of the standard validation vocabulary to use it, but you can certainly construct use cases that use other validation keywords and do not need the standard vocabulary (but do need the applicator keywords).

I guess it's OK

I would hope it's a bit more important than that, as it's one of the main points of the proposal: that the standard validation vocabulary is not and should not be the only viable assertion vocabulary.

So.. trying again without any assertions at all, which hopefully is what you are looking for...

Issue #56 proposes allowing templated values for rel, which could be used to make non-templated, non-curied JSON HAL links usable by hyper-schema (using validation keywords wouldn't help make curied or templated links usable, so that's not a problem for this as an example).

The "0#" Relative JSON Pointer resolves to the name of the current property. It is not a URI reference and the # is not a fragment marker. In HAL, the property names of the _links object are the link relation types.

The "0/href" pointer is technically unnecessary as it's the default value but I figure it makes things a bit more clear.

{
    "properties": {
        "_links": {
            "additionalProperties": {
                "links": [
                    {   
                        "rel": "{propertyName}",
                        "href": "{href}",
                        "templatePointers": {
                            "propertyName": "0#",
                            "href": "0/href"
                        },  
                        "templateRequired": ["href"]
                    }   
                ]   
            }   
        },  
        "_embedded": {
            "additionalProperties": {
                "oneOf": [
                    {"$ref": "#"},
                    {"items": {"$ref": "#"}}
                ]
            }
        } 
    }   
}

Please let me know if this addresses your concerns. I'm looking for something a little more enthusiastic than "I guess that's OK" before diving into a PR if at all possible :-)

[Relequestual]

OK. I think I'm with you now. I feel a little unfamiliar with developments of JHyperS, but catching up with that one issue, reading up on relative JSON pointers (is this new?).

I can see how additionalProperties can be used for not assertation purposes here. Great!

Given I personally don't see many direct applications for this (right now), I can upgrade my status from "I guess that's OK", to "This should be a thing", but I'd struggle to be excited about it. Figure that's good enough though =]

[epoberezkin]

@handrews I agree with @Relequestual - this "seems" almost harmless, but it doesn't seem to change or improve anything, so it's difficult to be excited about this change.
I completely agree that it's worth differentiating applicability keywords from validation keywords but splitting them into two separate documents (rather than two sections of the same document) seems only adding to the management overhead without adding any value.

Even if some vocabulary doesn't need validation keywords to define its logic, their presence won't hurt. On the other hand, the absence of validation keywords allows to redefine them in a different way, that can be quite harmful. To avoid it you will have to say in applicability spec that a vocabulary not using validation spec should still avoid redefining validation keywords. It seems quite artificial to me, as you would still not achieve complete independence of a vocabulary from validation spec.
Also I don't see how users of such vocabulary would not be interested in using validation keywords at least sometimes - e.g "const", "enum", "minimum" or "minLength". As I wrote, anything that uses JSON would need some basic assertions on the values.

In addition to that I still see #515 as conflicting with this proposal (and even undermining the ability to differentiate applicability and validation keywords), not sure where this discussion belongs, here or there, but you didn't comment on it yet.

[Relequestual]

I didn't say it doesn't change or improve anything. I think it's the right move. I can see the application, and those key words don't belong in validation when they are ... applicable (a ha) elsewhere. They belong in core.

We have overshight of any new JSON Schema related specs. There are a number of applications outside of validation and it's important to show that they can be mutually exclusive.

Also I don't see how users of such vocabulary would not be interested in using validation keywords at least sometimes

Then you can't understand why this change is important.

[Relequestual]

I'm making this as Accepted. It's clearly defined and required for moving forward. @handrews have at it.

[epoberezkin]

They belong in core.

I thought the discussion was leaning towards having a separate spec. In core is definitely better.

Then you can't understand why this change is important.

I understand that it's easy to come up with an example where a validation assertions are not used, as above. What I want to see though is a use case case of a vocabulary where you can guarantee/prove that validation assertions will NEVER be needed. Or at least where it will be difficult to come up with an example when validation assertions are needed. Can somebody present an idea for such vocabulary? All vocabularies I can think of would need validation assertions in some cases.

I'm making this as Accepted.

@Relequestual why not figure out the contradiction with #515 first? Or at least establish that they can coexist?

[handrews]

@epoberezkin

That conclusion seems not logical to me. If a sufficient number of users (you wrote "many probably will") of some vocabulary need validation assertions, why should it not be the requirement for any implementation to support them?

Because those sufficient number of users are not in any way inconvenienced by this reorganization, and many of us have clearly stated that we see benefits.

If a sufficient number of users (you wrote "many probably will") of some vocabulary need validation assertions, why should it not be the requirement for any implementation to support them?

Because it is not necessary to make that a requirement in order to meet the needs of those users.

From the first part of your statement it follows that if a vocabulary implementation does not support validation assertions then many users will not be able to use such implementation. Why do you see it as an acceptable outcome?

Because if an implementation is not usable to users then the users will not use it. They will instead use an implementation that provides the validation keywords. This "problem" solves itself- it's not a real problem.

To summarize:

1. You have identified as your primary concern that validation be universally available. This issue does not prevent that in any way
2. Your argument that we should not do this is that the majority of users will not benefit from it. Our argument is that some users will benefit from it, and there is no downside (see point 1) to providing those users with this benefit
3. You want to know why what you see as unusable implementations are acceptable, but for some those implementations will be usable and preferred, while for others they will simply not use implementations that are unusable

To attempt an analogy: If nearly all users want format to be fully implemented, then only implementations with format support will become popular. But the minority of users who prefer faster validation without format support will benefit from format not being required.

Making format optional means that implementations are free to fully support it, not support it, or make it user-configurable. This freedom of implementors to make their own cost-benefit trade-offs, and the corresponding freedom of users to choose which trade-offs are most suitable for their purposes, is an asset of JSON Schema.

The same is true of allowing applicability without validation. While most users will likely want validation, the threshold the rest of us have agreed is appropriate for this issue is "some implementors and users will benefit from this, and none will be harmed."

We have shown that some users will benefit. You have not shown that any users will be harmed.

[handrews]

@epoberezkin as far as dependencies, I will make one comment on it here, and if you want to argue it further please file it as its own issue about where to put that specific keyword. I will ignore further argument on the point in this issue, unless @Relequestual asks me to respond to it specifically.

You said:

ALL applicability keywords are also assertions

No, I explicitly state in the spec (which you even quoted!):

Such keywords do not assert conditions on their own. Rather, they control how assertions are applied and evaluated.

The rules for how to aggregate subschema assertion results are not themselves assertions. Applicators apply subschemas and aggregate the results. They have no results without subschema results. This is exactly what the distinction between applicators and assertions means. It is why I made the distinction, and why I chose the words quoted above.

• {"dependencies": {"foo": {...}}} is equivalent to {"if": {"required": ["foo"]}, "then": {...}}
• {"dependencies": {"foo": ["bar"]}} is equivalent to {"if": {"required": ["foo"]}, "then": {"required": ["bar"]}}

In both forms, the behavior depends on required, which is an assertion. The goal here is to move the applicability keywords only. dependencies is an applicability + assertion hybrid, so it stays with the assertions. The core spec should not contain assertions (other than the boolean schemas true and false which are the trivial assertions).

This proposal does not involve moving any keyword with assertion behavior, as I have defined it in section 3.1 of draft-handrews-00. dependencies has assertion behavior, so it is by definition out of scope for this issue. Please feel free to file your own issue asking that it be moved, and we will continue to discuss it there.

[epoberezkin]

You have not shown that any users will be harmed.

I believe I have, but you just ignore it. But time will show. My prediction is that now you will move applicability keywords to the core. Then you'll realise that annotation keywords are also needed to any vocabulary and you move them as well. After that you'll realise that some validation assertions are also needed (e.g. required, const, minimum, ...). At that point validation spec will have too few keywords left there to justify the existence of validation spec.

[handrews]

I believe I have, but you just ignore it.

I honestly do not believe that I have. Could you clearly state the harm that you see in the simplest possible terms? By "harm" I mean "the users will not be able to achieve their goals." I do not consider "some implementations will not meet the goals of all possible users" to be harm. Perhaps that is what is coming across as ignoring?

[dlax]

@epoberezkin I don't have much to add to @handrews' answer (which I completely agree with) so I might just be paraphrasing here. The analogy with format is relevant to illustrate the point, by the way.

I disagree about validation keywords being always needed.

@dlax I never said they are always needed, I only said they will be needed by some users of any vocabulary.

So this is the difference between a MUST and a SHOULD implementation requirements. If you agree that we are in the SHOULD domain, that's fine.

If a sufficient number of users (you wrote "many probably will") of some vocabulary need validation assertions, why should it not be the requirement for any implementation to support them?

I could pursue the point I made before about "storage backend" validation and JSON Schema validation "shortcomings" (which are due to its inherent design) and argue that some users might simply be interested in JSON Schema as a way to expose general validation results to the end user, thus only taking advantage of the "applicability" concepts. In this respect, validation can be viewed as a kind of runtime annotation of the instance. JSON Schema validation is just one way to validate an instance, but any kind of validation would take advantage of "applicability" keywords to convey its assertion results.

From the first part of your statement it follows that if a vocabulary implementation does not support validation assertions then many users will not be able to use such implementation. Why do you see it as an acceptable outcome?

This is just about diversity, and it's essential that the specification favors diversity IMHO.

[handrews]

Then you'll realise that annotation keywords are also needed to any vocabulary

No, that is completely contrary to the spirit of this issue. While it is debatable whether the annotation keywords truly belong with validation (it was raised repeatedly by multiple people during draft-06 and I kept making everyone hold off on the topic), I absolutely do not believe that they belong in core. There is even less of an argument for annotations to be in core than for assertions.

[epoberezkin]

@handrews referring back to your example in #513 (comment)

Can you please tell me how many users of this sample vocabulary will NEVER want to do something like:

{
    "anyOf": [
        {   
            "if": {"$ref": "https://example.com/schemas/titles#/definitions/englishTitle"},
            "then": {
                "properties": {
                    "exampleSentence": {
                      "type": "string",
                      "properGramar": "en",
                      "minLength": 0
                    },
                    "exampleErrorSentence": {
                      "type": "string",
                      "not": {"properGrammar": "en"},
                      "minLength": 0
                    }
                }   
            }   
        },  
        {   
            "if": {"$ref": "https://example.com/schemas/titles#/definitions/chineseTitle"},  
            "then": {
                "properties": {
                    "exampleSentence": {
                      "type": "string",
                      "properGrammar": "zh",
                      "minLength": 0
                    },
                    "exampleErrorSentence": {
                      "type": "string",
                      "not": {"properGrammar": "zh"},
                      "minLength": 0
                    }
                }   
            }   
        }   
    ],
    "allOf": [
        {   
            "items": {"$ref": "#"},
            "additionalProperties": {"$ref": "#"}
        }   
    ] 
}

to make sure the properties are non-empty strings?

If that vocabulary were to depend only on core, how would "type" and "minLength" be available?

My argument is that ALL users of any vocabulary will at least sometimes need to use validation assertions in addition to the assertions defined in vocabulary.

There are only two possibilities, really:

1. There may be vocabularies that don't use any assertions at all. But if that were the case, they would not be able to use the keywords "anyOf", "oneOf", "if/then/else", "not", because they are meaningless without assertions.
2. All vocabularies need some assertions. If that is the case, then there are two possibilities:

• any vocabulary also needs at least some basic validation keywords to assert some basic things about the underlying data - that the string is not empty ("minLength"), that the value is a number ("type"), that the number is positive ("minimum"), etc.
• vocabularies will have to define their own assertions to either include existing validation assertions (e.g. "properGrammar" above can imply that the data is a non-empty string) or to re-define them as separate keywords. Neither is efficient and both create overlap with validation, that is counter to the orthogonality principle (e.g., nothing implies "type").

It's just logic. What's the mistake in it?

[handrews]

There may be vocabularies that don't use any assertions at all. But if that were the case, they would not be able to use the keywords "anyOf", "oneOf", "if/then/else", "not", because they are meaningless without assertions.

But they are not dependent in any way on the specific set of assertions that make up the validation vocabulary. This is actually the point: Applicability keywords of the sort you mention depend on the existence of assertions (which is covered in the core spec, and bootstrapped with the boolean schema as trivial assertions). They do not depend on any specific assertions. Therefore they should not be tied to any specific set of assertions.

any vocabulary also needs at least some basic validation keywords to assert some basic things about the underlying data - that the string is not empty ("minLength"), that the value is a number ("type"), that the number is positive ("minimum"), etc.

It's just logic. What's the mistake in it?

You are attempting proof by example, which is a logical fallacy. Proof by example works if you are reaching an existential conclusion (at least one such thing exists). It is a fallacy for a universal conclusion.

Your argument is that you see some users, or some possible vocabularies as needing the standard validation keywords. Since you see at least one example, you conclude that all possible users/vocabularies must involve the standard validation keywords. That is a universal conclusion, and is not provable by example.

On the other proof by counter-example is sufficient to disprove a universal conclusion (it is insufficient to disprove an existential conclusion). So here, you are asserting that the standard validation keywords are always necessary (universal conclusion). However, @dlax and I have both given counterexamples. @Relequestual has accepted the counterexample. Therefore your universal conclusion is disproven.

---

Your logic is based on a fallacy.

I feel that I have spent enough time on this, and that enough other people are on board. You are welcome to appeal this to @Relequestual, since a 3rd party is necessary to mediate disputes such as this, and I think we can all agree that he is the most reasonable of the main contributors here.

[epoberezkin]

Example was for the illustration, not as a proof.

I can repeat the question: if validation assertions are not available, how would a user assert that some location in data has, for example, a correct type? How many users would NEVER want to assert the type of data? My argument here is that all users of any vocabulary would need to assert at least data type, if not always, then often.

[erayd]

@epoberezkin I hate to say this, but I'm starting to feel like you're deliberately trolling these threads. Must you object to everything, and refuse any possible attempt at a compromise? You are not the only person with a stake in this.

This issue proposes shuffling the deck chairs a little, no more, no less. It doesn't change implementations at all; there is no practical downside to doing this. From where I'm sitting, many of your objections do not appear to stand up to rational analysis, and often ignore the reality of the points being discussed.

I can repeat the question: if validation assertions are not available, how would a user assert that some location in data has, for example, a correct type?

They wouldn't use validation assertions. They may be using some other kind of assertion that includes a type check, or the type may be checked elsewhere outside of JSON schema, or they may be using an input which is already guaranteed to be of the correct type. There are plenty of instances where a validation vocabulary type-check is not required.

As @handrews has said, repeatedly, If the user cares about validation assertions, then they will use an implementation that provides them. If they do not care, then they are free to choose an implementation which does not.

How many users would NEVER want to assert the type of data? My argument here is that all users of any vocabulary would need to assert at least data type, if not always, then often.

This is a red herring. There have been multiple examples proposed of use-cases which do not require the validation vocabulary, and are therefore candidates to benefit from this change. If no users ever want to do without the validation vocabulary, then nobody will use an implementation that lacks it. This is both self-evident and self-policing.

[epoberezkin]

@epoberezkin I hate to say this, but I'm starting to feel like you're deliberately trolling these threads.

That is a very strong and insulting statement. @erayd didn't you previously say that "ad-hominem attacks have no place here"? So, now personal attacks are ok, aren't they?

Must you object to everything, ...

I only object to things that create internal contradictions in the spec, violate its foundational principles and/or create problems to the users of the specification. Unfortunately such things are often overlooked. It usually takes a surprising effort for people who propose the changes to detach from their ideas and start thinking about their implications and bigger picture. We had similarly strong discussions about $schema, $ref, if/then/else, when my point of view was eventually accepted, after some very strong arguments.

and refuse any possible attempt at a compromise?

I am always happy to compromise, but usually it is neither proposed nor accepted. The compromise here would be, as I suggested, to put this issue on hold until #515 is settled, and $vocabulary is agreed upon, because this issue creates implications to them.

They wouldn't use validation assertions. They may be using some other kind of assertion that includes a type check, or the type may be checked elsewhere outside of JSON schema, or they may be using an input which is already guaranteed to be of the correct type. There are plenty of instances where a validation vocabulary type-check is not required.

I understand of course that you can validate things outside of the schema. But it is very unconventional to use a schema for validating some custom assertions, being able to use "properties" keyword and not being able to use "type" or "minimum". I have heard from a lot of users of JSON schema that when they use a declarative document for any assertions, they want all their assertions in that document, not just some of them. From that point of view the implications of the change can be very surprising for most users.

[erayd]

That is a very strong and insulting statement. @erayd didn't you previously say that "ad-hominem attacks have no place here"? So, now personal attacks are ok, aren't they?

My comment is not ad-hominem / personal attack, and I maintain my position that such attacks are not appropriate. Please take my comment in the spirit it was clearly intended - i.e. reluctant advice that I am beginning to feel trolled by your posting style, and a brief explanation of why that is the case.

I personally am finding participation here unpleasant, and feel that discussions are becoming unproductive, as a direct result of how you are engaging with some of these issues. You bring a valuable perspective to the table, and make some good points - I am simply asking you to take a second look at the manner in which you are debating things in some areas.

I am always happy to compromise, but usually it is neither proposed nor accepted.

I disagree. I've seen what look like a number of attempts at compromise (to be fair, not always explicitly stated as such, although the intent seems clear), followed by you refusing to budge on whatever the issue happens to be, or throwing in out-of-scope objections (e.g. the static analysis argument in #515) while ignoring relevant discussion points.

In fairness to you, there are a number of other stubborn contributors here, myself included - so a certain amount of head-butting between us is to be expected, perhaps. But it's important that despite this, we can all discuss constructively and make useful progress on whatever the issue of the moment happens to be.

...put this issue on hold until #515 is settled, and $vocabulary is agreed upon, because this issue creates implications to them.

Could you please, clearly and concisely, state what those issues are. Unless I've missed something, I haven't yet seen a clear explanation of why either of those things are relevant.

• $vocabulary does not appear relevant, because this issue results in some keywords living in a core spec, and some in a validation spec. That's exactly the same as things already are currently. All that happens is some keywords move from one document to the other. Whether and how to provide some kind of $vocabulary mechanism is certainly something that needs discussion, but why should that discussion block this one, when the outcome of that discussion (whatever that happens to be) does not appear to materially impact things here, and this one does not constrain how $vocabulary might be specified?

• Flexible re-use: deferred keywords vs schema transforms #515 also does not appear relevant, because it's a discussion regarding extensibility, possibly resulting in new keywords. Those keywords will need to live in either the validation spec, the core spec, or a home of their own - which, again, is exactly the same as things are currently. If anything, this issue should be resolved before Flexible re-use: deferred keywords vs schema transforms #515, because this issue may impact which document any keywords resulting from Flexible re-use: deferred keywords vs schema transforms #515 should be specified in.

I understand of course that you can validate things outside of the schema. But it is very unconventional to use a schema for validating some custom assertions, being able to use "properties" keyword and not being able to use "type" or "minimum".

Unconventional from the perspective of a standard JSON schema validator, certainly. On that we definitely agree. Users who simply wish to validate things in the 'traditional' way (i.e. the manner in which JSON schema has operated to date) will expect to be able to mix and match all the usual validation keywords in their schemas, and will continue to be able to do so as normal with no changes.

I have heard from a lot of users of JSON schema that when they use a declarative document for any assertions, they want all their assertions in that document, not just some of them.

It's fairly common to split things up, rather than validating everything against one massive monolithic schema (especially when multiple teams or multiple different application components are involved). But nothing about this change prevents the use of monolithic schemas; if that's what users want to do, there's nothing stopping them.

From that point of view the implications of the change can be very surprising for most users.

How is the status quo surprising? For a current user of JSON schema, there is no change whatsoever needed in their behavior - they can continue to do exactly what they have always done, with no regard for this issue at all.

[handrews]

I'm going to lock this and other issues until @Relequestual is recovered from being sick and has a chance to catch up and mediate. I considered responding to the last two comments, but I think my positions are predictable at this point and there's no reason for me to add to the volume.

Suffice to say that I think valid code-of-conduct concerns have been raised, and I will take them up with @Relequestual and @awwright because a I believe at this point we need a written policy.

[Relequestual]

I tagged this issue as accepted. That means I believe the general consensus is we should do this. If anyone doesn't agree with that assessment, then you don't agree. This is no longer the place to debate it. Don't waste everyone elses time by drawing people into debating it further. Just stop. Accept your view point was not the one that was accepted.

Wait till it's added to the spec, PR accepted, then raise an issue (if there are any remaining).

---

@Relequestual the problem here is that if you allow a vocabulary to build on top of core (or applicability) without validation, then in order to use validation keywords in such schema you would have to introduce support of multiple vocabularies in a single schema.

@epoberezkin not at all. The fancy-schema-vocab specification just says, "This spec extends core and validation", just like we say validation extends core.

[handrews]

And with that clear resolution, I am changing the lock reason from "too heated" to "resolved".

I have filed #529 for tracking Code of Conduct issues.

[handrews]

PR #572 implements this.

[handrews]

Merged #572.