$vocabulary behaviour

[SorinGFS]

Context

This would be the next natural question after dynamicAnchor behaviour on which $vocabulary system seem to depend on.

First of all I thank @jdesrosiers for the great help in understanding $dynamicAnchor - $dynamicRef behaviour. In that question at some point there is this quote I pinned in my quest map to understand json-schema.

The specification itself can't be changed, but it does include an extension mechanism we call the Vocabulary System.

I ask this because I wonder if the $dynamicAnchor and $dynamicReferences used inside of those specs couldn't be in fact avoided...

I'm not sure what you mean by this. These are not optional features. You'd have to implement them in order to be compliant with the specification. [...] There are things that are only possible with dynamic references such as extending a recursive schema.

Questions

Despite the fact that I solved the $dynamicRef resolution in my project I suspect that it wouldn't be complete without including the $vocabulary system.

1. Is the $dynamicRef-$dynamicAnchor extension mechanism involved in $vocabulary system ? If yes, how? If not, what is it ?
2. If a schema contains the keyword $vocabulary containing an url, does that corresponding file need to have the same $dynamicAnchor value as the parent schema?
3. What is the priority when the parent schema contains the same keyword as an embeded $vocabulary ?
4. Can a $vocabulary override a json-schema spec keyword ?
5. What is the priority between embeded $vocabulary 'ies ? Can they define the same keyword ?
6. Can a $vocabulary corresponding schema contain another $vocabulary?
7. Can a schema contain only $vocabulary without any other defined keywords ?

There are more questions, but they depend on the answers to the first questions.

[gregsdennis]

dynamicAnchor behaviour on which $vocabulary system seem to depend on.

The vocabulary system is independent from $dynamic*. We use $dynamic* in the meta-schemas so that people can extend them easily, but they could have been written without $dynamic*. Using $dynamic* just makes it easier on people who want to create their own meta-schemas that build on ours.

---

$vocabulary is a way for people to define custom keywords in such a way that allows implementations to declare that they support those keywords, or even refuse to process the schema if they don't understand the keywords. It prevents "surprises:" unexpected inconsistencies between implementations.

This system is still under development, so we don't necessarily have answers for all of your questions, particularly the "what to do in the event of a conflict" ones.

As it stands, vocabularies can define the same keywords, even ones that the spec defines. However, in the event of a collision, the behavior is undefined. That is, the implementation gets to choose what to do. Eventually, we'd like to define this, but we just haven't explored it enough, yet.

Right now, this space is just underspecified.

---

If you'd like more reading on how vocabularies work, I have some docs with an explanation and about as simple an example as I could devise. I have also written two vocabularies, data & uniqueKeys, in an attempt to support some ideas presented by long-standing issues in the spec repo.

[SorinGFS]

Thank you for the edifying answer:

$vocabulary is a way for people to define custom keywords in such a way that allows implementations to declare that they support those keywords, or even refuse to process the schema if they don't understand the keywords. It prevents "surprises:" unexpected inconsistencies between implementations.
This system is still under development, so we don't necessarily have answers for all of your questions, particularly the "what to do in the event of a conflict" ones.
As it stands, vocabularies can define the same keywords, even ones that the spec defines. However, in the event of a collision, the behavior is undefined. That is, the implementation gets to choose what to do. Eventually, we'd like to define this, but we just haven't explored it enough, yet.
Right now, this space is just underspecified.

Can I extend this to Still Kinda Supporting Unknown Keywords would be a 100% alternative to $vocabulary ?

As a different fact, if the introduction of vocabularies was a necessary preliminary step to the dissallowing of unknown keywords then I can say that since these keywords are put in a separate file the schema authors did not necessarily need vocabularies to propagate their own keywords.

I saw in the $vocabulary (not as json-schema defined keyword, but in it's structure) a very different power. Keywords in $vocabulary are identifiers, same as id or $id, so basically every $vocabulary key is a separate keyword having it's own $id. This mechanism holds a tremendous power allowing us to have a precise navigation between schema and non-schema, or between http or non-http.It also allows us to combine multiple environments without colision, any colision being in fact a superset. This is what I'm trying to do in my project, and using this reference mechanism I was able to interconnect thousands of links of hundreds of schemas because this is a native interlinking mechanims that doesn't require extra proccessing for linking. The json-schema uses a local json pointer for their specs but this mechanism would bring the power to the next level: global json pointer !

[gregsdennis]

Can I extend this to Still Kinda Supporting Unknown Keywords would be a 100% alternative to $vocabulary?

No, not at all. I have a blog post about this coming soon. x- keywords will be reserved for ad-hoc annotation-only keywords; vocabularies will be restricted from defining them (even the ones in the spec).

They are disjoint sets.

if the introduction of vocabularies was a necessary preliminary step to the dissallowing of unknown keywords...

No, vocabularies were designed as an extension point long before we considered disallowing unknown keywords. The unknown keywords issue only pertains to making the spec stable and compatible between versions. The two are not related.

Keywords in $vocabulary are identifiers, same as id or $id, so basically every $vocabulary key is a separate keyword having it's own $id.

This isn't right.

$vocabulary keys are the IDs of the vocabularies themselves. There's no file associated with them. They're just URI IDs.

The implementation needs to know solely from the ID whether it supports the keywords a vocab defines. There's nothing that the implementation can read to link the vocab to its keywords.

Vocabularies MAY also define a meta-schema (which has a different $idand is $ref'd in an allOf), but that's only used for validation of how the keywords are used. It doesn't define the keywords.

This mechanism holds a tremendous power allowing us to have a precise navigation between schema and non-schema, or between http or non-http.

I think you're reading into vocabularies with some misunderstanding of them. I'm not sure how this applies.

[SorinGFS]

Keywords in $vocabulary are identifiers, same as id or $id, so basically every $vocabulary key is a separate keyword having it's own $id.

This isn't right.

$vocabulary keys are the IDs of the vocabularies themselves. There's no file associated with them. They're just URI IDs.

The implementation needs to know solely from the ID whether it supports the keywords a vocab defines. There's nothing that the implementation can read to link the vocab to its keywords.
Vocabularies MAY also define a meta-schema (which has a different $idand is $ref'd in an allOf), but that's only used for validation of how the keywords are used. It doesn't define the keywords.

This mechanism holds a tremendous power allowing us to have a precise navigation between schema and non-schema, or between http or non-http.

I think you're reading into vocabularies with some misunderstanding of them. I'm not sure how this applies.

I take from the point where I started the quote. You omited an important part right before that part, I paste here what I said:

I saw in the $vocabulary (not as json-schema defined keyword, but in it's structure) a very different power. Keywords in $vocabulary are identifiers, same as id or $id, so basically every $vocabulary key is a separate keyword having it's own $id.

I bolded the important omited parts.

Let me explain this a bit:

A json object has this structure:

{
    "key (may be also read as keyword)": "value",
    "https://json-schema.org/draft/...": "whatever",
    "^-------------------------------^": "is a keyword and also an identifier"
}

Anything defined in the key part is what json-schema also uses by the term keyword.

[gregsdennis]

My reply was to the text I quoted. The identifiers in $vocabulary are not the same as those in $id. They are both URIs, yes, but they represent different things.

Also, they are not themselves keywords. Please try to find ways to communicate your ideas that don't use terms we've very clearly defined. Confusion arises when you try to redefine well-known terms.

Anything defined in the key part is what json-schema also uses by the term keyword.

This is wrong. JSON Schema has a very particular meaning for "keyword." Keywords are like operators that impart meaning (annotation or validation) when evaluating an instance. They are not just arbitrary keys in some JSON data.

The difference reveals itself when you consider that JSON is just how JSON Schema is rendered. JSON doesn't define the structure or internal workings of JSON Schema. JSON Schema has keywords, but JSON does not.

[SorinGFS]

Also, they are not themselves keywords. Please try to find ways to communicate your ideas that don't use terms we've very clearly defined. Confusion arises when you try to redefine well-known terms.

Sorry about that, but how to communicate my ideas for cases that you didn't invented yet? I specified that I'm not refering to keyword as known by json-schema. And I'm not too good at literature, not even in my native language, let alone in English... 😄