Applicator, Assertion, and Annotation as behaviors not categories

[gregsdennis]

Core 7 describes keywords as belonging to "behavior categories." However, I don't think "categories" is quite right. It seems to imply that a keyword only behaves in one of these ways, which isn't the case. (If that's not what it's saying, I'm still reading it that way, and it could be clearer.)

These are just behaviors. Case in point: properties actually assumes all of these behaviors:

• it's an applicator because it contains subschemas
• it produces an annotation of the keywords it constrains
• it produces a validation result by AND-ing all of the applicable subschemas' validation results

I think this section could make it clearer that a keyword can (and often does) embody more than one of these behaviors.

[jdesrosiers]

I don't think the intention was to imply that these behaviors are mutually exclusive. If that's not clear enough, we should fix that.

I'd also be in favor of dropping that section entirely. IMO, the only thing that matters is what inputs are available and what output is expected. Whatever behavior is possible from the inputs you have is a possible behavior for a keyword. Categorizing keyword behavior seems more appropriate for a research paper.

[benjagm]

Hey! When reading this issue I moved it by mistake into the "In Discussion" status but I can't find a way to find the previous status to revert it. Is "In discussion" the right status for this issue?

[gregsdennis]

I'd also be in favor of dropping that section entirely. IMO, the only thing that matters is what inputs are available and what output is expected. Whatever behavior is possible from the inputs you have is a possible behavior for a keyword. Categorizing keyword behavior seems more appropriate for a research paper.

This opinion leans into #1159 where I proposed that we reorganize the meta-schemas. If behaviors like "applicator", "annotation", and "assertion" are the output of a meta-analysis of keywords, then it doesn't make sense to organize our vocabularies using these concepts, which means we need some other way to organize them. To me, that's by applicable JSON type (e.g. all of the "object" keywords together) and/or keyword purpose (e.g. boolean logic, conditionals, etc)

[jdesrosiers]

I'm definitely in favor of revisiting vocabulary organization, but I'm still strongly of the following opinion ...

vocabulary organization is arbitrary and no matter what we choose, there will always be use cases where it doesn't make sense. I'd rather define keywords than vocabularies. Then people can combine them however they like without being constrained by the categorization we choose for them.

I strongly believe that there needs to be a decoupling of keywords from vocabularies. If we do that, it matters very little how we group keywords into vocabularies or if we define vocabularies at all. We can even provide both a type-optimized and composition-opitmized set of vocabularies that group the keywords in different ways. But most importantly, anyone can define their own vocabularies tailored to their needs if ours don't make sense for them.

[gregsdennis]

Okay. Let's have the vocab rework conversation over there, whatever it ends up being. I really just wanted to link these two since they seem related.

---

"Applicator" in particular is useful as a concept because it makes unevaluated* easier to define since unevaluated* MUST run after all other applicators. I'm not convinced removing it is the right direction, but I'm also not sure what needs to be done.

[jviotti]

Aside from the vocabulary rework conversation, I agree the current description seems a bit misleading. I remember first reading the specs and indeed assuming that one keyword had to be of one and only one category.

However, once you understand what some of these terms mean, like "applicator" and "annotation", it makes understanding other keywords easier, as these terms can condense a lot of what we mean in a single word. It's great vocabulary that I think should remain somewhere and continued to be polished (for example I really liked @gregsdennis 's recent idea of separating applicators that apply schemas to the current instance location like anyOf vs the ones that add structure, like properties). I wouldn't want these terms to get lost.