-
-
Notifications
You must be signed in to change notification settings - Fork 272
Added migration page overview #1061
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from 36 commits
859a6f1
93bcaba
d4c8b24
8eb9721
75ee2a1
a967f66
b22b2ff
c5d352e
136ee2e
fa6391b
83536f1
dd364ba
dd1d4e7
33b69ab
9c583ce
5a4b8b3
24488f9
4e5a08d
d17e308
c5b1f87
95276a0
288e5d9
7199292
8cc36f0
45aecbc
65ba898
9891c6e
5bdfc65
3ef35de
a68d4f3
65325b8
419ea36
43f9816
bb62eaa
757f1f9
5eae100
93da171
994f731
ffcf639
b439468
85b9ceb
81ebeea
d718e51
3a5a632
33e536b
266963b
e75e0da
78d912a
5a46c9d
91c3b63
ddec102
f0fd4c2
f2aa409
6e7aa3e
7badaea
625b9f8
6649ac8
a215d13
2d34ff1
6009e19
54a0e49
aa0ca88
586e3d0
f568aee
06de9fa
bec87f1
8a56fdf
f0d7f96
e2e3fb7
8800dc0
9bbb1c2
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,39 @@ | ||
import React from 'react'; | ||
import Head from 'next/head'; | ||
import { getLayout } from '~/components/Sidebar'; | ||
import StyledMarkdown from '~/components/StyledMarkdown'; | ||
import getStaticMarkdownPaths from '~/lib/getStaticMarkdownPaths'; | ||
import getStaticMarkdownProps from '~/lib/getStaticMarkdownProps'; | ||
import { Headline1 } from '~/components/Headlines'; | ||
import { SectionContext } from '~/context'; | ||
import { DocsHelp } from '~/components/DocsHelp'; | ||
|
||
export async function getStaticPaths() { | ||
return getStaticMarkdownPaths('pages/draft-02'); | ||
} | ||
export async function getStaticProps(args: any) { | ||
return getStaticMarkdownProps(args, 'pages/draft-02'); | ||
} | ||
|
||
export default function StaticMarkdownPage({ | ||
frontmatter, | ||
content, | ||
}: { | ||
frontmatter: any; | ||
content: any; | ||
}) { | ||
const markdownFile = '_index'; | ||
const newTitle = 'JSON Schema - ' + frontmatter.title; | ||
|
||
return ( | ||
<SectionContext.Provider value={frontmatter.section || null}> | ||
<Head> | ||
<title>{newTitle}</title> | ||
</Head> | ||
<Headline1>{frontmatter.title}</Headline1> | ||
<StyledMarkdown markdown={content} /> | ||
<DocsHelp markdownFile={markdownFile} /> | ||
</SectionContext.Provider> | ||
); | ||
} | ||
StaticMarkdownPage.getLayout = getLayout; |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,39 @@ | ||
import React from 'react'; | ||
import Head from 'next/head'; | ||
import { getLayout } from '~/components/Sidebar'; | ||
import StyledMarkdown from '~/components/StyledMarkdown'; | ||
import getStaticMarkdownPaths from '~/lib/getStaticMarkdownPaths'; | ||
import getStaticMarkdownProps from '~/lib/getStaticMarkdownProps'; | ||
import { Headline1 } from '~/components/Headlines'; | ||
import { SectionContext } from '~/context'; | ||
import { DocsHelp } from '~/components/DocsHelp'; | ||
|
||
export async function getStaticPaths() { | ||
return getStaticMarkdownPaths('pages/draft-03'); | ||
} | ||
export async function getStaticProps(args: any) { | ||
return getStaticMarkdownProps(args, 'pages/draft-03'); | ||
} | ||
|
||
export default function StaticMarkdownPage({ | ||
frontmatter, | ||
content, | ||
}: { | ||
frontmatter: any; | ||
content: any; | ||
}) { | ||
const markdownFile = '_index'; | ||
const newTitle = 'JSON Schema - ' + frontmatter.title; | ||
|
||
return ( | ||
<SectionContext.Provider value={frontmatter.section || null}> | ||
<Head> | ||
<title>{newTitle}</title> | ||
</Head> | ||
<Headline1>{frontmatter.title}</Headline1> | ||
<StyledMarkdown markdown={content} /> | ||
<DocsHelp markdownFile={markdownFile} /> | ||
</SectionContext.Provider> | ||
); | ||
} | ||
StaticMarkdownPage.getLayout = getLayout; |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,4 @@ | ||
--- | ||
title: Draft 02 to Draft 03 | ||
section: docs | ||
--- |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,39 @@ | ||
import React from 'react'; | ||
import Head from 'next/head'; | ||
import { getLayout } from '~/components/Sidebar'; | ||
import StyledMarkdown from '~/components/StyledMarkdown'; | ||
import getStaticMarkdownPaths from '~/lib/getStaticMarkdownPaths'; | ||
import getStaticMarkdownProps from '~/lib/getStaticMarkdownProps'; | ||
import { Headline1 } from '~/components/Headlines'; | ||
import { SectionContext } from '~/context'; | ||
import { DocsHelp } from '~/components/DocsHelp'; | ||
|
||
export async function getStaticPaths() { | ||
return getStaticMarkdownPaths('pages/draft-04'); | ||
} | ||
export async function getStaticProps(args: any) { | ||
return getStaticMarkdownProps(args, 'pages/draft-04'); | ||
} | ||
|
||
export default function StaticMarkdownPage({ | ||
frontmatter, | ||
content, | ||
}: { | ||
frontmatter: any; | ||
content: any; | ||
}) { | ||
const markdownFile = '_index'; | ||
const newTitle = 'JSON Schema - ' + frontmatter.title; | ||
|
||
return ( | ||
<SectionContext.Provider value={frontmatter.section || null}> | ||
<Head> | ||
<title>{newTitle}</title> | ||
</Head> | ||
<Headline1>{frontmatter.title}</Headline1> | ||
<StyledMarkdown markdown={content} /> | ||
<DocsHelp markdownFile={markdownFile} /> | ||
</SectionContext.Provider> | ||
); | ||
} | ||
StaticMarkdownPage.getLayout = getLayout; |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,76 @@ | ||
--- | ||
title: Migrating from Draft 03 to Draft 04 | ||
section: docs | ||
--- | ||
|
||
### Introduction | ||
|
||
The migration from Draft 3 to Draft 4 of JSON Schema introduces changes in how schemas are defined and validated. Draft 4, published on January 31, 2013, introduced new keywords and revised the behaviours of existing ones. | ||
|
||
This guide will help you adapt your JSON Schemas to align with Draft 4 requirements, covering keyword changes, updates, and behavioural modifications. | ||
|
||
### Keyword changelog | ||
|
||
Below is a summary table highlighting keyword changes between Draft 3 and Draft 4. | ||
|
||
| Keyword (Draft 3) | Keyword (Draft 4) | Specification | Keyword type | Behavior Details | | ||
| ----------------- | ----------------- | ------------- | ----------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | ||
| `$schema` | `$schema` | Core | Identifier | Change in the dialect (Uses the latest Draft4 dialect) | | ||
| `type` | `type` | Validation | Assertion | This change no longer accepts the `any` type, restricting instances to the seven core primitive types only. | | ||
kwennB marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| `disallow` | removed | Validation | Applicator | The `disallow` keyword was removed, eliminating the ability to specify types or schemas that an instance must not match. | | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The ability to specify types or schemas that an instance must not match wasn't eliminated, it's just done using There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Can you confirm that There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I can confirm that
|
||
| `required` | `required` | Validation | Assertion | The `required` keyword shifted from being a boolean within each property to a standalone keyword that takes an array of required property names outside of properties. | | ||
| `divisibleBy` | `multipleOf` | Validation | Assertion | `divisibleBy` was renamed to `multipleOf`, with a stricter requirement that its value must be greater than 0. | | ||
kwennB marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| `extends` | removed | Validation | Applicator | The `extends` keyword was removed; allOf was added as a new keyword to achieve similar functionality. | | ||
| `format` | `format` | Validation | Annotation | - | | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Missing change description. I think there were some changes to what formats are defined, but otherwise there weren't any changes in the behavior of this keyword. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I am still unsure how to better describe the Yes noted for There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. How about this for There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Those discussions are irrelevant because they are about future I think @Ritesh2351235 has the right idea, but I'd simplify significantly. I suggest,
|
||
| `dependencies` | `dependencies` | Core | Assertion | The `dependencies` member values were changed to require an array, eliminating the use of single strings. | | ||
kwennB marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| `ref` (legacy) | `ref` (legacy) | Core | Applicator | - | | ||
kwennB marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| Not present | `allOf` | Core | Applicator | - | | ||
| Not present | `anyOff` | Core | Applicator | - | | ||
kwennB marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| Not present | `definitions` | Validation | Reserved Location | - | | ||
| Not present | `maxProperties` | Validation | Assertion | - | | ||
| Not present | `minProperties` | Validation | Assertion | - | | ||
| Not present | `not` | Core | Applicator | - | | ||
| Not present | `oneOf` | Core | Applicator | - | | ||
|
||
<Infobox label="Note"> Starting with Draft 4, schema identifiers that use an empty URI "" or a fragment-only URI "#" are no longer allowed. | ||
|
||
In Draft 3, these identifiers were considered valid: | ||
|
||
``` | ||
id: "" | ||
kwennB marked this conversation as resolved.
Show resolved
Hide resolved
|
||
id: "#" | ||
``` | ||
|
||
However, this format is now prohibited from Draft 4 onwards. | ||
</Infobox> | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Should There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. No, it was only used as a reference example. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Sorry, I didn't understand your response. The infobox is describing a change to how There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is what I was trying to communicate with the infobox. On Draft 3, it was defined as : And on Draft 4: -- But thank you for pointing out There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Maybe I'm missing something, but I don't think that's true. You've quoted the definition of Actually, the spec says "SHOULD", not "MUST". So, technically those empty values aren't disallowed, it's just recommended that schema authors don't use them. I think that's a good argument for not considering this not a change and leaving it out of the migration page altogether. Implementations in both drafts should consider those values to effectively be a no-op. The only difference is that draft-04 tells schema authors not to use that particular nonsense value. I'd argue that nothing actually changed in the behavior of |
||
|
||
<Infobox label="Note"> | ||
Before Draft 3, the JSON Schema only included the Core specification, which outlined the foundational elements for schema structure. With Draft 4, the specification expanded to incorporate Validation, establishing rules for data format, structure, and type requirements. This addition enabled schema authors to define and enforce validation constraints directly within their schemas, making it easier for implementers to ensure data integrity and compatibility as schemas evolved. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This isn't correct. There was originally only one spec that included everything. Everything that we now consider Core, Validation, and Hyper-Schema was included in that one spec. In draft-04, the one spec was split into the three parts we're familiar with today. So, the spec didn't expand in draft-04 to include validation. Validation was always there. It just split that content into a different document. This may be too much detail, but what has gone in each document has changed over time as well. The Content vocabulary and a few Meta-Data keywords moved from Hyper-Schema to Validation (draft-07) and the Applicator vocabulary moved from Validation to Core (2019-09). There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
What was the one spec? If you also stated that there was originally only one specification, at what point did the Validation become necessary?
Thank you. I will phrase this better.
Are there any more data for scenarios like this? To better represent this Spec note, what would be the most nearly accurate detail? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
I'm not sure what you mean. Draft-01, draft-02, and draft-03 were all just one spec that included what is now Core, Validation, and Hyper-Schema. It didn't really have another name like the three do now. It was just the JSON Schema spec.
Validation was always part of the spec. It was included from the first draft. It was always necessary.
I think this kind of information is in the release notes for each draft. The older drafts don't have release notes, but those didn't have these kinds of changes.
Honestly, I'm not sure what this spec note is trying to communicate. Is it just that there are now three specs instead of one?1 That was just a change in the way the spec was maintained. It has little affect on what people can and can't do with JSON Schema. However, splitting off Hyper-Schema meant draft-04 was the first draft where you could implement JSON Schema without including Hyper-Schema support. Implementers could implement Core and Validation and treat Hyper-Schema as an extension that they don't support. Footnotes
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Thank you for clarifying about the initial "JSON Schema Spec". There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think this infobox can be removed. It's not relevant to migration. It's just an administrative detail that doesn't effect how schemas are written or evaluated. |
||
</Infobox> | ||
|
||
### Tutorial | ||
|
||
This tutorial walks you through key steps and considerations to help you successfully migrate your JSON schemas from Draft 3 to Draft 4. | ||
|
||
#### Step 1: Review Core Changes | ||
|
||
Start by familiarizing yourself with the updates in the [Draft 4 Core schema specification](https://json-schema.org/draft-04/draft-zyp-json-schema-04.html). Note the revised `type`, `properties`, and `$ref` keywords, which might affect your schemas if you rely on polymorphic types or cross-schema references. | ||
kwennB marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
#### Step 2: Update Validation Keywords | ||
|
||
Draft 4 has introduced new keywords such as `required`, `dependencies`, `anyOf`, `allOf`, and `patternProperties`. Review each of these additions, and update your schemas to use these keywords if relevant. For instance: | ||
|
||
- If you have properties that must always be present, use `required` to define these properties explicitly. | ||
- For schemas that contain nested dependencies, consider restructuring them using `dependencies` to improve schema maintainability. | ||
kwennB marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
#### Step 3: Refactor $ref Usage | ||
|
||
References in Draft 4 (`$ref`) are more standardized, which enhances schema modularity and reusability. If your schema relies on definitions within or across schemas, make sure the `$ref` keyword is used consistently as per Draft 4’s enhanced JSON Reference guidelines. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. There were no changes to There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Then there's no need to keep this as Step 3. |
||
|
||
#### Step 4: Validate Your Updated Schemas | ||
|
||
Test your updated schemas using a JSON Schema validator compatible with Draft 4 ([Another JSON Validator](https://ajv.js.org/) (AJV)). Pay particular attention to behaviours of `type`, `properties`, and new combinatory keywords (`allOf`, `anyOf`), as validation behaviour may differ from Draft 3. | ||
|
||
#### Step 5: Test in Your Application Context | ||
|
||
After the schema updates, integrate them into your application and test the end-to-end functionality. Ensure that the new schema definitions meet your data requirements and interact appropriately with application code, especially in cases involving complex validation rules and nested references. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. These last two steps effectively just tell people to test the changes to their schemas. That's general and obvious software development practice that I don't think needs to be said explicitly. In any case, don't suggest using AJV. It has poor spec compliance and isn't actively maintained. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Could you suggest any tool? We can also say, "validate and test your updated schemas with your preferred tool". There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I like suggesting they use their preferred tool. We could link to the tooling page to help them find a tool if they don't have a preferred tool yet. |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,6 @@ | ||
--- | ||
title: Draft 04 to Draft 05 | ||
section: docs | ||
--- | ||
|
||
4-5 | ||
kwennB marked this conversation as resolved.
Show resolved
Hide resolved
|
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,4 @@ | ||
--- | ||
title: Draft 05 to Draft 06 | ||
section: docs | ||
--- |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,4 @@ | ||
--- | ||
title: Draft 07 to Draft 2010-09 | ||
section: docs | ||
--- |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,6 @@ | ||
--- | ||
title: Draft 2019-09 to Draft 2020-12 | ||
section: docs | ||
--- | ||
|
||
Testing to see if this page is visible. |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,6 @@ | ||
--- | ||
title: Draft 2019-09 to Draft 2020-12 | ||
section: docs | ||
--- | ||
|
||
2019-09 to 2020-12 |
Uh oh!
There was an error while loading. Please reload this page.