-
-
Notifications
You must be signed in to change notification settings - Fork 256
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
Added migration page overview #1061
base: main
Are you sure you want to change the base?
Changes from 43 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
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,48 @@ | ||
--- | ||
title: Draft 02 to Draft 03 | ||
section: docs | ||
--- | ||
|
||
### Introduction | ||
|
||
The migration from Draft 2 to Draft 3 of JSON Schema introduced significant updates in schema definition and validation behaviors. Draft 3 refined existing keywords, added new ones, and adjusted validation rules to improve schema precision and consistency. This guide will assist you in updating your JSON Schemas to meet Draft 3 requirements, detailing keyword replacements, vocabulary changes, and modifications in validation behaviors. | ||
|
||
### Keyword changelog | ||
|
||
| Keyword(Draft 2) | Keyword(Draft 3) | Specification | Keyword type | Behavior Details | | ||
| ----------------- | ------------------- | ------------- | ------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | ||
| `$schema` | `$schema` | `core` | Identifier | Change in the dialect | | ||
| not present | `$ref` | `core` | Applicator | `$ref` key references an external schema URI for validation, allowing re-validation against the referenced schema. | | ||
kwennB marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| not present | `id` | `core` | Identifier | This attribute defines the schema's current URI (a "self" link). The URI can be relative or absolute and is resolved against the parent schema's URI. If id is missing, the parent's URI is used. | | ||
kwennB marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| `optional` | `required` | `core` | Assertion | This change ensures that properties must have defined values for validation. | | ||
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 description needs work. In draft-02, object properties defined with Hopefully, you can rewrite that in a more concise way for this description. 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 the feedback Jason!, |
||
| `minimumCanEqual` | `exclusiveMinimum` | `core` | Assertion | Specifies that instance values must be strictly greater than the minimum when `exclusiveMinimum` is `true`. | | ||
| `maximumCanEqual` | `exclusiveMaximum` | `core` | Assertion | This ensures that instance values fall below the maximum when `exclusiveMaximum` is `true`. | | ||
| `format` | `format` | `core` | Annotation | This update refined format handling by adding and removing specific types, offering clearer guidance for expected data formats. | | ||
| not present | `patternProperties` | `core` | Applicator | Enforces schema validation on properties with names matching specified regex patterns. Each property matching a pattern must conform to the schema defined for that pattern in `patternProperties`. | | ||
| `requires` | `dependencies` | `core` | Assertion | Defines property dependencies - if an instance includes a property named in this attribute, that property must meet additional validation requirements defined by its dependency value. | | ||
| not present | `additionalItems` | `core` | Applicator | Defines rules for extra items in an array - can be set to false to disallow extra items beyond specified tuples, or to a schema that additional items must follow. | | ||
| `alternate` | removed | `core` | | - | | ||
|
||
### Tutorial | ||
|
||
#### Step 1: Review Core Changes: | ||
|
||
Start by understanding the key differences between Draft 2 and Draft 3, especially regarding core changes in $schema, $ref, and validation keywords. | ||
|
||
- `$schema`: In Draft 3, this remains the same but is now more standardized to handle the schema dialect and the version of the specification being used. | ||
kwennB marked this conversation as resolved.
Show resolved
Hide resolved
|
||
- `$ref`: Draft 3 introduces the `$ref` keyword, which allows referencing external schemas for validation. This will enable more modular and reusable schema definitions. | ||
kwennB marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
#### Step 2: Update Validation Keywords: | ||
|
||
Draft 3 introduces new validation keywords that improve flexibility in schema definitions. Notable changes include: | ||
|
||
- `optional` to `required`: Draft 3 removes the `optional` keyword and introduces `required`, which specifies the required properties for an object. | ||
- `minimumCanEqual` to `exclusiveMinimum`: For numerical validation, `exclusiveMinimum` enforces that the value must be strictly greater than the given minimum value. | ||
- `maximumCanEqual` to `exclusiveMaximum`: Similarly, `exclusiveMaximum` ensures the value is strictly less than the maximum allowed value. | ||
- `patternProperties`: Draft 3 introduces `patternProperties`, which allows you to define schema rules for properties whose names match a regular expression. | ||
|
||
#### Step 3: Refactor $ref Usage | ||
|
||
Draft 3 introduces a more standardized usage of `$ref`, which allows you to reference external schemas using **URIs**. This improves schema modularity and enables better reuse of schema definitions. | ||
kwennB marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
Validate and test your updated schemas manually, or with your preferred tool. |
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,87 @@ | ||
--- | ||
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) | | ||
kwennB marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| `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 specifies types or schemas that an instance must not match, although removed; this functionality has been replaced by the `not` keyword. | | ||
| `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. | | ||
| `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 of strings or a schema, eliminating the use of single strings. | | ||
| `id` | `id` | Core | Identifier | - | | ||
| Not present | `allOf` | Core | Applicator | - | | ||
| Not present | `anyOf` | Core | Applicator | - | | ||
| 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 | - | | ||
|
||
#### Helpful notes for Keyword changelog | ||
|
||
1. `type` | ||
|
||
In Draft-03, the `type` keyword could hold a simple value like "string" or "number" and an entire schema as its value. | ||
|
||
For example: | ||
|
||
```json | ||
{ | ||
"type": { | ||
"type": "array", | ||
"items": { "type": "string" } | ||
} | ||
} | ||
``` | ||
|
||
This feature was in Draft-03 but changed in later versions of JSON Schema, where `type` is limited to simpler values like strings or arrays of strings. | ||
|
||
The `allof` keyword has now replaced the previous type schema functionality. | ||
kwennB marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
<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`, `required`, and `dependencies` keywords, which might affect your schemas if you rely on polymorphic types or cross-schema references. | ||
|
||
#### Step 2: Update Validation Keywords | ||
|
||
Draft 4 has introduced new keywords such as `oneOf`, `not`, `anyOf`, and `allOf`. 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. | ||
|
||
Validate and test your updated schemas manually, or with your preferred tool. |
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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
$schema
didn't exist in draft-02. It was introduced in draft-03.