Ben Hutton

It all starts with applicability - JSON Schema Fundamentals part 1


*I’ve been known to say “If you haven’t rewritten your OpenAPI bundling implementation recently, then you don’t support OpenAPI 3.1”. This observation may be true, but perhaps some more detail would be helpful? When implementing support for OAS 3.1 and JSON Schema draft 2020-12 in `oas-kit`, reading the sections of the JSON Schema spec on bundling compound documents, I still wasn’t totally clear on what was expected of compliant tooling. Thankfully, Ben Hutton is here to set the record straight with a worked example.* - Mike Ralphson, OAI TSC

## Bundling has renewed importance

OpenAPI has long since put the spotlight on JSON Schema, and the release of OpenAPI 3.1 has huge implications for the future of both projects. I'm truly excited.

Developers of platforms and libraries that use OpenAPI haven't had such a shake up before, and my feeling is it may take more than a few releases to correctly implement all the new shiny features full JSON Schema has to offer.

While the number of changes from JSON Schema draft-04 to draft 2020-12 are vast and the subject of more blog posts than are likely interesting, one of the key "features" of draft 2020-12 is a defined bundling process. (draft-04 is the version of JSON Schema that OAS used prior to version 3.1.0; or rather, a subset/superset of it.)

Indeed, bundling, if anything, is going to be more important to get right than ever. OAS 3.1 ushering in full JSON Schema support dramatically increases the likelihood that developers with existing JSON Schema documents will use them __by reference__ in new and updated OpenAPI definitions. Ultimate source of truth matters, and it's often the JSON Schemas.

Many tools don't support referencing external resources.
Bundling is a convenient way to package up schema resources spread across multiple files in a single file for use elsewhere, such as an OpenAPI document.

## Existing solutions? New solutions!

There are several libraries which offer bundling solutions, however they all have caveats, and I haven't seen any to date which are fully JSON Schema aware. The most popular of these libraries is called `json-schema-ref-parser`, however it [reports](https://github.com/APIDevTools/json-schema-ref-parser/issues/97#issuecomment-415963663) that it was not intended to be JSON Schema aware, and is only intended to cover the JSON Reference specification (Which has been bundled back into the JSON Schema specification now).

We are hoping to provide you with a canonical implementation (Right, Mike?!) and enough information to get started building your own in your language of choice. (Although, it's always best to read the full specification when developing implementations.)

## Bundling fundamentals

Firstly, let's visit some key definitions in JSON Schema draft 2020-12.
The `$id` keyword is used to identify a "schema resource". In the example below, the `$id` is `https://jsonschema.dev/schemas/mixins/integer` for the resource.

```json
{
  "$id": "https://jsonschema.dev/schemas/mixins/integer",
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "description": "Must be an integer",
  "type": "integer"
}
```

A "Compound Schema Document" is a JSON document which has multiple embedded JSON Schema Resources. Below is a simplified example of one we’ll unpack a bit later.

```json
{
  "$id": "https://jsonschema.dev/schemas/examples/non-negative-integer-bundle",
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "description": "Must be a non-negative integer",
  "$comment": "A JSON Schema Compound Document. Aka a bundled schema.",
  "$defs": {
    "https://jsonschema.dev/schemas/mixins/integer": {
      "$schema": "https://json-schema.org/draft/2020-12/schema",
      "$id": "https://jsonschema.dev/schemas/mixins/integer",
      "description": "Must be an integer",
      "type": "integer"
    },
    "https://jsonschema.dev/schemas/mixins/non-negative": {
      "$schema": "https://json-schema.org/draft/2020-12/schema",
      "$id": "https://jsonschema.dev/schemas/mixins/non-negative",
      "description": "Not allowed to be negative",
      "minimum": 0
    },
    "nonNegativeInteger": {
      "allOf": [
        {
          "$ref": "/schemas/mixins/integer"
        },
        {
          "$ref": "/schemas/mixins/non-negative"
        }
      ]
    }
  },
  "$ref": "#/$defs/nonNegativeInteger"
}
```
> Note that schema bundling and the use of multiple definitions are not necessary to represent non-negative integers.
> This example is purely for illustrative purposes and the schema below is perfectly suitable for representing non-negative integers without the use of bundling.
> ```json
> {"type": "integer", "minimum": 0}
> ```

Last, let's look at the carefully crafted definition of "bundling" according to the JSON Schema specification:

"The bundling process for creating a Compound Schema Document is
   defined as taking references (such as "$ref") to an external Schema
   Resource and embedding the referenced Schema Resources within the
   referring document.  Bundling SHOULD be done in such a way that all
   URIs (used for referencing) in the base document and any referenced/
   embedded documents do not require altering."

With these definitions in mind, now we can look at the defined bundling process for JSON Schema resources! We will only cover the ideal situation in this article. The goal here is to have no external Schema Resources.

Note, this article does NOT cover "total dereferencing", which is removing all uses of `$ref` from a schema. This is not advised, and is not always even possible, such as when there are self references.

## Bundling Simple External Resources

In our first example, we have an ideal situation for bundling. Each schema has an `$id` and `$schema` defined, making the bundling process simple.
We'll cover various other situations and edge cases in further examples, but having each resource define its own identity and dialect is always preferable.
Our primary schema resource references two other schema resources using the in-place applicator `$ref` with the value being a relative URI. The relative URI is resolved against the base URI, which in this instance is found in the primary schema resource's `$id` value. By combining "integer" and "non-negative" schemas, we create a "non-negative integer" schema.

```json
{
  "$id": "https://jsonschema.dev/schemas/mixins/integer",
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "description": "Must be an integer",
  "type": "integer"
}
```

```json
{
  "$id": "https://jsonschema.dev/schemas/mixins/non-negative",
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "description": "Not allowed to be negative",
  "minimum": 0
}
```

```json
{
  "$id": "https://jsonschema.dev/schemas/examples/non-negative-integer",
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "description": "Must be a non-negative integer",
  "$comment": "A JSON Schema that uses multiple external references",
  "$defs": {
    "nonNegativeInteger": {
      "allOf": [
        {
          "$ref": "/schemas/mixins/integer"
        },
        {
          "$ref": "/schemas/mixins/non-negative"
        }
      ]
    }
  },
  "$ref": "#/$defs/nonNegativeInteger"
}
```

Should "non-negative-integer" schema be used as the primary schema in an implementation, the other schemas would need to be available to the implementation. At this point, exactly how that implementation loads in the schemas doesn't matter, as they have fully qualified URIs as their identity defined in `$id`. Any implementation that loads in schemas should build an internal local index of schema URIs defined in `$id` to schema resources.

Remember, any schema which provides a value for `$id` is considered a Schema Resource.

Let's resolve (dereference) one of the references in our primary schema. `"$ref": "/schemas/mixins/integer"` resolves to a fully qualified URI of `https://jsonschema.dev/schemas/mixins/integer` by following the rules for first determining the base URI and then resolving the relative URI against that base URI. The implementation should then check its internal index of schema identifiers and schema resources, finding a match, and using the appropriate previously loaded schema resource.

The bundling process is done. The previously externally referenced schemas are copied into `$defs` in our primary schema, as is. The keys for the `$defs` object are the identifying URIs, but they can be anything, as those values won't be referenced (They could be UUIDs if you like). Looking at our final bundled schema… I mean "Compound Schema Document", we now have multiple Schema Resources embedded in a single Schema document.

```json
{
  "$id": "https://jsonschema.dev/schemas/examples/non-negative-integer-bundle",
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "description": "Must be a non-negative integer",
  "$comment": "A JSON Schema Compound Document. Aka a bundled schema.",
  "$defs": {
    "https://jsonschema.dev/schemas/mixins/integer": {
      "$schema": "https://json-schema.org/draft/2020-12/schema",
      "$id": "https://jsonschema.dev/schemas/mixins/integer",
      "description": "Must be an integer",
      "type": "integer"
    },
    "https://jsonschema.dev/schemas/mixins/non-negative": {
      "$schema": "https://json-schema.org/draft/2020-12/schema",
      "$id": "https://jsonschema.dev/schemas/mixins/non-negative",
      "description": "Not allowed to be negative",
      "minimum": 0
    },
    "nonNegativeInteger": {
      "allOf": [
        {
          "$ref": "/schemas/mixins/integer"
        },
        {
          "$ref": "/schemas/mixins/non-negative"
        }
      ]
    }
  },
  "$ref": "#/$defs/nonNegativeInteger"
}
```

When the bundled schema is initially loaded and evaluated, the implementation should create its own internal index of schema identifiers and schema resources, just as before. The relative URIs used to reference those schema resources need not change.

The simplest way to see this bundled schema working as expected is to paste it into https://json-schema.hyperjump.io and then try different values for the instance. I'm hopeful to bring several updates to https://jsonschema.dev over the next few months, but times are busy as we continue to elevate JSON Schema as an organisation.

It’s worth remembering that the example in this article shows the ideal situation, when best practices have been followed. The JSON Schema specification does define additional processes for non-ideal situations and edge cases (such as when `$id` or `$schema` are not set), however, some solutions may be indirectly related to Compound JSON Schema Documents. For example, establishing the base URI follows the steps laid out in RFC3986, which JSON Schema does not redefine.

## OpenAPI Specification Example

Let’s look at an example of how this might work with an OpenAPI definition.

```yaml
openapi: 3.1.0
info:
  title: API
  version: 1.0.0
components:
  schemas:
    non-negative-integer:
      $ref: 'https://jsonschema.dev/schemas/examples/non-negative-integer'
```

We start with our input OpenAPI 3.1.0 specification document. For brevity, we’re only showing the components section with a single component, but let’s assume some other part of the document uses the component schema “non-negative-integer”.

“non-negative-integer” has a single reference to a JSON Schema resource. The reference URI is an absolute URI, including domain and path, meaning there’s no need to do any “resolve the relative URI against the base URI” dance.

All the schemas required to resolve and bundle the reference are provided to the bundling tooling. After the schemas are loaded into the implementation, their originating physical location no longer matters.

```yaml
openapi: 3.1.0
info:
  title: API
  version: 1.0.0
components:
  schemas:
    # This name has not changed, or been replaced, as it already existed and is likely to be referenced elsewhere
    non-negative-integer:
      # This Reference URI hasn't changed
      $ref: 'https://jsonschema.dev/schemas/examples/non-negative-integer'
    # The path name already existed. This key doesn't really matter. It could be anything. It's just for human readers. It could be an MD5!
    non-negative-integer-2:
      $schema: 'https://json-schema.org/draft/2020-12/schema'
      $id: 'https://jsonschema.dev/schemas/examples/non-negative-integer'
      description: Must be a non-negative integer
      $comment: A JSON Schema that uses multiple external references
      $defs:
        nonNegativeInteger:
          allOf:
          # These references remain unchanged because they rely on the base URI of this schema resource
          - $ref: /schemas/mixins/integer
          - $ref: /schemas/mixins/non-negative
      $ref: '#/$defs/nonNegativeInteger'
    integer:
      $schema: 'https://json-schema.org/draft/2020-12/schema'
      $id: 'https://jsonschema.dev/schemas/mixins/integer'
      description: Must be an integer
      type: integer
    non-negative:
      $schema: 'https://json-schema.org/draft/2020-12/schema'
      $id: 'https://jsonschema.dev/schemas/mixins/non-negative'
      description: Not allowed to be negative
      minimum: 0
```

The schemas are inserted into the `components/schemas` location of the OAS document. The keys used in the `schemas` object have no importance for reference resolution, although you will want to avoid potential duplications. References need not change, and a processor of the resulting bundled or Compound Document, should look for the use of embedded Schema Resources within the OAS document, keeping track of the `$id` values.


## But what about...

The astute among you might have noticed that Compound Documents may not be correctly validated using a meta-schema for the dialect defined at the document root. One of our principal contributors distilled a great explanation which he has agreed to let us share with you.

“*If an embedded schema has a different `$schema` than the parent schema, then a Compound Schema Document can't be validated against a meta-schema without deconstructing it into separate schema resources and applying the appropriate meta-schema to each. That doesn't mean the Compound Schema Document is not usable without deconstruction, it just means that implementations need to be aware that the `$schema` can change during evaluation and handle such changes appropriately.*” - Jason Desrosiers.

If you’d like a more in-depth look at edge case situations, please do let us know.

You can reach out to us [@jsonschema](https://twitter.com/jsonschema) or our [Slack server](/slack).

*I hope you’ll agree, Ben has clarified the process for us all here, and we can use this example to fully meet JSON Schema’s bundling expectations when writing tools which bundle multiple resources into compound OpenAPI documents. Thanks, Ben!* - Mike

<a href="https://www.freepik.com/vanitjan1">Business photo created by vanitjan - www.freepik.com</a>

This article was first published on the JSON Schema Blog and is canonically located at https://json-schema.org/blog/posts/bundling-json-schema-compound-documents


Mike Ralphson

JSON Schema bundling finally formalised


If the JSON Schema project had a Code of Conduct in the early days, I suspect we would be years ahead of where we are today. It may seem unlikely, and you may feel like you rarely see a code of conduct in action, but having a Code of Conduct lays some foundational expectations from contributors. You could argue that you shouldn't NEED a Code of Conduct, that people should use common sense and be nice... but it's not so clear cut. Let me explain.

## My culture is not your culture

Star Trek fans will no doubt be well aware of the "Prime Directive". For the rest of us, the Prime Directive is a top priority general order to not interfere with other cultures and civilizations. The theory goes, humans are more likely to have a disastrous effect regardless of the intent because cultures can be very different.

While the failure of an open-source project is unlikely to cause the collapse of another civilization in our reality, the general principle still applies; You cannot presume to know the culture of others. What is normal or acceptable in one culture is not in another.

How do these concepts translate from fiction to reality? While there are many extreme examples, one TV advert always stuck with me as a good example of cultural differences causing undesirable results.

The advert depicts an English man sitting down for a meal with 10 or so Chinese businessmen. The English man orders an eel, possibly by mistake as he looks worried, but eats the whole thing. The voiceover says, "The English believe it's a slur on your host's food if you don't clear your plate, whereas the Chinese feel you're questioning my generosity if you do." The restaurant brings out another eel, this time much larger.

This advert was one of a series published for HSBC, highlighting the importance of "local knowledge". While it makes a nice soundbite, it is a good demonstration of different cultural norms and expectations.

## Communication is mostly non-verbal

Avoiding cultural clashes is even harder when using mostly text to communicate. Experts estimate that only 7% of how we communicate is by using the meaning of the words we use. That leaves 93% attributes to tone and body language. Wow.

When you communicate through text with people you usually communicate with in person, it's usually not difficult to fill in for the lack of tone. But, when you've never met or seen the person you're interacting with, you have no reference or basis to make assumptions. What sometimes happens is we fill in those missing parts to draw our own conclusions, which may not match the intent.

So how should an open-source project on GitHub avoid cultural clashes and misunderstandings?

Emojis can help increase the likelihood of understanding the correct intent, as they can convey tonal and emotional implications. Increasing the level of understanding and intent certainly helps avoid misunderstandings, but this isn't always going to help with cultural differences.

## Our culture and colloquial language

It's easy to forget how much culture affects how we interact every day. "Shaka, when the walls fell." You might recognize this as a quote from StarTrek. Imagine you land on a planet and you have a universal translator, but the words just don't make any sense. In this fictional situation, the alien language only uses colloquialisms; phrases that have meaning beyond the words used.

We find colloquialisms in one language which are nonsensical to most others. Many of you will find yourself part of various internet cultures, and these too will have their own colloquialisms. With images being a way we can communicate online, we've built visual colloquial language, which we call memes.

What I'm implying here is that we can, and do, create our own cultures, and that's OK. We as JSON Schema chose to adopt the Contributor Covenant for [several reasons](https://github.com/json-schema-org/community/blob/main/docs/adr/2021-08-26-code-of-conduct.md), and this sets our cultural tone. It defines how we should interact, and what our expectations should be when we interact. In addition to the Contributor Covenant, we continue to keep the IETF Guidelines for Conduct (BCP 54), creating our own Code of Conduct.

## Why a Code of Conduct?

We've explored that cultural differences can make it hard to understand intent. But, even if the intent is clear, sometimes specific conduct can be unwelcome.

With open-source, people come and go. The people who were super helpful today may be busy tomorrow... or de-prioritise a specific project for years. Aside from making people feel welcome to be nice, it makes good sense in terms of developing and maintaining the project long term. People are more likely to stay if they continue to feel welcomed and valued.

Some get involved because it's their job, some because it's fun and rewarding. Some are lucky enough to be able to combine those two aspects. But whatever your reason, we want open source to be a positive experience.

While I often suggest people avoid making assumptions, when your communication is limited, you have to make some assumptions or ask for clarification. However, a Code of Conduct allows you to frame your interactions with expectations. "If a comment reads bad, but I assume their intent was good, can I understand the likely meaning differently?"

Beyond setting the expectations of good interactions, there is conduct we (agreeing with the Contributor Covenant) defined as not acceptable such as public or private harassment. While it's hard to imagine a culture where that would be acceptable, there are some cultural norms and expectations that are totally unacceptable in many cultures.

The Contributor Covenant makes clear the expectations in the form of a pledge and provides examples of meeting those expectations, but it doesn't give any specific hard rules for working (how to do "business"). CBP 54 does give some clear expectations, such as how we should work: "We dispute ideas by using reasoned argument rather than through intimidation or personal attack."

We feel the combination we presented and agreed upon in full view and comment from the community aligns with our expectations, and we hope you agree. If that changes or your opinions differ, we will gladly hear them, and try to understand. This is part of what consensus building looks like, some of which is set out in CBP 54.

Our choice for the Code of Conduct was partly based on the document's reputation and existing usage. The Contributors Covenant has been adopted by many projects and organizations and has undergone several revisions. It has been developed and updated by many with much experience and knowledge of code of conducts, which is something we can't say for anyone in our team.

## What if we just... did nothing?

Without getting too philosophical, humans seem to often find conflict even when full communication is possible. It's almost inevitable that with text-only communication, there are going to be some misunderstandings, and that drives conflict.

JSON Schema as a project previously stalled because the core team (as much as I can tell) had [differing expectations](https://github.com/json-schema/json-schema/issues/52). Discussions got heated. Tempers were raised. There was no default laid expectation to frame potential misunderstandings. There was no framework for resolving or remediating conflicts.

Right now, there is a fair amount of fragmentation of JSON Schema tooling and version support. We are actively trying to help ease the issue, but my feeling is this only came about where the specification development stopped. If it had continued, and those projects and tools had been supported, we might have found ourselves in an easier situation.

We've lost knowledge. We're trying to capture knowledge and decision reasoning moving forward, but there are some things we just simply don't know, and likely now never will. Key people of the previous team that worked on JSON Schema seem to have stepped away from any public open-source work. It may be a coincidence, but based on very public arguments, I suspect not.

When we frame our interactions with expectations, we give the benefit of the doubt. With an increasingly wide user base, we have to expect contributors may not have English as their first language, making graceful interpretation increasingly important.

One strength of JSON Schema is the ability to use any compliant implementation, and swap out one for another with minimal effort if needed. Do others need to use the schema in another programming language? No problem. That's great for validation, but what about generating types or classes? What about UI generation and database generation? What about generating documentation?

Having fixed many problems and inconsistencies, developed many new features, and re-established active development of JSON Schema, the legitimacy and trust of the project are growing. We are now interacting with and guiding several initiatives to define standardized extensions to JSON Schema. Standardized to ensure interoperability.

As our community grows, so must our approach with which we engage with our community, and our expectations. Establishing a Code of Conduct is just one of several initiatives that seek to elevate JSON Schema from being an unsung silent hero, into the legitimate, established, and well used critical standard we know it can be. We must learn from our history if we don't want to repeat its mistakes.

## How do I get involved?

We recently updated our homepage to include a few links to our active community and regular activities, but let's recap here anyway.

The majority of our discussions happen on our [open slack server](https://json-schema.org/slack). Our general channel is for all discussions, including those looking for help. We have other channels for specification development and implementers, the official test suite, even for monitoring GitHub and StackOverflow activity. It's our central hub. But, it is ephemeral, and we lose access to older messages (a limitation of the free account).

The more long-living and searchable location for activity and discussion is now our [GitHub Discussions](https://github.com/json-schema-org/community/discussions). Currently, these are limited to our community repository, but we plan to open these up across other repositories later.

Currently, there are two sets of regular calls we hold.

First is our [JSON Schema Office Hours](https://github.com/json-schema-org/community/discussions/34); an hour every week at the same time where anyone can come and ask questions or just discuss anything JSON Schema related. It has seen low traffic, but it sends an important signal to our community: "We're here to help you as much as we can." Every Tuesday at 15:00 UTC.

Second is our [Open Community Working Meetings](https://github.com/json-schema-org/community/discussions/35). For these we alternate between times; First Friday of the month at 20:00 UTC, third Friday of the month at 14:00 UTC. This enables the calls to be open to a broader audience. These meetings have a semi-formal agenda and serve as a call to action to gather feedback and thoughts on key decisions and to progress work that needs to be done. We always make sure we capture the resulting action items and follow up in the next session.

Both sets of calls are open for anyone to join. Both are recorded, but only the Open Community Working Meeting is shared publicly. The Office Hours session is not shared, hopefully allowing people to speak more freely.

Besides Slack, GitHub Discussions, and regular meetings, we do make use of Twitter. You can find me running the [@jsonschema account](https://twitter.com/jsonschema). Any mention of "JSON Schema" feeds into a channel on Slack, so we see most of the discussion, and can lend a hand or point people in a direction as appropriate.

Hopefully, this has been a helpful look at why JSON Schema specifically needs a Code of Conduct. Maybe you're considering if your project needs a Code of Conduct. If you have any questions, thoughts, or comments as a result of this article, please feel free to use any of the above methods to make contact.

Image by <a href="https://pixabay.com/users/broesis-5213623/?utm_source=link-attribution&amp;utm_medium=referral&amp;utm_campaign=image&amp;utm_content=2366955">Maike und Björn Bröskamp</a> from <a href="https://pixabay.com/?utm_source=link-attribution&amp;utm_medium=referral&amp;utm_campaign=image&amp;utm_content=2366955">Pixabay</a>

Why JSON Schema needs a Code of Conduct


## Challenge

Cookpad Mart is one of the new businesses that Cookpad Inc. is focusing on. It is an e-commerce platform that mainly deals with fresh food, and retailers in the city and local producers participate in Cookpad Mart as sellers. Dedicated refrigerators are installed as pick-up locations for users in various places such as convenience stores, drug stores, train stations, and condominiums. Users can place orders from the app and receive fresh food from the refrigerator.

Cookpad Mart was developing a management screen for sellers that provided functions for sellers to register products and perform daily shipping operations.

"It is necessary to enter different types of data depending on the type and state of the product, but which information should be manually entered from the form in which all items are listed? It is very difficult to judge each time," says Kenshi Shiode, Engineer, Cookpad Mart Team. There was a need for a mechanism to sort out appropriate forms according to the type and condition of the product.

In addition, it is not possible to completely prevent the registration of invalid data simply by controlling the distribution of forms on the front-end.
Although in-house operation members perform product screening before the product starts selling, it is desirable that the product is registered after being validated on the back-end side in order to avoid the burden of product screening and mistakes.

## Solution

The team considered using custom code to generate complicated forms, but were concerned about consistent validation in the browser and on the server side. In looking to create a common Schema, JSON Schema was chosen as the mechanism. "We decided to introduce JSON Schema as a mechanism that can separate and validate complicated forms," says Kenshi.

## Impact

JSON Schema has improved the accuracy and experience when registering products, and has greatly reduced the operational burden of product screening.

Using JSON Schema has reduced the burden of changing requirements. "Even if new requirements increase in the future, it can be solved by simply updating the JSON Schema definition, and validation of the form distribution control logic on the front-end side and validation on the back-end side can be easily performed," says Kenshi.

## Key Impact Results

<Bigquote>
  From 10% of submissions being deficient, to zero.
</Bigquote>

"Previously, about 10% of newly registered products had incomplete input of quality assurance items, but with the introduction of JSON Schema, there are no deficiencies in the quality assurance items," says Kenshi.

## About Cookpad Inc.

<p className="text-2xl my-10">Cookpad is a global recipe sharing platform, boasting an average of 100 million people every month across the world, spanning 76 countries, supporting 34 languages, and boasting more than 5.5 million shared recipes. It is the largest recipe sharing service in Japan.</p>

<div className="container flex flex-col sm:flex-row sm:space-x-4 space-y-4 sm:space-y-0 place-content-between">
  <figure className="group m-auto">
    <img className="flex-1" src="/img/posts/2021/cookpad-case-study/fridge.webp" />
    <figcaption className="absolute text-2xl -mt-9 px-4 bg-gray-600 bg-opacity-50">
        <span className="text-white">Cookpad Mart Fridges</span>
    </figcaption>
  </figure>
  <figure className="group m-auto">
    <img className="flex-1" src="/img/posts/2021/cookpad-case-study/office.webp" />
    <figcaption className="absolute text-2xl -mt-9 px-4 bg-gray-600 bg-opacity-50">
        <span className="text-white">Cookpad Offices</span>
    </figcaption>
  </figure>
</div>

As a tech company, they work to "make everyday cooking fun". They believe that cooking is the key to a happier and healthier life for people, communities and the planet. Providing easier access to fresh quality ingredients enables better cooking, which is where Cookpad Mart has an impact.

"Delicious things while they are delicious" is one of the primary thoughts of Cookpad Mart, looking to connect customers more directly with producers. Fresh ingredients, recommendations, and recipes, make for an appealing proposition. "The crispy and elastic texture and the dripping milky texture are the real pleasures of fresh mozzarella," reads one example product.

High quality ingredients that come from small producers tend to be difficult to find in the general market, making the most sensible approach to be mostly self-service listing. While Cookpad Mart operates in a limited area for now, the ability to scale and reduce manual review and approval is important, in addition to enabling customers to get the freshest ingredients.

## Benefits in development

"We thought that we should use the same logic for backend and frontend applications. At first we thought about creating our own custom JSON Structure, but we had to write many `if` statements, and I do not want to imagine!"

<Bigquote>
"JSON Schema helps us to implement backend validation and frontend form generation easily. It was quite an excellent experience!" explains Kenshi, estimating that time spent building validation has been cut in half as a result of using JSON Schema.
</Bigquote>

One mantra developers often hear is DRY: 'don't repeat yourself'. "We could focus ONLY on JSON Schema definitions and everything has been automatically generated and applied," says Kenshi, "That was an excellent moment." Reducing duplication of logic reduces the likelihood of a mismatch in expectations between the client and server side.

While AI is often compared to many `if` statements, experienced application developers usually seek to reduce complexity and therefore risk. Reducing complexity by removing many conditional blocks has made code reviews easier, and even had a positive impact on continuing maintenance tasks. "Engineers would like to reduce "if" statements as much as possible I think," quips Kenshi.

Many JSON Schemas we see are kept quite simple, but there's a lot of power on offer for those willing to read the documentation. "I was really astonished with the vocabulary of JSON Schema," Kenshi continues, "There are not only simple expressions like type and length, but also complex expressions like `oneOf` and even `If-Then-Else`."

Conditional validation is new when you consider the long life of JSON Schema. Once you unlock the understanding of the multiple approaches to applying subschemas, composition can be satisfying and powerful. "When I found the rich vocabulary prepared by JSON Schema, I felt confident to use JSON Schema. Very nice!" We happen to agree, Kenshi!

Thank you to Kenshi Shiode, Engineer, and Cookpad, for allowing and enabling us to share this case study with you.

Note:
Some parts of this case study are originally located in a blog posting by Cookpad, located at https://techlife.cookpad.com/entry/mart-json-schema. Used with permission.


JSON Schema deduplicated complex logic and validation at Cookpad


## 挑戦

クックパッドマートとは、クックパッド株式会社が力を入れて取り組んでいる新規事業のひとつです。生鮮食品を中心として扱っているECプラットフォームで、街の食材専門店や地域の生産者が、販売者としてクックパッドマートに参加しています。コンビニエンスストア・ドラッグストア・駅・マンションなどの様々な場所に、ユーザーの受け取り場所として専用の冷蔵庫が設置されています。ユーザーはアプリから注文を行い、冷蔵庫から生鮮食品を受け取ることができます。

クックパッドマートでは、販売者が商品の登録や日々の出荷作業などを行うための機能を提供する販売者向け管理画面を開発しています。

「商品の種類や状態によって異なる種類のデータを入力する必要がありますが、全項目が羅列されるフォームから適切な項目の入力を都度行うことはとても難しい状態でした。」とクックパッドマートの開発に携わっているエンジニアの塩出さんは語ります。商品の種類や状態に応じて、適切なフォームが出し分けされる仕組みが求められていました。

また、フロントエンド側でフォームの出し分け制御がされるだけでは、不正なデータの登録を完全に防ぐことはできません。社内の運用メンバーが商品の販売開始前に審査を行っていましたが、商品審査の負担やミスを避けるために、バックエンド側でバリデーションされた上で商品が登録されることが望ましい状態でした。

## 解決策

開発チームでは、独自のコードを使用して複雑なフォームを生成することも検討しましたが、フロントエンドとバックエンドでのバリデーションの一貫性について懸念していました。そこで、共通の定義を作成するために、JSON Schemaが仕組みとして選択されました。「複雑なフォームをバリデーションできる仕組みとしてJSON Schemaを導入することにしました。」と塩出さんは言います。

## 結果

JSON Schemaにより、商品登録時の正確性や体験が改善され、商品審査にかかる運用の負担が大幅に軽減されました。

また、JSON Schemaを利用することで、要件の変更に対して柔軟に対応することができるようになりました。「今後新しい要件が増えても、JSON Schemaの定義を更新するだけで解決し、フロントエンド側のフォームの出し分け制御ロジック・バックエンド側のバリデーションを容易に追加・更新することが可能な状態になりました。」と塩出さんは言います。


## 主な成果

<Bigquote>
品質保証に関する入力不備が10％から0％に
</Bigquote>


主な成果として「以前は、新規登録商品の約10％で品質保証の項目の入力不備がありましたが、JSON Schemaの導入により、品質保証の項目の入力不備はほぼゼロになりました。」と塩出さんは言います。

## クックパッド株式会社について

<p className="text-2xl my-10">クックパッドは、クックパッド株式会社がグローバルに展開している料理レシピ投稿・検索サービスです。世界の76か国で毎月平均1億人のユーザー数を誇り、34の言語をサポートし、日本では550万件以上のレシピが共有されている国内最大のレシピサービスです。</p>

<div className="container flex flex-col sm:flex-row sm:space-x-4 space-y-4 sm:space-y-0 place-content-between mb-6">
  <figure className="group m-auto">
    <img className="flex-1 " src="/img/posts/2021/cookpad-case-study/fridge.webp" />
    <figcaption className="absolute text-l -mt-6 px-4 bg-gray-600 bg-opacity-50">
        <span className="text-white">クックパッドマートの冷蔵庫</span>
    </figcaption>
  </figure>
  <figure className="group m-auto">
    <img className="flex-1" src="/img/posts/2021/cookpad-case-study/office.webp" />
    <figcaption className="absolute text-l -mt-6 px-4 bg-gray-600 bg-opacity-50">
        <span className="text-white">クックパッド株式会社のオフィス</span>
    </figcaption>
  </figure>
</div>

テクノロジー企業であるクックパッド株式会社は、「毎日の料理を楽しみにする」というミッション実現に向けて様々な事業に取り組んでいます。料理は、人・地域社会・地球での生活に幸せと健康をもたらす大事なものであると考えています。クックパッドマートでは、新鮮で高品質の食材を手軽に入手できるようにすることで、料理をより良い体験にすることができると考えています。

「おいしいものを新鮮なうちに」は、クックパッドマートの指針のひとつであり、ユーザーと生産者をより直接的に結び付けることを目指しています。新鮮な食材、おすすめを紹介する特集やレシピなど、ユーザーへ魅力的な提案をしています。代表的な商品のひとつには「キシっとした弾力ある食感とジュっと滴るミルク感は、フレッシュなモッツァレラならではの醍醐味です。」と記載されています。

クックパッドマートは現在限られた地域でのみサービス展開されていますが、ユーザーが新鮮な食材を入手できるようにする仕組みだけでなく、事業規模の拡大に向けて、商品のひとつひとつの審査・承認にかかる運用コストの削減も重要です。


## 開発でのメリット

「バックエンドとフロントエンドのアプリケーションに同じロジックを使用する必要がありました。最初は独自のJSONフォーマットの作成を考えましたが、多数の`if`文を自分たちで作成する必要が出てくるため、避けたいと思っていました。」

<Bigquote>
"「JSON Schemaのおかげで、バックエンド側でのバリデーションとフロントエンド側のフォーム生成をとても簡単に実装することができました。とても素晴らしい体験でした！」と塩出さん。JSON Schemaを使用した結果、バリデーションおよびフォームの実装にかかる時間が半分以下で済んだ、と見積もっています
</Bigquote>

開発者はDRY「Don't repeat yourself」という言葉をよく耳にします。「JSON Schemaの定義の構築のみに集中できました。その後は、JSON Schemaをサポートするライブラリによって、ほぼ全てが自動生成されました。最高の瞬間でしたね！」と塩出さんは語ります。ロジックの重複を減らすことで、フロントエンドとバックエンドの間で実装の不一致が起こりにくくなります。

AIは多数の`if`文と比較されることがよくありますが、経験豊富なアプリケーション開発者は複雑さを軽減し、リスクを軽減しようとすることが多いです。多くの条件付きブロックを削除して複雑さを軽減することでコードレビューが簡単になり、継続的なメンテナンスタスクにもプラスの影響を与えました。「多くのエンジニアは`if`文を必要最小限に減らしたいのではないでしょうか。」と塩出さんは言います。

私たちが目にする多くのJSON Schemaはとてもシンプルなものですが、ドキュメントを読む人に多大なる力を与えます。「JSON Schemaの構文の種類には本当に驚きました。型や文字列長などの単純な制約だけでなく、`oneOf`や`If-Then-Else`などの複雑なものもありました。」と塩出さんは続けます。

JSON Schemaはかなり前からありますが、条件付きのバリデーションはまだ新しいものです。あるデータ構造の制約を定義するために、複数のアプローチが存在することを理解できるようになると、JSON Schemaはより強力なものになります。「JSON Schemaの豊富な表現力を見つけたとき、JSON Schemaを自信を持って使うことができました。すごく良かったです！」塩出さん、本当にその通りです！

JSON Schemaの活用事例の紹介に協力してくださった、エンジニアの塩出さんおよびクックパッド株式会社に深く感謝いたします。

注：
本事例紹介の一部は、https://techlife.cookpad.com/entry/mart-json-schema にあるクックパッド株式会社による開発者ブログから許可を得て引用しています。


クックパッド株式会社におけるJSON Schemaの活用事例


> Originally published at [simonplend.com](https://simonplend.com/get-started-with-validation-in-node-js/).

The first step in putting together request validation for your Node.js application is finding a way to create flexible validation rules. When you try to pick a validation library to use, it's often more difficult than you expect. They're all different from each other, and it's not clear what benefits one has over another.

Perhaps you've tried to build your own custom validation before, but it starts to feel messy and difficult to maintain. You want to put some reliable validation in place and move on to building exciting new features in your application. Why is adding in validation *such* a headache?!

In this article, we're going to learn how the JSON Schema specification can help us create flexible validation rules. We'll write a schema which describes the format we expect data to be in, then we'll write some JavaScript that uses the Ajv validator library to validate our data against it.

Let's get started!

## A powerful validation duo

The [JSON Schema specification](/specification) defines a JSON-based format for describing the structure of JSON data. This includes validation keywords, such as `type`, `required` and `properties`. These keywords allow us to create a definition of the format we expect data to be in. This is a "schema". It can be as simple as:

```json
// props { "isSchema": true }
{ "type": "string" }
```

To validate data against a schema, we need to use a validator library which implements the JSON Schema specification. The [Ajv (Another JSON Schema Validator)](https://ajv.js.org/) library is the most popular JSON Schema validator for client and server side JavaScript, downloaded over [50 million times every week](https://www.npmtrends.com/ajv) from npm.

Let's get hands-on and see what validating data with JSON Schema and Ajv looks like.

> For a more detailed introduction to JSON Schema, check out the blog post [JSON Schema in 5 minutes](/blog/posts/json-schema-in-5-minutes).

## Creating a schema and validating data

First, we need to run the command `npm install ajv` to install the Ajv library.

Then we can jump straight into defining a JSON schema. It describes the structure and types we expect:

```javascript
const iceCreamSchema = {
  type: "object",
  properties: {
    flavour: { type: "string" },
    price: { type: "number" },
    stock: { type: "number" },
  },
  required: ["flavour", "price", "stock"],
};
```

Now we'll define the data which we want to validate:

```javascript
const iceCreamData = {
  flavour: "Pistachio",
  price: 1.99,
  stock: null,
};
```

Then we'll import the Ajv library and create a new Ajv instance:

```javascript
import Ajv from "ajv";

const ajv = new Ajv();
```

And use it to validate the data against our schema:

```javascript
const isDataValid = ajv.validate(iceCreamSchema, iceCreamData);
```

Lastly, we'll add some code to handle the validation results:

```javascript
if (isDataValid) {
  console.log("The ice cream data is valid! 🍨");
} else {
  console.error("The ice cream data is invalid:", ajv.errors);
}
```

When we put this code together and run it, we get the following output:

```
The ice cream data is invalid: [
  {
    instancePath: '/stock',
    schemaPath: '#/properties/stock/type',
    keyword: 'type',
    params: { type: 'number' },
    message: 'must be number'
  }
]
```

Pretty slick, huh?

Alright, we've created a schema which describes the structure and types we expect, validated data against it, and handled any validation errors. So far so good!

> A note from the editor: In the latest major release of AJV, a "strict mode" was introduced, enabled by default, which sometimes throws an exception when a valid JSON Schema is used. If you run into problems with strict mode related errors, check out [the documentation](https://ajv.js.org/strict-mode.html) for details on how to disable it, or even specific rules. We feel this may be better as linter functionality, however it does help prevent accidental errors in schema authorship. - Ben Hutton

As one final step, we'll look at how we can potentially improve the way we create our JSON schema.

## Schema generation

JSON schemas are an expressive way of defining validation rules, but writing schemas "by hand" can sometimes get a bit much. There's a handy library called [fluent-json-schema](https://npm.im/fluent-json-schema) which can help us generate our JSON schemas. Let's give it a try.

Note that while using a tool to define validaiton rules to be converted into a JSON Schema gives you control, other methods of generating JSON Schema, for example from your instance data, often leaves you with a partially complete or sometimes incorrect JSON Schema. Other approaches might be better called "scaffolding" rather than "generating", as you'll have the basics, but still have work to do before it's complete and useable.

First we need to install the library by running the command `npm install fluent-json-schema`. Then we can import it and use it to generate our schema:

```
import S from "fluent-json-schema";

const iceCreamSchema = S.object()
  .prop("flavour", S.string().required())
  .prop("price", S.number().required())
  .prop("stock", S.number().required())
  // This method call returns the generated schema as an object.
  .valueOf();
```

If we `console.log` the `iceCreamSchema` object, we can see the JSON schema we've generated:

```json
{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "type": "object",
  "properties": {
    "flavour": { "type": "string" },
    "price": { "type": "number" },
    "stock": { "type": "number" }
  },
  "required": ["flavour", "price", "stock"]
}
```

You'll notice this generated schema is almost identical to the `iceCreamSchema` we previously wrote "by hand". We can replace our handcrafted schema with this generated schema and the validation will behave in the same way as it did before.

If we're writing our applications in TypeScript, the [TypeBox](https://www.npmjs.com/package/@sinclair/typebox) library is a great alternative to `fluent-json-schema`.

Schema generation is down to your personal preference: some folks like to write raw JSON schemas "by hand", whereas others prefer to use a library which helps generate them. Try out both and pick whichever approach works best for you.

## Try it yourself

- **[Browse the code on GitHub](https://github.com/simonplend/creating-flexible-validation-rules)**
- **[Run the code in your browser with StackBlitz](https://stackblitz.com/github/simonplend/creating-flexible-validation-rules)** (works in Chrome, Edge or Brave browsers)
- **[Take on the validation coding challenge](https://github.com/simonplend/creating-flexible-validation-rules#ready-for-a-challenge)**! 🏆

## Wrapping up

We can use Ajv as a standalone library or we can integrate it with the framework we're using to build our Node.js application. Some Node.js frameworks even provide JSON Schema based validation with Ajv [built in](https://www.fastify.io/docs/latest/Validation-and-Serialization/).

When we combine JSON Schema and Ajv, we have a flexible solution for implementing validation in our Node.js applications:

- **Learn once, use everywhere.** The JSON Schema specification is cross-platform, and there are [validation libraries](/implementations) available for every popular programming language. We're not locked into a library, framework or language. Once we've learnt the fundamentals of JSON Schema, we can use it everywhere.
- **Portability.** Because JSON Schema is cross-platform, even if we decide to rewrite our applications in another framework or language, we can take our schemas with us.
- **Speed**. Under the hood, Ajv compiles our JSON schemas into JavaScript code. This improves the performance of repeated validation of data against a schema. For example, schemas can be compiled by Ajv when our Node.js application starts. HTTP request data which the application receives can then be validated against the pre-compiled schemas.
- **Active and supportive community**. There's an active community of folks on Slack who are happy to help out (the [JSON Schema website](https://json-schema.org/) has a link you can use to join).

### Further reading

If you'd like to learn more about JSON Schema, you might find these links helpful:

- **[How to handle request validation in your Express API](https://simonplend.com/how-to-handle-request-validation-in-your-express-api/)**. If you're using the Express Node.js framework, I wrote this guide to help you integrate the Ajv library into your applications.
- **[Fastify framework validation documentation](https://www.fastify.io/docs/latest/Validation-and-Serialization/)**. The Fastify Node.js framework integrates the Ajv library, making it straightforward to add validation with JSON Schema.
- **[Understanding JSON Schema](https://json-schema.org/understanding-json-schema/)**. A free online book which will teach you the fundamentals of JSON Schema. Also available in PDF format for offline reading.
- **[JSON Schema Cheat Sheet](https://simonplend.com/wp-content/uploads/2020/12/JSON-Schema-Cheat-Sheet-v1.1.pdf)**. I created this cheat sheet PDF as a handy reference for JSON Schema validation keywords. Use it to give you a helping hand any time you're writing schemas.

> Photo by [Manik Rathee](https://unsplash.com/@manikrathee) on [Unsplash](https://unsplash.com/photos/a8YV2C3yBMk).


Simon Plenderleith

Get started with JSON Schema in Node.js

Yanick Champoux

Astonishing Serializations & Schemas of Hyperborea


If you have never heard of JSON Schema till now, then you are in the right place to learn more.
If you are confident in using JSON Schema, this article still holds some value for you, and you'll likely still learn something new.

By the end of this article, you will:

- Understand what JSON Schema is
- Know what JSON Schema can do
- Understand some key terminology for talking about JSON Schema
- Know some of the basics of how JSON Schema works
- Outshine even those with years of JSON Schema experience (hopefully)

Although this is a technical introduction, we won't cover writing any code today. But we will link you to a list of implementations in almost any programming language.

## JSON What?
Primarily, JSON Schema is used to validate data.
The sorts of data JSON Schema can validate is data encoded in JSON.

JSON stands for JavaScript Object Notation and is a subset of Javascript.
JSON is both human and machine-readable, making it a popular format choice for data interchange.

JSON Schema is both the name given to the project and the artefact (A JSON Schema) that defines the required validation. The validation rules are expressed by defining constraints against the JSON data.

The JSON data you are validating is called a "JSON instance".

## JSON Schema
JSON Schema the project is located [on GitHub](https://github.com/json-schema-org) under the organization name "json-schema-org". It is comprised of several git repositories used to track changes and enable collaboration on the specification and supporting resources.

The JSON Schema specification is made up of technical specification documents currently published canonically through the Internet Engineering Task Force (IETF) as a series of "personal drafts". A "personal draft" is the category given to documents published on the IETF which are from an IETF working group.

A JSON Schema document is written in JSON itself. Being written in JSON means that it can be read by almost every programming language, making it an interoperable validation solution. It can also be written using other formats which translate to JSON, or using code that can serialize to JSON.

## A JSON Schema (document)
We mentioned JSON Schema is itself JSON. It used to be that JSON had to be an Object or an Array at the root level, but today, it can also be any of the allowed values.

A JSON Schema may be an Object or a Boolean. The Boolean form results in the same value as the validation assertion result. The Object form allows for keywords and values to express constraints for validation.

JSON Schema is constraints based, meaning that anything not defined (or constrained) is allowed and considered valid.

It may seem odd to allow Boolean values for a Schema, but we will explore why that's useful later. For now, let's look at our very first example Schemas.

## Introduction to constraints

```json
// props { "caption": "An empty Object"}
{}
```

```json
// props { "caption": "A \"true\" Boolean value"}
true
```

```json
// props { "caption": "A \"false\" Boolean value"}
false
```

```json
// props { "caption": "Not, empty Object"}
{ "not": { } }
```

Let's take each Schema in turn and explain the validation result.

The empty Object Schema expresses no constraints. Any instance data will always be considered valid.
The "true" Boolean Schema will always assert that the instance data is valid.

As you may have guessed, the inverse is true for the remaining two Schemas. The "false" Boolean Schema will always assert false, and the "Not, empty Object" Schema will have the same result.

The `not` keyword takes a JSON Schema as its value. These "schema values" are called subschemas. The subschema is applied to the instance data, and the resulting assertion is inverted. As we now know, the empty Object schema results in a "true" assertion, so the inverse is "false".

## The Object Schema
The keys in an Object Schema are the JSON Schema keywords. These keywords have four classes: Identifiers, Applicators, Assertions, and Annotations. Some keywords don't fit into these classes, as they have unique functions.

The `$schema` keyword has a unique function. The value of this keyword is a URI that identifies the JSON Schema Dialect to use when processing the schema.

You can think of a JSON Schema Dialect as a set of keywords with a defined meaning. In most cases, the different dialects you will deal with are merely different versions (or "drafts") of JSON Schema.

It is best practice to define the JSON Schema Dialect in use using the `$schema` keyword. In doing so, implementations should throw an error if they find a version of JSON Schema that they do not support.

If your Schema does not define the Dialect of JSON Schema it is using, implementations may pick any dialect. This may result in false positives when used with an implementation that does not support that version.

In this introduction, we will use the 2020-12 version of JSON Schema, however, most of what you will learn applies to almost all of the versions used in production today.

The 2020-12 JSON Schema Dialect URI is `https://json-schema.org/draft/2020-12/schema`.

## Assertions
Remembering that JSON Schema provides constraints based validation, JSON Schema defines keywords that, when applied to the instance, provide an assertion result (pass or fail).

### The "const" keyword

The simplest assertion keyword is `const`. The value can be any valid JSON. To pass validation data must be the same as the value of `const`. Here's an example:

```json
// props { "isSchema": true}
{ "const": 1234 }
```

```json
// props { "valid": true, "caption": "valid - It is exactly the same" }
1234
```

```json
// props { "valid": false, "caption": "invalid - It is not the same" }
"foobar"
```

### The "type" keyword

Another assertion keyword is `type`. Its value is an array of strings that are the allowed types. The types are the six primitive types defined by JSON, plus "integer". Let's look at an example.

```json
// props { "isSchema": true}
{ "type": ["object", "boolean", "null"] }
```

```json
// props { "valid": true, "caption": "valid - An Object is allowed." }
{ "ok": "yes" }
```
```json
// props { "valid": true, "caption": "valid - A Boolean is allowed." }
true
```
```json
// props { "valid": true, "caption": "valid - Null is allowed." }
null
```

```json
// props { "valid": false, "caption": "invalid - A Number is not allowed." }
123
```
```json
// props { "valid": false, "caption": "invalid - A string is not allowed." }
"foobar"
```

These two assertion keywords are applicable to ANY type of data in JSON, but some assertion keywords are only applicable to specific types. If a keyword is NOT applicable to the instance data, it is ignored and performs no validation.

### The "required" keyword

`required` is an assertion keyword that is only applicable for Objects. Let's explore the implications of this with some examples.

`{ "required": ["name"] }` - Our JSON Schema
`{ "name": "Bob" }` - valid - "name" is in the Object.
`{ "fullName": "Bob" }` - invalid - "name" is missing from the Object.
`"Bob"` - valid - The `required` keyword only applies to an Object.
`true` - valid - Same as above.

This may be surprising, but it allows for the composition of constraints that only logically otherwise make sense given a specific type of data.

You should combine using `type` with other keywords in the same Schema to avoid type expectation mismatch.

## Applicators

Validation begins by applying the root Schema to the complete instance document. Applicator keywords apply subschemas to the instance location.

### The "properties" keyword
The most commonly used applicator keyword is `properties`, which has an object value, where the values are subschemas. Let's see it in action.

```json
// props { "caption": "Our JSON Schema", "isSchema": true }
{
  "properties": {
    "name": {
      "type": ["string"]
    }
  }
}
```

```json
// props { "caption": "instance has name, which is a string", "valid": true }
{
  "name": "Alice"
}
```

```json
// props { "caption": "instance object has no `name` property", "valid": true }
{
  "fullName": "Alice"
}
```

```json
// props { "caption": "instance is not an object, therefore `properties` isn't applicable", "valid": true }
[ "name", 123 ]
```


The subschemas are only applied to the instance location where the key matches a key in the instance locations object.

If you want to make sure the instance data is an Object, use the `type` keyword.

If you want to make sure that the Object has the "name" property, use the `required` keyword.

## Recap
The most common reason a JSON Schema appears to not be working is the lack of the fully required constraints.

JSON Schema is "constraints based", and keywords may only be applicable to the correct data types.
Using multiple keywords to tighten constraints allows you to make sure type-specific keyword mismatch is handled by a different keyword.

Identifying subschemas, and knowing that Schemas can always be Boolean values allows you to confirm assumptions about correct applicability. Subschemas can always be tested on their own if required.

## Next steps / Further Reading
I hope you've found this very brief introduction to the fundamentals of JSON Schema beneficial in how you read, reason, and develop JSON Schemas.

My recommendation for writing JSON Schemas today is to use VSCode. When a file is in JSON language mode, and a `$schema` value is added to a root object, VSCode provides auto-complete and IntelliSense  (Although this is limited to draft-07).

Here are some places you may find helpful moving forward:

- [Up to date getting started guide](/learn/getting-started-step-by-step)
- [Weekly Office Hours (Tuesday, 15:00 UTC)](https://github.com/json-schema-org/community/discussions/34)
- [Open Community Slack Server](/slack)
- [Community GitHub Discussions](https://github.com/json-schema-org/community/discussions)
- [List of implementations](/implementations)
- [Human-friendly documentation for understanding JSON Schema](/understanding-json-schema)
- [JSON Schema live playground (ajv) for draft-07 with shareable links](https://jsonschema.dev)
- [JSON Schema live playground (hyperjump validator) for all drafts (from draft-04)](https://json-schema.hyperjump.io)
- [Links to RFC specification documents](/specification)

Photo by <a href="https://unsplash.com/@saadx?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Saad Salim</a> on <a href="https://unsplash.com/s/photos/construction?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Unsplash</a>


JSON Schema in 5 minutes


Joining Postman to work full time on JSON Schema has been a great move for me personally, and I feel for the JSON Schema project. Working full time on JSON Schema has been something I never expected, but I'm grateful and honoured to be able to do.

It's been almost a year, and one of the first meetings I organized was to chat with the OpenJS Foundation to learn more and discuss the potential for JSON Schema to join the foundation. That's why it gives me great pleasure to announce that JSON Schema has joined the OpenJS Foundation!

I'll give a few other small updates, but joining the OpenJS Foundation is our headline.

# Joining the OpenJS Foundation

The application to join could have been put in a year ago, but that wouldn't have been in line with the way we operate, and we wanted to do it right. JSON Schema works as a loose collective of individuals looking to form general consensus, and act accordingly.

There had long been a question over where JSON Schema would call home in terms of belonging to an organization. Would we formally join the IETF or the W3C, or maybe even some other open source / open standards organization? While myself and others had done some investigating and had a few calls, we were still unsure. We had made a few connections and could pick up threads again if required.

However, with the prospect of working on JSON Schema full time, I decided we should re-engage with the OpenJS Foundation. I wanted to provide confidence to the core team and community that JSON Schema would remain neutrally owned, and have an assurance of continuation should myself or others vanish from the space.

You can read my full proposal and report in a JSON Schema Community GitHub Discussion: https://github.com/json-schema-org/community/discussions/28

I primed the application, which was then reviewed and revised by the team and community. You can read the full application in our Community GitHub Repository: https://github.com/json-schema-org/community/blob/main/docs/openjsf/application.md


# OpenJS Foundation announcement

Here's the majority of the OpenJS Foundation announcement regarding JSON Schema joining the foundation. You can read the full announcement here: https://openjsf.org/blog/2022/01/31/json-schema-joins-openjs-foundation/

__JSON Schema is the newest technical project hosted under the OpenJS Foundation!__

JSON Schema is a vocabulary that allows you to annotate and validate JSON documents. It defines how a JSON should be structured, making it easy to ensure that a JSON is formatted correctly, and it is useful for automated testing and validating. In addition, JSON Schema provides clear human- and machine-readable documentation.

"We are thrilled to welcome JSON Schema into the OpenJS Foundation. Building a community requires dedicated people and great technology, which JSON Schema already has. It also requires a reliable structure for open governance and legal support that allows worldwide communities to grow. As the vendor-neutral home to almost 40 open source projects, JSON Schema already fits in well with our ecosystem of projects," said Robin Ginn, OpenJS Foundation executive director. "We look forward to providing resources and support to JSON Schema to help their community to grow."

"JSON Schema's supportive community has in part enabled us to get this far. This has been critical to its success. JSON Schema is primarily a validation tool, plus it's gaining additional uses such as generating forms, generating databases, or generating other UIs. We want to make sure the community and technology can continue to grow, possibly in unforeseen directions," said Ben Hutton, JSON Schema specification lead at Postman. "By joining the OpenJS Foundation, we gain the community structure and support - with a strong focus on open governance - to continue to build and enlarge the community. We remain committed to being an interoperability focused standard, and want to provide assurance that JSON Schema will remain open and owned by the community that needs it."

"The OpenJS Foundation continues to grow, and JSON Schema is a great addition. It is a key foundational technology, and by joining the OpenJS Foundation, it now has a strong home for further growth," said Todd Moore, OpenJS Foundation Board Chairperson and Chief Developer Advocate IBM. "We are looking forward to working with and supporting JSON Schema."

"The OpenJS Foundation is continuing to support key technologies that JavaScript communities rely upon. JSON Schema is an important addition," said Joe Sepi, Open Source Program Director at IBM, and chairperson of the OpenJS Foundation Cross Project Council." JSON Schema is a great example of how interconnected JavaScript technologies can be. Providing a structure for sharing data is critical."

"The Cross Project Council carefully considers the projects that join our neutral home at the OpenJS Foundation. We are pleased to have JSON Schema onboard so we can support the project's growth, and the maintainers can contribute their expertise to the broader JavaScript ecosystem through OpenJS," said Eemeli Aro, Staff Software Engineer at Mozilla, and OpenJS Cross Project Council (CPC) member.

JSON Schema will be designated "At-Large," which includes many different types of projects but is most often used for stable projects with minimal needs. They are now officially in the incubation process where projects complete their on-boarding to join the foundation.


# JSON Schema is hiring! (at Postman)

On joining Postman, one thing we discussed is the potential to bring on more people to work on JSON Schema full time. While JSON Schema currently does not provide or maintain any software as such, that could change.

In the immediate future, we're looking to hire for Software Engineer and for Technical Community Manager / Developer Relations roles.

Here are the roles and application links!

[Software Engineer](https://www.postman.com/company/careers/software-engineer-json-schema-4918592003)

[Technical Community Manager (/devrel)](https://postman.com/company/careers/technical-community-manager-open-technologies-4918571003)

Feel free to reach out to me directly via [Twitter](https://twitter.com/jsonschema) or [Slack](https://json-schema.org/slack) should you have any questions.


# Regular calls

JSON Schema now holds two regular calls. We hold weekly Office Hours and twice monthly Open Community Working Meetings.

Office Hours are 15:00 UTC every Tuesday. The objective is to provide a space for people to ask questions or just chat about JSON Schema in real time with video.

Open Community Working meetings are every 1st and 3rd Friday of the month. We have split the time across multiple zones, but we will be consolidating the time to 12:00 PT for both calls moving forward due to low attendance.

We still want more people to join us on these calls. If you want to have a voice in the future of JSON Schema, please join!

Links to both regular calls can be found on our home page: [https://json-schema.org](https://json-schema.org)


# Community, Slack, and GitHub Discussions

We started using GitHub Discussions as a place for our community outside of Slack. The free tier of Slack limits history, and the valuable answers and discussions are lost. While they can be deep-linked, people still have to be registered with the JSON Schema slack to read the content, and it's not search engine indexed.

After joining the OpenJS Foundation, I reached out to Slack again to see if they would bless us with a free Pro account. This time, they agreed! Enjoy access to the full history of our Slack server!

As we expand the ways in which we interact with our community, it feels fitting to enable the community to discuss how they would like to see things develop, and have an open space to see and read proposals. Our Community repo is that space: [https://github.com/json-schema-org/community](https://github.com/json-schema-org/community)


# JSON Schema Blog

JSON Schema now has a blog! [https://json-schema.org/blog](https://json-schema.org/blog)

We wanted a space to provide best practice examples, thought pieces, case studies, and updates. You may even be reading this article on the blog itself!

Currently there are only a handful of articles, but several more case studies are in the works.

The blog has an RSS feed, so if you're still using an RSS reader you can catch every new update.

There were long time plans to rebuild the website as a whole, but our need for a blog escalated after some discussion around referencing on Twitter. Our first article was a joint post between myself and Mike Ralphson on the new JSON Schema bundling process.

We've published one case study in two languages, English and Japanese.

If you're interested in writing a guest post or collaborating on a case study, please reach out.


# JSON Schema on YouTube

In addition to our written case studies, we wanted to provide some easy watching chat style case studies. This series is called JSON Schema in Production.

We needed a YouTube channel to host the videos, which you can [now subscribe to](https://www.youtube.com/channel/UCrl3fjmHSp6FhJUKcEJhisA) - We need 100 subscribers to claim a custom URL, so any sharing is appreciated.


# Open Objectives

With updates to GitHub Projects, I figured I'd see if they could be useful for tracking JSON Schema work in a more public way. Ultimately, I've ended up using task lists in issues, which seems to be working just fine for now. (Projects are still in beta.)

Postman uses the Objective, Key Results (ORK) approach to defining work. I created OKRs for JSON Schema.

Here is a [Project view for 2022 Q1 OKRs grouped by objective](https://github.com/orgs/json-schema-org/projects/4/views/5).

Here's the [Issue which lists all the Key Results as individual tasks](https://github.com/json-schema-org/community/issues/72).


# In Summary

If you've read this far, you must be interested in what we're doing at JSON Schema and our plans for the future.

The most effective way to keep up to date is to join our Slack server. We're also using Twitter, which is our primary way to reach out to our community when we have questions.

There are lots more things we want to bring you, including essential tooling to enable a modern JSON Schema ecosystem.



Photo by [Abraham Barrera](https://unsplash.com/@abebarrera?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText).


JSON Schema joins the OpenJS Foundation and 2022 updates


## Challenge

With multiple government clients, Tyler Technologies faces the continual challenge of meeting stringent differing requirements defined in law. Building custom rules for each client was very time-consuming, and Tyler Technologies were seeking to create a multi-tenancy application solution that could be customised for each client without needing custom code.

Tyler's multi-tenant application solution needed an easy way to define custom data and validation rules, giving power to the client, rather than having to make heavy investment in custom development work.

"This way we can spend our time providing business value and innovating the application instead of handling all the custom work manually." - Andres Moreno, Lead Software Engineer at Tyler Technologies.

## Solution

JSON Schema allowed Tyler Technologies to create and maintain different model definitions for each client in a simple and understandable format.

JSON Schema was chosen as a viable solution for defining data structures. Tyler found wide adoption of the standard across the industry, partial familiarity from using OpenAPI, and broadness of open-source tools providing rich functionality.

"With JSON Schema, Formly, and AJV we were able to get the functionality we needed to render and validate fields dynamically for each tenant without requiring a developer to do it!" - Andres Moreno

Formly allows for the dynamic generation of forms from JSON Schema, enabling each client to have unique forms based on their unique definitions. AJV allowed for the validation of data from those same forms on the server-side.

"We are focused on API-First development, so we needed a way to allow validation on the server-side for when our API was used directly rather than through the generated forms," Andres continued.

Further, AJV has options to take advantage of annotations such as the `default` keyword, filling in missing attributes, and optionally filtering out data not defined in the schema. These options allowed Tyler Technologies to provide additional value to customers, catering to broader requirements.

## Impact

The effort required to develop and deliver custom work for customer-specific requirements was reduced. Existing schemas can now be easily updated using APIs, without the need to wait for a full deployment cycle.

A new custom field would need to be fully identified and get approval, sent to the development team, verified by QA, and finally deployed to the production environment. "This process can span multiple days or even weeks," explains Andres.

Rather than a full development cycle and release process, updating a JSON Schema takes just a few minutes by those that know JSON Schema, dramatically reducing the time to resolution of bugs related to custom data structures.

## Key Impact Results
<Bigquote>
Showing added value to clients in minutes, rather than days or weeks.
</Bigquote>

"From what used to be a multi-day/week process, to being able to get something in front of the client within minutes," says Andres.

## Tyler Technologies

<p className="text-2xl my-10">Tyler Technologies is a leading provider of end-to-end information management solutions and services for local governments. In recent years they've been playing a key role in the digital transformation of the public sector.</p>

<div className="container flex flex-col sm:flex-row sm:space-x-4 space-y-4 sm:space-y-0 place-content-between mb-4">
  <figure className="group m-auto">
    <img className="flex-1 " src="/img/posts/2022/tyler-technologies-case-study/2187563_0051.webp" />
  </figure>
  <figure className="group m-auto">
    <img className="flex-1" src="/img/posts/2022/tyler-technologies-case-study/2187563_0278.webp" />
  </figure>
</div>

"We empower the public sector to create smarter, safer, and stronger communities. Our team is providing the most innovative solutions to the processes each of our customers have without reinventing the wheel; We choose to assemble instead of building everything ourselves."

Custom development work for each client is a big investment, and a more cost-effective and performant approach was required.

## Benefits in development

<p className="text-2xl my-10">"We are very confident that JSON Schema has solved the challenges that we had faced as we started these projects" - Andres Moreno</p>

Initially using Formly's proprietary configuration format to dynamically generate forms, Tyler needed validation of the resulting data on the server-side. Creating different configurations for the client-side and server-side, which needed to match, wasn't going to give Tyler the scalability they needed.

While investigating, they discovered that Formly also supported configuration using JSON Schema. The same JSON Schema could be used for validation on the client and server sides. With minimal research and prototyping, it became clear using JSON Schema was going to be useful.

After demonstrating how JSON Schema could be easily used to build an extensible application, other teams at Tyler saw the appeal of using a single configuration to both dynamically generate forms and perform validation on the submitted data.

JSON Schema is now a core concern when developing existing and new applications.

"We are very confident that JSON Schema has solved the challenges that we had faced as we started these projects. We can say with certainty that we are going to continue using JSON Schema as the core of the application for any future applications that are built using the cloud infrastructure that we have put in place," explains Andres.

Thank you to Andres Moreno, Lead Software Engineer, and Tyler Technologies, for allowing and enabling us to share this case study with you.


How Tyler Technologies reduced its client feedback loop with JSON Schema


Starting with the release of OpenAPI 3.1, the dialect of JSON Schema used in
OpenAPI documents is configurable. By default, you get the OpenAPI 3.1 Schema
dialect, but you can choose to use draft 2020-12 or any other dialect if you
choose. This brings up the question of how to validate an OpenAPI 3.1 document
if one of its components (JSON Schema) is open-ended. In this article, we'll
cover how to configure the default JSON Schema dialect of an OpenAPI 3.1
document and how to validate that document, including JSON Schemas, no matter
which dialect(s) you choose to use.

## What is a JSON Schema dialect?

Because not everyone is familiar with the term "dialect" in this context, let's
take a moment to define it before moving on. A JSON Schema dialect is any unique
incarnation of JSON Schema. This includes any official release of JSON Schema
such as draft-07 or draft 2020-12, but it also includes custom versions of JSON
Schema. OpenAPI has effectively had three dialects of JSON Schema introduced
with 2.0, 3.0, and 3.1. JSON Schema Dialects are compatible with the core
architecture of JSON Schema but may add keywords, remove keywords, or modify the
behavior of keywords.

## The OpenAPI 3.1 Schema dialect

By default, schemas in OpenAPI 3.1 are assumed to use OpenAPI 3.1's custom JSON
Schema dialect. This dialect includes full support for all draft 2020-12
features plus a few additional keywords and `format` values.

## Validating with the default dialect

There are two schemas available for validating OpenAPI 3.1 documents.
`https://spec.openapis.org/oas/3.1/schema` includes all the constraints for
validating the document except for schemas. You aren't expected to validate your
OpenAPI documents against this schema by itself. Think of this schema as an
abstract schema that is intended to be extended to include schema validation
support for the JSON Schema dialect you're using.

That's why there's also `https://spec.openapis.org/oas/3.1/schema-base` that
extends the abstract schema with validation support for the OpenAPI 3.1 Schema
dialect. If you're using plain out-of-the-box OpenAPI 3.1, this is the schema
you want to validate your document against. If you want to use a different
dialect, keep reading to see how to extend the main schema to get validation
support for your chosen dialect.

This is made possible by dynamic references which were added in JSON Schema
2020-12. The details of how dynamic references work is out of scope for this
article, but we'll cover enough for you to make your own concrete schemas for
any dialect you choose to use in your OpenAPI 3.1 documents.

### Examples

These examples use the [@hyperjump/oas-schema-validator](https://www.npmjs.com/package/@hyperjump/oas-schema-validator)
to validate OpenAPI documents. It's just an extension of [@hyperjump/json-schema](https://www.npmjs.com/package/@hyperjump/json-schema)
with support for the OpenAPI 3.1 dialect and all the OpenAPI 3.1 schemas
pre-packaged. Beware that dynamic references are a new feature of JSON Schema
and many validators don't yet support them, or have limited support, or have
bugs.

#### Without schema validation
```javascript
const OasSchema = require("@hyperjump/oas-schema-validator");
const example = require("./example.openapi.json");

(async function () {
  const schema = await OasSchema.get(
    "https://spec.openapis.org/oas/3.1/schema"
  );
  const validate = await OasSchema.validate(schema);

  const result = validate(example);
  console.log(result.valid);
}());
```

#### With OpenAPI Schema dialect schema validation
```javascript
const OasSchema = require("@hyperjump/oas-schema-validator");
const example = require("./example.openapi.json");

(async function () {
  const schema = await OasSchema.get(
    "https://spec.openapis.org/oas/3.1/schema-base"
  );
  const validate = await OasSchema.validate(schema);

  const result = validate(example);
  console.log(result.valid);
}());
```

### How does it work?

To get an idea about how this works, let's take a look at a few selections from
of the OpenAPI 3.1 schemas.

This is where the Schema Object is defined. The `$dynamicAnchor` declares this
sub-schema to be something that can be effectively overridden by another schema.
If it's not overridden, the default behavior is to validate that the value is an
object or a boolean. No other validation is performed on the schema.

```yaml
$defs:
  schema:
    $dynamicAnchor: meta
    type:
      - object
      - boolean
```

When something in this schema wants to reference the Schema Object, instead of
referencing `#/$defs/schema` like normal, it uses a dynamic reference to the
"meta" dynamic anchor set in the previous selection. Now instead of always
resolving to `#/$defs/schema`, another schema can potentially override where it
resolves to.

```yaml
$defs:
  components:
    type: object
    properties:
      schemas:
        type: object
        additionalProperties:
          $dynamicRef: '#meta'
```

## Validating Schema Objects against the default dialect

With those vague building blocks in mind let's derive a schema that "extends"
the abstract schema to create a schema that validates Schema Objects using the
default dialect meta-schema.

The first step is to include the abstract schema.

```yaml
$schema: 'https://json-schema.org/draft/2020-12/schema'

$ref: 'https://spec.openapis.org/oas/3.1/schema/2021-09-28'
```

Then we need to add a `$dynamicAnchor` that matches the one in the abstract
schema to override where dynamic references to "meta" will resolve to. From
there we can reference the meta schema for the default dialect.

```yaml
$schema: 'https://json-schema.org/draft/2020-12/schema'

$ref: 'https://spec.openapis.org/oas/3.1/schema/2021-09-28'

$defs:
  schema:
    $dynamicAnchor: meta
    $ref: 'https://spec.openapis.org/oas/3.1/dialect/base'
```

That's enough to get the Schema Object validation we were after, but there are a
few loose ends we'll want to tie up as well. The `jsonSchemaDialect` field in
the OpenAPI 3.1 document can be used to change the dialect used. Since this
schema only supports the default dialect, we want to restrict people from
changing that to something else. If they need to change it, they'll need a
different schema to validate against. We also don't want people using the
`$schema` keyword to change the dialect of individual schemas.

```yaml
$schema: 'https://json-schema.org/draft/2020-12/schema'

$ref: 'https://spec.openapis.org/oas/3.1/schema'
properties:
  jsonSchemaDialect:
    $ref: '#/$defs/dialect'

$defs:
  dialect:
    const: 'https://spec.openapis.org/oas/3.1/dialect/base'
  schema:
    $dynamicAnchor: meta
    $ref: 'https://spec.openapis.org/oas/3.1/dialect/base'
    properties:
      $schema:
        $ref: '#/$defs/dialect'
```

With that, we have exactly what you'll find in the official
`https://spec.openapis.org/oas/3.1/schema-base` schema.

## Supporting multiple dialects

With the adoption of JSON Schema 2020-12 came support for the `$id` and
`$schema` keywords, which together allows us to override the default JSON Schema
dialect for a schema. Let's assume we have an OpenAPI 3.1 document where we use
JSON Schema 2020-12 by default, but we also have some legacy JSON Schema
draft-07 schemas that we want to use as well.

```yaml
jsonSchemaDialect: 'https://json-schema.org/draft/2020-12/schema'
components:
  schemas:
    foo:
      type: object
      properties:
        foo:
          $ref: '#/components/schemas/baz'
      unevaluatedProperties: false
    bar:
      $id: './schemas/bar'
      $schema: 'http://json-schema.org/draft-07/schema#'
      type: object
      properties:
        bar:
          $ref: '#/definitions/number'
      definitions:
        number:
          type: number
    baz:
      type: string
```

### What's going on here

First, we use the `jsonSchemaDialect` field to set the default dialect for the
document. By setting the default dialect to JSON Schema 2020-12, by default,
schema will not understand the keywords added in the OpenAPI 3.1 vocabulary such
as `discriminator`. Only standard JSON Schema 2020-12 keywords will be
recognized.

The `/components/schemas/foo` schema is understood to be interpreted as JSON
Schema 2020-12 because that's what we set to be the default.

The `/components/schemas/bar` schema changes the dialect of that schema to be
JSON Schema draft-07. There are a couple of things working together to make this
possible. The `$schema` keyword sets the dialect for the schema, but `$schema`
is only allowed at the root of the document it appears in. That's why we also
need to include the `$id` keyword. The `$id` keyword effectively makes that
schema a separate document with its own identifier and that location as the
root. It's an independent document embedded inside the OpenAPI 3.1 document. You
can think of it like an iframe in HTML.

A consequence of this is that `/components/schemas/bar` can't use a local
reference like `#/components/schemas/foo` to reference another schema in
`/components/schemas` because it's now technically in a different document.
There are two ways to get around this. One option is to use an external
reference to the OpenAPI 3.1 document, such as
`myapi.openapi.yml#/components/schemas/foo`. The other option is to give
`/components/schemas/foo` an `$id` as well and reference that instead,
`./schemas/foo`.

### Validating

Now that we understand how this works, let's derive the schema to validate an
OpenAPI 3.1 document with JSON Schema 2020-12 as the default dialect and JSON
Schema draft-07 as an allowed alternative.

```yaml
$schema: 'https://json-schema.org/draft/2020-12/schema'

$ref: 'https://spec.openapis.org/oas/3.1/schema'
properties:
  jsonSchemaDialect:
    const: 'https://json-schema.org/draft/2020-12/schema'
required:
  - jsonSchemaDialect

$defs:
  schema:
    $dynamicAnchor: meta
    properties:
      $schema:
        enum:
          - 'https://json-schema.org/draft/2020-12/schema'
          - 'http://json-schema.org/draft-07/schema#'
    allOf:
      - if:
          properties:
            $schema:
              const: 'https://json-schema.org/draft/2020-12/schema'
        then:
          $ref: 'https://json-schema.org/draft/2020-12/schema'
      - if:
          type: object
          properties:
            $schema:
              const: 'http://json-schema.org/draft-07/schema#'
          required:
            - $id
            - $schema
        then:
          $ref: 'http://json-schema.org/draft-07/schema'
```

The first change is that the `jsonSchemaDialect` field is now required because
we are no longer using the default.

Next, we have to update the schema definition to only allow `$schema` values for
the dialects we want to allow.

The first `if`/`then` will validate the schema as a JSON Schema 2020-12 schema
if there is no `$schema` keyword used, or `$schema` is set to JSON Schema
2020-12. Of course it's unnecessary to use `$schema` in this case, but it is
allowed.

The second `if`/`then` will validate the schema as a JSON Schema draft-07 schema
if there is an `$id` and a `$schema` indicating draft-07.

You can extend this pattern for any number of dialects you want to support.

Photo by <a href="https://unsplash.com/@gonchifacello?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Gonzalo Facello</a> on <a href="https://unsplash.com/collections/8799947/json-schema-posts/c9d98f0b917af1758a609d674392502f?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Unsplash</a>


Blog¶