diff --git a/_includes/community b/_includes/community index b81462a65..903010740 160000 --- a/_includes/community +++ b/_includes/community @@ -1 +1 @@ -Subproject commit b81462a65d1f9d4941edfa8a4eff8189c2ef1068 +Subproject commit 903010740745b96f9b21204c4b578bb77d84cb53 diff --git a/components/Layout.tsx b/components/Layout.tsx index 3a3b5bbd6..a43fc53ac 100644 --- a/components/Layout.tsx +++ b/components/Layout.tsx @@ -400,7 +400,7 @@ const Footer = () => (

- Copyright © 2024 JSON Schema.  + Copyright © {new Date().getFullYear()} JSON Schema.  All rights reserved.

diff --git a/components/Sidebar.tsx b/components/Sidebar.tsx index 6370bb406..962d2412e 100644 --- a/components/Sidebar.tsx +++ b/components/Sidebar.tsx @@ -380,6 +380,7 @@ export const DocsNav = ({ setOpen={setOpen} /> + { h4: { component: Headline4 }, strong: { component: ({ children }) => ( - + {children} ), diff --git a/context.ts b/context.ts index 2d7bbee79..9f8022ea5 100644 --- a/context.ts +++ b/context.ts @@ -21,6 +21,7 @@ export const SectionContext = React.createContext< | 'reference' | 'roadmap' | 'ambassador' + | 'pro-help' >(null); export const BlockContext = React.createContext(null); export const FullMarkdownContext = React.createContext(null); diff --git a/pages/index.page.tsx b/pages/index.page.tsx index 0b4dd2e9c..2aa976a8a 100644 --- a/pages/index.page.tsx +++ b/pages/index.page.tsx @@ -515,13 +515,17 @@ const Home = (props: any) => { className='border-b border-black' > sponsor - {' '} - or a{' '} + + , a{' '} backer + {' '} + or hiring our{' '} + + pro services .

diff --git a/pages/pro-help/index.page.tsx b/pages/pro-help/index.page.tsx new file mode 100644 index 000000000..99eb27681 --- /dev/null +++ b/pages/pro-help/index.page.tsx @@ -0,0 +1,217 @@ +import React from 'react'; +import fs from 'fs'; +import { getLayout } from '~/components/SiteLayout'; +import Head from 'next/head'; +import { Headline1 } from '~/components/Headlines'; +import { SectionContext } from '~/context'; +import { DocsHelp } from '~/components/DocsHelp'; + +interface ContractorLink { + title: string; + url: string; +} + +interface Contractor { + name: string; + bio: string; + email?: string; + website?: string; + github: string; + x?: string; + mastodon?: string; + linkedin?: string; + incorporatedIn: string[]; + type: string; + links: ContractorLink[]; +} + +export async function getStaticProps() { + const contractorData = JSON.parse( + fs.readFileSync( + '_includes/community/programs/contractors/contractors.json', + 'utf-8', + ), + ) as Contractor[]; + + return { + props: { + contractorData, + }, + }; +} + +interface ProHelpPageProps { + contractorData: Contractor[]; +} + +export default function ProHelp({ contractorData }: ProHelpPageProps) { + const newTitle = 'Need pro help with JSON Schema?'; + + return ( + + + {newTitle} + +
+
+
+ {newTitle} +

+ Whether you need training, personalized advice, or custom JSON + Schema solutions, some members of the JSON Schema Technical Steering + Committee (TSC) and Ambassadors programs offer pro services beyond + community support. Don't hesitate in reaching out to discuss + further. +

+
+

+ Hiring our top contributors also helps funding the JSON Schema + open-source organization, and as a consequence, the specifications + that build on top of it, such as{' '} + + OpenAPI + + , + + AsyncAPI + + , + + RAML + + , + + W3C WoT + + , and many more. +

+
+ Available Members +
+ {contractorData.map((contractor) => ( +
+

+ {contractor.name} + + {contractor.type} + +

+ +
+ +
+

{contractor.bio}

+

+ Previous work and relevant links +

+ +
+
+
+ ))} +
+
+
+
+
+ +
+ + ); +} + +ProHelp.getLayout = getLayout; diff --git a/pages/understanding-json-schema/reference/string.md b/pages/understanding-json-schema/reference/string.md index 8620076a1..dde680a68 100644 --- a/pages/understanding-json-schema/reference/string.md +++ b/pages/understanding-json-schema/reference/string.md @@ -121,129 +121,3 @@ with an optional area code: // props { "indent": true, "valid": false } "(800)FLOWERS" ``` - -## Format[#format] - -The `format` keyword allows for basic semantic identification of certain -kinds of string values that are commonly used. For example, because JSON -doesn\'t have a \"DateTime\" type, dates need to be encoded as strings. -`format` allows the schema author to indicate that the string value -should be interpreted as a date. By default, `format` is just an -annotation and does not effect validation. - -Optionally, validator [implementations](../../learn/glossary#implementation) can provide a configuration option -to enable `format` to function as an assertion rather than just an -annotation. That means that validation will fail if, for example, a -value with a `date` format isn\'t in a form that can be parsed as a -date. This can allow values to be constrained beyond what the other -tools in JSON Schema, including [Regular Expressions](../../understanding-json-schema/reference/regular_expressions) can -do. - -> Implementations may provide validation for only a subset of the built-in -> formats or do partial validation for a given format. For example, some -> implementations may consider a string an email if it contains a `@`, -> while others might do additional checks for other aspects of a well -> formed email address. - -There is a bias toward networking-related formats in the JSON Schema -specification, most likely due to its heritage in web technologies. -However, custom formats may also be used, as long as the parties -exchanging the JSON documents also exchange information about the custom -format types. A JSON Schema validator will ignore any format type that -it does not understand. - -### Built-in formats[#built-in-formats] - -The following is the list of formats specified in the JSON Schema -specification. - -#### Dates and times - -Dates and times are represented in [RFC 3339, section 5.6](https://tools.ietf.org/html/rfc3339#section-5.6). This is a subset -of the date format also commonly known as [ISO8601 format](https://www.iso.org/iso-8601-date-and-time-format.html). - -- `"date-time"`: Date and time together, for example, - `2018-11-13T20:20:39+00:00`. -- `"time"`: Time, for example, `20:20:39+00:00` -- `"date"`: Date, for example, `2018-11-13`. -- `"duration"`: A duration as defined by the [ISO 8601 ABNF for \"duration\"](https://datatracker.ietf.org/doc/html/rfc3339#appendix-A). - For example, `P3D` expresses a duration of 3 days. - - - -#### Email addresses - -- `"email"`: Internet email address, see [RFC 5321, section 4.1.2](http://tools.ietf.org/html/rfc5321#section-4.1.2). -- `"idn-email"`: The internationalized form of an Internet email - address, see [RFC 6531](https://tools.ietf.org/html/rfc6531). - - - -#### Hostnames - -- `"hostname"`: Internet host name, see [RFC 1123, section 2.1](https://datatracker.ietf.org/doc/html/rfc1123#section-2.1). -- `"idn-hostname"`: An internationalized Internet host name, see - [RFC5890, section 2.3.2.3](https://tools.ietf.org/html/rfc5890#section-2.3.2.3). - - - -#### IP Addresses - -- `"ipv4"`: IPv4 address, according to dotted-quad ABNF syntax as - defined in [RFC 2673, section 3.2](http://tools.ietf.org/html/rfc2673#section-3.2). -- `"ipv6"`: IPv6 address, as defined in [RFC 2373, section 2.2](http://tools.ietf.org/html/rfc2373#section-2.2). - - - -#### Resource identifiers - -- `"uuid"`: A Universally Unique Identifier as defined by [RFC 4122](https://datatracker.ietf.org/doc/html/rfc4122). Example: - `3e4666bf-d5e5-4aa7-b8ce-cefe41c7568a` -- `"uri"`: A universal resource identifier (URI), according to - [RFC3986](http://tools.ietf.org/html/rfc3986). -- `"uri-reference"`: A URI Reference (either a URI or a - relative-reference), according to [RFC3986, section 4.1](http://tools.ietf.org/html/rfc3986#section-4.1). -- `"iri"`: The internationalized equivalent of a \"uri\", according to - [RFC3987](https://tools.ietf.org/html/rfc3987). -- `"iri-reference"`: The internationalized equivalent of a - \"uri-reference\", according to - [RFC3987](https://tools.ietf.org/html/rfc3987) - -If the values in the schema have the ability to be relative to a -particular source path (such as a link from a webpage), it is generally -better practice to use `"uri-reference"` (or `"iri-reference"`) rather -than `"uri"` (or `"iri"`). `"uri"` should only be used when the path -must be absolute. - - - -#### URI template - -- `"uri-template"`: A URI Template (of any level) according to - [RFC6570](https://tools.ietf.org/html/rfc6570). If you don\'t - already know what a URI Template is, you probably don\'t need this - value. - - - -#### JSON Pointer - -- `"json-pointer"`: A JSON Pointer, according to - [RFC6901](https://tools.ietf.org/html/rfc6901). There is more - discussion on the use of JSON Pointer within JSON Schema in - [Structuring a complex schema](../../understanding-json-schema/structuring). Note that this should be used only when - the entire string contains only JSON Pointer content, e.g. - `/foo/bar`. JSON Pointer URI fragments, e.g. `#/foo/bar/` should use - `"uri-reference"`. -- `"relative-json-pointer"`: A [relative JSON pointer](https://tools.ietf.org/html/draft-handrews-relative-json-pointer-01). - - - -#### Regular Expressions - -- `"regex"`: A regular expression, which should be valid according to - the [ECMA 262](https://www.ecma-international.org/publications-and-standards/standards/ecma-262/) - [dialect](../../learn/glossary#dialect). - -Be careful, in practice, JSON schema validators are only required to -accept the safe subset of [regular expressions](../../understanding-json-schema/reference/regular_expressions) described elsewhere in this document. diff --git a/pages/understanding-json-schema/reference/type.md b/pages/understanding-json-schema/reference/type.md index fc5608a7a..dd3698476 100644 --- a/pages/understanding-json-schema/reference/type.md +++ b/pages/understanding-json-schema/reference/type.md @@ -181,3 +181,64 @@ types. For example, numeric types have a way of specifying a numeric range, that would not be applicable to other types. In this reference, these validation keywords are described along with each of their corresponding types in the following chapters. + +## Format[#format] + +The `format` keyword conveys semantic information for values that may be difficult or impossible to describe using JSON Schema. Typically, this semantic information is described by other documents. The JSON Schema Validation specification defines several formats, but this keyword also allows schema authors to define their own formats. + +For example, because JSON doesn't have a "DateTime" type, dates need to be encoded as strings. `format` allows the schema author to indicate that the string value should be interpreted as a date. By default, `format` is just an annotation and does not affect validation. + +Optionally, validator [implementations](../../learn/glossary#implementation) can provide a configuration option to enable `format` to function as an assertion rather than just an annotation. That means that validation fails when, for example, a value with a `date` format isn't in a form that can be parsed as a date. This allows values to be constrained beyond what other tools in JSON Schema, including [Regular Expressions](../../understanding-json-schema/reference/regular_expressions), can do. + +> Implementations may provide validation for only a subset of the built-in formats or do partial validation for a given format. For example, some implementations may consider a string an email if it contains an `@`, while others might perform additional checks for other aspects of a well-formed email address. + +The JSON Schema specification has a bias toward networking-related formats due to its roots in web technologies. However, custom formats may also be used if the parties exchanging the JSON documents share information about the custom format types. A JSON Schema validator will ignore any format type it does not understand. + +### Built-in Formats + +It should be noted that `format` is not limited to a specific set of valid values or types. Users may define their own custom keywords including ones that work with JSON data types other than `string`, such as `number`. Below, we cover the formats specified in the JSON Schema specification. + +#### Dates and Times + +Dates and times are represented in [RFC 3339, section 5.6](https://tools.ietf.org/html/rfc3339#section-5.6). RFC 3339 is a specification from the Internet Engineering Task Force (IETF). + +- `"date-time"`: Date and time together, for example, `2018-11-13T20:20:39+00:00`. +- `"time"`: Time, for example, `20:20:39+00:00`. +- `"date"`: Date, for example, `2018-11-13`. +- `"duration"`: A duration as defined by the [ISO 8601 ABNF for "duration"](https://datatracker.ietf.org/doc/html/rfc3339#appendix-A). For example, `P3D` expresses a duration of 3 days. + +#### Email Addresses + +- `"email"`: Internet email address, see [RFC 5321, section 4.1.2](http://tools.ietf.org/html/rfc5321#section-4.1.2). +- `"idn-email"`: The internationalized form of an Internet email address, see [RFC 6531](https://tools.ietf.org/html/rfc6531). + +#### Hostnames + +- `"hostname"`: Internet host name, see [RFC 1123, section 2.1](https://datatracker.ietf.org/doc/html/rfc1123#section-2.1). +- `"idn-hostname"`: An internationalized Internet host name, see [RFC5890, section 2.3.2.3](https://tools.ietf.org/html/rfc5890#section-2.3.2.3). + +#### IP Addresses + +- `"ipv4"`: IPv4 address, according to dotted-quad ABNF syntax as defined in [RFC 2673, section 3.2](http://tools.ietf.org/html/rfc2673#section-3.2). +- `"ipv6"`: IPv6 address, as defined in [RFC 2373, section 2.2](http://tools.ietf.org/html/rfc2373#section-2.2). + +#### Resource Identifiers + +- `"uuid"`: A Universally Unique Identifier as defined by [RFC 4122](https://datatracker.ietf.org/doc/html/rfc4122). Example: `3e4666bf-d5e5-4aa7-b8ce-cefe41c7568a`. +- `"uri"`: A universal resource identifier (URI), according to [RFC3986](http://tools.ietf.org/html/rfc3986). +- `"uri-reference"`: A URI Reference (either a URI or a relative-reference), according to [RFC3986, section 4.1](http://tools.ietf.org/html/rfc3986#section-4.1). +- `"iri"`: The internationalized equivalent of a "uri", according to [RFC3987](https://tools.ietf.org/html/rfc3987). +- `"iri-reference"`: The internationalized equivalent of a "uri-reference", according to [RFC3987](https://tools.ietf.org/html/rfc3987). + +#### URI Template + +- `"uri-template"`: A URI Template (of any level) according to [RFC6570](https://tools.ietf.org/html/rfc6570). If you don\'t already know what a URI Template is, you probably don\'t need this value. + +#### JSON Pointer + +- `"json-pointer"`: A JSON Pointer, according to [RFC6901](https://tools.ietf.org/html/rfc6901). There is more discussion on using JSON Pointer within JSON Schema in [Structuring a complex schema](../../understanding-json-schema/structuring). Note that this should be used only when the entire string contains only JSON Pointer content, e.g., `/foo/bar`. JSON Pointer URI fragments, e.g., `#/foo/bar/` should use `"uri-reference"`. +- `"relative-json-pointer"`: A [relative JSON pointer](https://tools.ietf.org/html/draft-handrews-relative-json-pointer-01). + +#### Regular Expressions + +- `"regex"`: A regular expression that should be valid according to the [ECMA 262](https://www.ecma-international.org/publications-and-standards/standards/ecma-262/) [dialect](../../learn/glossary#dialect). Be careful, in practice, JSON Schema validators are only required to accept the safe subset of [regular expressions](../../understanding-json-schema/reference/regular_expressions) described elsewhere in this document. diff --git a/styles/globals.css b/styles/globals.css index 5288d6aa4..ca0e0b2cc 100644 --- a/styles/globals.css +++ b/styles/globals.css @@ -66,6 +66,7 @@ border-radius: 4px; */ .DocSearch-Button { margin: 0; width: 39px; + background: none; } .DocSearch-Button-Placeholder {