[要約] RFC 8927はJSON Type Definition (JTD)に関するもので、JSONデータ構造の型を定義するための言語です。その目的は、JSONデータの検証、文書化、およびインターフェース生成を簡素化することにあります。利用場面としては、APIのスキーマ定義、設定ファイルの検証、またはデータ通信の型安全性の確保などがあります。
Independent Submission U. Carion
Request for Comments: 8927 Segment
Category: Experimental November 2020
ISSN: 2070-1721
JSON Type Definition
JSON型の定義
Abstract
概要
This document proposes a format, called JSON Type Definition (JTD), for describing the shape of JavaScript Object Notation (JSON) messages. Its main goals are to enable code generation from schemas as well as portable validation with standardized error indicators. To this end, JTD is intentionally limited to be no more expressive than the type systems of mainstream programming languages. This intentional limitation, as well as the decision to make JTD schemas be JSON documents, makes tooling atop of JTD easier to build.
この文書では、JavaScriptオブジェクト表記（JSON）メッセージの形状を説明するための、JSON型定義（JTD）と呼ばれるフォーマットを提案します。その主な目標は、スキーマからコード生成と標準化されたエラーインジケータを使用したポータブル検証を可能にすることです。この目的のために、JTDは意図的に主流のプログラミング言語の型システムよりも表現力がないように制限されています。この意図的な制限、ならびにJTDスキーマをJSON文書にするという決定は、JTDのツーリングを構築するのを容易にします。
This document does not have IETF consensus and is presented here to facilitate experimentation with the concept of JTD.
この文書はIETFの合意を持っていないため、JTDの概念を伴う実験を容易にするためにここに提示されています。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
この文書はインターネット標準のトラック仕様ではありません。検査、実験的実施、評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.
この文書は、インターネットコミュニティの実験的プロトコルを定義しています。これは、他のRFCストリームとは無関係にRFCシリーズへの貢献です。RFCエディタは、この文書を裁量で公開することを選択し、実装または展開のためのその値についてのステートメントを作成しません。RFCエディタによる出版の承認済みの文書は、インターネット規格のレベルレベルの候補者ではありません。RFC 7841のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8927.
この文書の現在のステータス、エラータ、およびフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc8927で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（C）2020 IETFの信頼と文書著者として識別された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書は、この文書の公開日に有効なIETF文書（https://truste.ietf.org/License-info）に関するBCP 78とIETF信頼の法的規定を受けています。この文書に関してあなたの権利と制限を説明するので、これらの文書を慎重に見直してください。
Table of Contents
目次
1. Introduction
1.1. Terminology
1.2. Scope of Experiment
2. Syntax
2.1. Root vs. Non-root Schemas
2.2. Forms
2.2.1. Empty
2.2.2. Ref
2.2.3. Type
2.2.4. Enum
2.2.5. Elements
2.2.6. Properties
2.2.7. Values
2.2.8. Discriminator
2.3. Extending JTD's Syntax
3. Semantics
3.1. Allowing Additional Properties
3.2. Errors
3.3. Forms
3.3.1. Empty
3.3.2. Ref
3.3.3. Type
3.3.4. Enum
3.3.5. Elements
3.3.6. Properties
3.3.7. Values
3.3.8. Discriminator
4. IANA Considerations
5. Security Considerations
6. References
6.1. Normative References
6.2. Informative References
Appendix A. Rationale for Omitted Features
A.1. Support for 64-Bit Numbers
A.2. Support for Non-root Definitions
Appendix B. Comparison with CDDL
Appendix C. Example
Acknowledgments
Author's Address
This document describes a schema language for JSON [RFC8259] called JSON Type Definition (JTD).
このドキュメントでは、JSON型定義（JTD）と呼ばれるJSON [RFC8259]のスキーマ言語について説明します。
There exist many options for describing JSON data. JTD's niche is to focus on enabling code generation from schemas; to this end, JTD's expressiveness is intentionally limited to be no more powerful than what can be expressed in the type systems of mainstream programming languages.
JSONデータを記述するための多くのオプションがあります。JTDのニッチは、スキーマからコード生成の有効化に焦点を当てることです。そのために、JTDの表現力は、主流のプログラミング言語のタイプシステムで表現できるものよりも強力ではないことを意図的に制限されています。
The goals of JTD are to:
JTDの目標は次のとおりです。
* Provide an unambiguous description of the overall structure of a JSON document.
* JSON文書の全体構造の明確な説明を提供します。
* Be able to describe common JSON data types and structures (that is, the data types and structures necessary to support most JSON documents and that are widely understood in an interoperable way by JSON implementations).
* 一般的なJSONデータ型と構造体（つまり、ほとんどのJSON文書をサポートするのに必要なデータ型と構造、およびJSON実装によって相互運用可能な方法で広く理解されている）を記述することができる。
* Provide a single format that is readable and editable by both humans and machines and that can be embedded within other JSON documents. This makes JTD a convenient format for tooling to accept as input or produce as output.
* 人間とマシンの両方で読みやすく編集可能な単一のフォーマットを指定し、他のJSON文書に埋め込むことができます。これにより、JTDは、入力として入出力として受け入れるためのツーリングの便利なフォーマットになります。
* Enable code generation from JTD schemas. JTD schemas are meant to be easy to convert into data structures idiomatic to mainstream programming languages.
* JTDスキーマからコード生成を有効にします。JTDスキーマは、メインストリームプログラミング言語に慣用のデータ構造に変換するのが簡単であることを意味しています。
* Provide a standardized format for error indicators when data does not conform with a schema.
* データがスキーマに準拠していない場合、エラーインジケータの標準化されたフォーマットを提供します。
JTD is intentionally designed as a rather minimal schema language. Thus, although JTD can describe some categories of JSON, it is not able to describe its own structure; this document uses Concise Data Definition Language (CDDL) [RFC8610] to describe JTD's syntax. By keeping the expressiveness of the schema language minimal, JTD makes code generation and standardized error indicators easier to implement.
JTDは意図的にかなり最小限のスキーマ言語として設計されています。したがって、JTDはJSONのいくつかのカテゴリを記述することができますが、それ自身の構造を記述することはできません。この文書では、JTDの構文を説明するには、簡潔なデータ定義言語（CDDL）[RFC8610]を使用しています。スキーマ言語の表現力を最小限に抑えることで、JTDはコード生成と標準化されたエラーインジケータを実装しやすくします。
Examples in this document use constructs from the C++ programming language. These examples are provided to aid the reader in understanding the principles of JTD but are not limiting in any way.
この文書の例では、Cプログラミング言語からの構文を使用しています。これらの例は、JTDの原則を理解する際に読者を助けるために提供されているが、決して限定的ではない。
JTD's feature set is designed to represent common patterns in JSON-using applications, while still having a clear correspondence to programming languages in widespread use. Thus, JTD supports:
JTDの機能セットは、JSON-USISHアプリケーションの一般的なパターンを表すように設計されていますが、広範囲に使用されているプログラミング言語にはまだ明確に対応しています。したがって、JTDは次のとおりです。
* Signed and unsigned 8-, 16-, and 32-bit integers. A tool that converts JTD schemas into code can use "int8_t", "uint8_t", "int16_t", etc., or their equivalents in the target language, to represent these JTD types.
* 署名されていない8-、16、および32ビットの整数。JTDスキーマをコードに変換するツールは、これらのJTDタイプを表すために、「INT8_T」、「UINT8_T」、「INT16_T」などをターゲット言語で使用することができます。
* A distinction between "float32" and "float64". Code generators can use "float" and "double", or their equivalents, for these JTD types.
* 「フロート32」と「フロート64」との間の区別。コードジェネレータは、これらのJTDタイプに対して「float」と「double」、またはそれらの均等物を使用できます。
* A "properties" form of JSON objects, corresponding to some sort of struct or record. The "properties" form of JSON objects is akin to a C++ "struct".
* ある種の構造体またはレコードに対応するJSONオブジェクトの「プロパティ」形式。JSONオブジェクトの「プロパティ」形式は、C "struct"に似ています。
* A "values" form of JSON objects, corresponding to some sort of dictionary or associative array. The "values" form of JSON objects is akin to a C++ "std::map".
* ある種の辞書または連想配列に対応するJSONオブジェクトの「値」形式。JSONオブジェクトの「値」形式は、C "STD :: Map"に似ています。
* A "discriminator" form of JSON objects, corresponding to a discriminated (or "tagged") union. The "discriminator" form of JSON objects is akin to a C++ "std::variant".
* 識別された（または「タグ付けされた」）連合に対応するJSONオブジェクトの「識別器」形式。JSONオブジェクトの「識別子」形式は、C "STD :: Variant"に似ています。
The principle of common patterns in JSON is why JTD does not support 64-bit integers, as these are usually transmitted over JSON in non-interoperable (i.e., ignoring the recommendations in Section 2.2 of [RFC7493]) or mutually inconsistent ways. Appendix A.1 further elaborates on why JTD does not support 64-bit integers.
JSONの一般的なパターンの原則は、JTDが64ビットの整数をサポートしていない理由です。これらは通常、JSON経由では通常JSON経由で送信されていません（すなわち、[RFC7493]のセクション2.2（RFC7493]の推奨事項）、または矛盾する方法での推奨事項を示しています。付録A.1 JTDが64ビットの整数をサポートしていない理由について詳しく説明します。
The principle of clear correspondence to common programming languages is why JTD does not support, for example, a data type for integers up to 2**53-1.
一般的なプログラミング言語に対する明確な対応の原則は、JTDが2 ** 53-1までの整数のデータ型をサポートしていない理由です。
It is expected that for many use cases, a schema language of JTD's expressiveness is sufficient. Where a more expressive language is required, alternatives exist in CDDL and others.
多くのユースケースでは、JTDの表現力のスキーマ言語が十分であると予想されます。より表現的な言語が必要な場合は、CDDLなどに代替案が存在します。
This document does not have IETF consensus and is presented here to facilitate experimentation with the concept of JTD. The purpose of the experiment is to gain experience with JTD and to possibly revise this work accordingly. If JTD is determined to be a valuable and popular approach, it may be taken to the IETF for further discussion and revision.
この文書はIETFの合意を持っていないため、JTDの概念を伴う実験を容易にするためにここに提示されています。実験の目的は、JTDで経験を積むことであり、それに応じてこの作業を修正することです。JTDが貴重で一般的なアプローチであると判断された場合、それはさらなる議論と改訂のためにIETFに連れて行かれるかもしれません。
This document has the following structure. Section 2 defines the syntax of JTD. Section 3 describes the semantics of JTD; this includes determining whether some data satisfies a schema and what error indicators should be produced when the data is unsatisfactory. Appendix A discusses why certain features are omitted from JTD. Appendix B presents various JTD schemas and their CDDL equivalents.
この文書には以下の構成があります。セクション2 JTDの構文を定義します。セクション3はJTDの意味論について説明しています。これには、データがスキーマを満たしているかどうか、データが満足できないときにどのエラーインジケータを生成するかを判断することが含まれます。付録Aでは、特定の機能がJTDから省略されている理由について説明します。付録Bは、さまざまなJTDスキーマとそのCDDLの同等物を表しています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
The term "JSON Pointer", when it appears in this document, is to be understood as it is defined in [RFC6901].
「JSONポインタ」という用語は、この文書に表示されるとき、[RFC6901]で定義されていると理解されるべきです。
The terms "object", "member", "array", "number", "name", and "string" in this document are to be interpreted as described in [RFC8259].
この文書の「オブジェクト」、「メンバー」、「配列」、「番号」、「名前」、「文字列」という用語は、[RFC8259]に記載されているように解釈されます。
The term "instance", when it appears in this document, refers to a JSON value being validated against a JTD schema. This value can be an entire JSON document, or it can be a value embedded within a JSON document.
「インスタンス」という用語は、このドキュメントに表示されると、JTDスキーマに対して検証されているJSON値を参照します。この値はJSON文書全体にすることも、JSON文書内に埋め込まれた値にすることもできます。
JTD is an experiment. Participation in this experiment consists of using JTD to validate or document interchanged JSON messages or building tooling atop of JTD. Feedback on the results of this experiment may be emailed to the author. Participants in this experiment are anticipated to mostly be nodes that provide or consume JSON-based APIs.
JTDは実験です。この実験への参加は、JTDを使用して、交換されたJSONメッセージやJTDの建築ツールの構築を検証または文書化することから成ります。この実験の結果に関するフィードバックは、作者に電子メールで送信される可能性があります。この実験の参加者は、JSONベースのAPIを提供または消費するノードであることが予想されています。
Nodes know if they are participating in the experiment if they are validating JSON messages against a JTD schema or if they are relying on another node to do so. Nodes are also participating in the experiment if they are running code generated from a JTD schema.
ノードは、JTDスキーマに対してJSONメッセージを検証している場合、または他のノードに依存している場合は、実験に参加しているか、またはそのようにする場合は知っています。ノードは、JTDスキーマから生成されたコードを実行している場合も、実験にも参加しています。
The risk of this experiment "escaping" takes the form of a JTD-supporting node expecting another node, which lacks such support, to validate messages against some JTD schema. In such a case, the outcome will likely be that the nodes fail to interchange information correctly.
この実験「エスケープ」のリスクは、いくつかのJTDスキーマに対するメッセージを検証するために、そのようなサポートを欠いている別のノードを期待しているJTDサポートノードの形式を取ります。そのような場合、結果は、ノードが情報を正しく交換できない可能性があります。
This experiment will be deemed successful when JTD has been implemented by multiple independent parties and these parties successfully use JTD to facilitate information interchange within their internal systems or between systems operated by independent parties.
この実験は、JTDが複数の独立した締約国によって実施されているときに成功したとみなされ、これらの当事者は、内部システム内の情報交換を促進するために、または独立した当事者によって運営されているシステム間での情報を促進するためにJTDを使用します。
If this experiment is deemed successful, and JTD is determined to be a valuable and popular approach, it may be taken to the IETF for further discussion and revision. One possible outcome of this discussion and revision could be that a working group produces a Standards Track specification of JTD.
この実験が成功したと見なされ、JTDは貴重で一般的なアプローチであると決定され、さらなる議論と改訂のためにIETFに連れて行かれることがあります。この議論および改訂の可能な結果の1つは、作業部会がJTDの標準トラック仕様を生産することであり得る。
Some implementations of JTD, as well as code generators and other tooling related to JTD, are available at <https://github.com/ jsontypedef>.
JTDの実装、およびJTDに関連するコードジェネレータやその他のツーリングの一部は、<https：//github.com/jsontypedef>で入手できます。
This section describes when a JSON document is a correct JTD schema. Because Concise Data Definition Language (CDDL) is well suited to the task of defining complex JSON formats, such as JTD schemas, this section uses CDDL to describe the format of JTD schemas.
このセクションでは、JSON文書が正しいJTDスキーマである状況について説明します。簡潔なデータ定義言語（CDDL）は、JTDスキーマなどの複雑なJSON形式を定義するタスクに適しているため、このセクションではCDDLを使用してJTDスキーマの形式を説明します。
JTD schemas may recursively contain other schemas. In this document, a "root schema" is one that is not contained within another schema, i.e., it is "top level".
JTDスキーマは、他のスキーマを再帰的に含めることができます。この文書では、「ルートスキーマ」は、他のスキーマ内に含まれていないもの、すなわち「トップレベル」である。
A JTD schema is a JSON object taking on an appropriate form. JTD schemas may contain "additional data", discussed in Section 2.3. Root JTD schemas may optionally contain definitions (a mapping from names to schemas).
JTDスキーマは適切なフォームを踏みてJSONオブジェクトです。JTDスキーマには、セクション2.3で説明した「追加データ」を含めることができます。ルートJTDスキーマはオプションで定義（名前からスキーマへのマッピング）を含みます。
A correct root JTD schema MUST match the "root-schema" CDDL rule described in this section. A correct non-root JTD schema MUST match the "schema" CDDL rule described in this section.
正しいルートJTDスキーマは、このセクションで説明されている「root-schema」CDDLルールと一致しなければなりません。正しいルート以外のJTDスキーマは、このセクションで説明されている「スキーマ」CDDLルールと一致する必要があります。
; root-schema is identical to schema, but additionally allows for
; definitions.
;
; definitions are prohibited from appearing on non-root schemas.
root-schema = {
? definitions: { * tstr => { schema}},
schema,
}
; schema is the main CDDL rule defining a JTD schema.
;
; All JTD schemas are JSON objects taking on one of eight forms
; listed here.
schema = (
ref //
type //
enum //
elements //
properties //
values //
discriminator //
empty //
)
; shared is a CDDL rule containing properties that all eight schema
; forms share.
shared = (
? metadata: { * tstr => any },
? nullable: bool,
)
; empty describes the "empty" schema form.
empty = shared
; ref describes the "ref" schema form.
;
; There are additional constraints on this form that cannot be
; expressed in CDDL. Section 2.2.2 describes these additional
; constraints in detail.
ref = ( ref: tstr, shared )
; type describes the "type" schema form.
type = (
type: "boolean"
/ "float32"
/ "float64"
/ "int8"
/ "uint8"
/ "int16"
/ "uint16"
/ "int32"
/ "uint32"
/ "string"
/ "timestamp",
shared,
)
; enum describes the "enum" schema form.
;
; There are additional constraints on this form that cannot be
; expressed in CDDL. Section 2.2.4 describes these additional
; constraints in detail.
enum = ( enum: [+ tstr], shared )
; elements describes the "elements" schema form.
elements = ( elements: { schema }, shared )
; properties describes the "properties" schema form.
;
; This CDDL rule is defined so that a schema of the "properties" form
; may omit a member named "properties" or a member named
; "optionalProperties", but not both.
;
; There are additional constraints on this form that cannot be
; expressed in CDDL. Section 2.2.6 describes these additional
; constraints in detail.
properties = (with-properties // with-optional-properties)
with-properties = (
properties: { * tstr => { schema }},
? optionalProperties: { * tstr => { schema }},
? additionalProperties: bool,
shared,
)
with-optional-properties = (
? properties: { * tstr => { schema }},
optionalProperties: { * tstr => { schema }},
? additionalProperties: bool,
shared,
)
; values describes the "values" schema form.
values = ( values: { schema }, shared )
; discriminator describes the "discriminator" schema form.
;
; There are additional constraints on this form that cannot be
; expressed in CDDL. Section 2.2.8 describes these additional
; constraints in detail.
discriminator = (
discriminator: tstr,
; Note well: this rule is defined in terms of the "properties"
; CDDL rule, not the "schema" CDDL rule.
mapping: { * tstr => { properties } }
shared,
)
Figure 1: CDDL Definition of a Schema
図1：スキーマのCDDL定義
The remainder of this section will describe constraints on JTD schemas that cannot be expressed in CDDL. It will also provide examples of valid and invalid JTD schemas.
このセクションの残りの部分は、CDDLで表現できないJTDスキーマの制約を説明します。有効なJTDスキーマと無効なJTDスキーマの例も提供します。
The "root-schema" rule in Figure 1 permits a member named "definitions", but the "schema" rule does not permit for such a member. This means that only root (i.e., "top-level") JTD schemas can have a "definitions" object, and subschemas may not.
図1の「root-schema」ルールは、「定義」という名前のメンバーを許可しますが、「スキーマ」ルールはそのようなメンバーを許可しません。これは、根（すなわち、「トップレベル」）JTDスキーマだけが「定義」オブジェクトを持つことができ、副概要ができないことを意味します。
Thus,
したがって、
{ "definitions": {} }
is a correct JTD schema, but
正しいJTDスキーマです
{
"definitions": {
"foo": {
"definitions": {}
}
}
}
is not, because subschemas (such as the object at "/definitions/foo") must not have a member named "definitions".
サブシーマ（「/ definitions / foo」のオブジェクトなど）に「定義」という名前のメンバーを持っていなければならないため、そうではありません。
JTD schemas (i.e., JSON objects satisfying the "schema" CDDL rule in Figure 1) must take on one of eight forms. These forms are defined so as to be mutually exclusive; a schema cannot satisfy multiple forms at once.
JTDスキーマ（すなわち、図1の「スキーマ」CDDL規則を満たすJSONオブジェクト）は、8つのフォームのうちの1つをとる必要があります。これらの形態は相互に排他的であるように定義されている。スキーマは一度に複数のフォームを満たすことはできません。
The "empty" form is defined by the "empty" CDDL rule in Figure 1. The semantics of the "empty" form are described in Section 3.3.1.
「空」フォームは、図1の「空」CDDL規則で定義されています。「空」フォームの意味論については、セクション3.3.1に記載されています。
Despite the name "empty", schemas of the "empty" form are not necessarily empty JSON objects. Like schemas of any of the eight forms, schemas of the "empty" form may contain members named "nullable" (whose value must be "true" or "false") or "metadata" (whose value must be an object) or both.
"空"という名前にもかかわらず、 "空の"フォームのスキーマは必ずしも空のJSONオブジェクトではありません。8つのフォームのいずれかのスキーマと同様に、「空」フォームのスキーマには、 "nullable"という名前のメンバー（その値が "true"または "false"）または "metadata"（その値がオブジェクトでなければならない）またはその両方を含みます。。
Thus,
したがって、
{}
{}
and
そして
{ "nullable": true }
and
そして
{ "nullable": true, "metadata": { "foo": "bar" }}
are correct JTD schemas of the "empty" form, but
「空」フォームの正しいJTDスキーマですが
{ "nullable": "foo" }
is not, because the value of the member named "nullable" must be "true" or "false".
「nullable」という名前のメンバーの値は "true"または "false"でなければならないためです。
The "ref" form is defined by the "ref" CDDL rule in Figure 1. The semantics of the "ref" form are described in Section 3.3.2.
「REF」フォームは、図1の「REF」CDDL規則によって定義されています。「REF」形式の意味は3.3.2節で説明されています。
For a schema of the "ref" form to be correct, the value of the member named "ref" must refer to one of the definitions found at the root level of the schema it appears in. More formally, for a schema _S_ of the "ref" form:
正しい「REF」フォームのスキーマの場合、 "ref"という名前のメンバーの値は、表示されているスキーマのルートレベルで見つかった定義の1つを参照しなければなりません。のスキーマ_s_"ref"フォーム：
* Let _B_ be the root schema containing the schema or the schema itself if it is a root schema.
* _b_をルートスキーマであれば、スキーマまたはスキーマ自体を含むルートスキーマにします。
* Let _R_ be the value of the member of _S_ with the name "ref".
* _R_を_s_のメンバーの値に名前 "REF"という名前の値にする。
If the schema is correct, then _B_ MUST have a member _D_ with the name "definitions", and _D_ MUST contain a member whose name equals _R_.
スキーマが正しい場合、_B_は「定義」という名前のメンバー_D_を持つ必要があり、_D_は名前が_R_に等しいメンバーを含める必要があります。
Thus,
したがって、
{
"definitions": {
"coordinates": {
"properties": {
"lat": { "type": "float32" },
"lng": { "type": "float32" }
}
}
},
"properties": {
"user_location": { "ref": "coordinates" },
"server_location": { "ref": "coordinates" }
}
}
is a correct JTD schema and demonstrates the point of the "ref" form: to avoid redefining the same thing twice. However,
正しいJTDスキーマであり、「Ref」フォームのポイントを示します。同じことを2回再定義しないようにします。しかしながら、
{ "ref": "foo" }
is not a correct JTD schema, as there are no top-level "definitions", and so the "ref" form cannot be correct. Similarly,
最上位の "定義"がないので、正しいJTDスキーマではなく、「Ref」フォームは正しくできません。同様に、
{ "definitions": { "foo": {}}, "ref": "bar" }
is not a correct JTD schema, as there is no member named "bar" in the top-level "definitions".
最上位の「定義」に「バー」という名前のメンバーがないため、正しいJTDスキーマではありません。
The "type" form is defined by the "type" CDDL rule in Figure 1. The semantics of the "type" form are described in Section 3.3.3.
「Type」フォームは、図1の「Type」CDDL規則で定義されています。「タイプ」形式のセマンティクスはセクション3.3.3で説明されています。
As an example of a correct JTD schema of the "type" form,
「タイプ」フォームの正しいJTDスキーマの例として、
{ "type": "uint8" }
is a correct JTD schema, whereas
正しいJTDスキーマですが、一方です
{ "type": true }
and
そして
{ "type": "foo" }
are not correct schemas, as neither "true" nor the JSON string "foo" are in the list of permitted values of the "type" member described in the "type" CDDL rule in Figure 1.
「true」もJSON文字列 "foo"も、図1の「Type」CDDL規則で説明されている「Type」メンバーの許容値のリストにある場合、正しいスキーマではありません。
The "enum" form is defined by the "enum" CDDL rule in Figure 1. The semantics of the "enum" form are described in Section 3.3.4.
「ENUM」フォームは、図1の「ENUM」CDDL規則によって定義されています。「enum」形式の意味は3.3.4項で説明されています。
For a schema of the "enum" form to be correct, the value of the member named "enum" must be a nonempty array of strings, and that array must not contain duplicate values. More formally, for a schema _S_ of the "enum" form:
「enum」フォームのスキーマが正しくなるためには、 "enum"という名前のメンバーの値は文字列の非区切り配列でなければならず、その配列は重複した値を含んではいけません。より正式には、 "enum"フォームのスキーマ_s_
* Let _E_ be the value of the member of _S_ with name "enum".
* _e_ _s_のメンバーの値 "enum"の値にする。
If the schema is correct, then there MUST NOT exist any pair of elements of _E_ that encode equal string values, where string equality is defined as in Section 8.3 of [RFC8259].
スキーマが正しい場合は、文字列の等価性が[RFC8259]のセクション8.3と同様に定義されている_E_の要素の一対の要素が存在してはなりません。
Thus,
したがって、
{ "enum": [] }
is not a correct JTD schema, as the value of the member named "enum" must be nonempty, and
「enum」という名前のメンバーの値はensettyでなければならないので、正しいJTDスキーマではありません。
{ "enum": ["a\\b", "a\u005Cb"] }
is not a correct JTD schema, as
正しいJTDスキーマではありません
"a\\b"
"a \\ b"
and
そして
"a\u005Cb"
"a \ u005cb"
encode strings that are equal by the definition of string equality given in Section 8.3 of [RFC8259]. By contrast,
[RFC8259]のセクション8.3で指定された文字列の平等の定義によって等しい文字列をエンコードします。対照的に、
{ "enum": ["PENDING", "IN_PROGRESS", "DONE" ]}
is an example of a correct JTD schema of the "enum" form.
"enum"フォームの正しいJTDスキーマの例です。
The "elements" form is defined by the "elements" CDDL rule in Figure 1. The semantics of the "elements" form are described in Section 3.3.5.
「要素」形式は、図1の「要素」CDDL規則によって定義されています。「要素」形式の意味はセクション3.3.5で説明されています。
As an example of a correct JTD schema of the "elements" form,
「要素」形式の正しいJTDスキーマの例として、
{ "elements": { "type": "uint8" }}
is a correct JTD schema, whereas
正しいJTDスキーマですが、一方です
{ "elements": true }
and
そして
{ "elements": { "type": "foo" } }
are not correct schemas, as neither
どちらのように正しいスキーマではありません
true
true
nor
nor
{ "type": "foo" }
are correct JTD schemas, and the value of the member named "elements" must be a correct JTD schema.
正しいJTDスキーマであり、「要素」というメンバーの値は正しいJTDスキーマである必要があります。
The "properties" form is defined by the "properties" CDDL rule in Figure 1. The semantics of the "properties" form are described in Section 3.3.6.
「プロパティ」フォームは、図1の「プロパティ」CDDL規則によって定義されています。「プロパティ」形式の意味は3.3.6項で説明されています。
For a schema of the "properties" form to be correct, properties must either be required (i.e., in "properties") or optional (i.e., in "optionalProperties"), but not both.
正しい「プロパティ」形式のスキーマの場合、プロパティは必要でなければならない（すなわち、「プロパティ」）、またはオプション（すなわち、「オプションプロパティ」）でも、両方ではない。
More formally, if a schema has both a member named "properties" (with value _P_) and another member named "optionalProperties" (with value _O_), then _O_ and _P_ MUST NOT have any member names in common; that is, no member of _P_ may have a name equal to the name of any member of _O_, under the definition of string equality given in Section 8.3 of [RFC8259].
より正式には、スキーマに「プロパティ」という名前のメンバー（値_p_）と「optionalproperties」（値_o_）という名前のメンバーがある場合は、_O_と_p_はメンバー名を共通にしてはいけません。つまり、[RFC8259]のセクション8.3で設定されている文字列の平等の定義の下、_P_のメンバーは_O_のメンバーの名前に等しい名前を持つことはできません。
Thus,
したがって、
{
"properties": { "confusing": {} },
"optionalProperties": { "confusing": {} }
}
is not a correct JTD schema, as "confusing" appears in both "properties" and "optionalProperties". By contrast,
正しいJTDスキーマではありませんが、「混乱」が「Properties」と「任意のプロパティ」の両方に表示されます。対照的に、
{
"properties": {
"users": {
"elements": {
"properties": {
"id": { "type": "string" },
"name": { "type": "string" },
"create_time": { "type": "timestamp" }
},
"optionalProperties": {
"delete_time": { "type": "timestamp" }
}
}
},
"next_page_token": { "type": "string" }
}
}
is a correct JTD schema of the "properties" form, describing a paginated list of users and demonstrating the recursive nature of the syntax of JTD schemas.
ユーザーのページ化されたリストを記述し、JTDスキーマの構文の再帰的性質を示す「プロパティ」形式の正しいJTDスキーマです。
The "values" form is defined by the "values" CDDL rule in Figure 1. The semantics of the "values" form are described in Section 3.3.7.
「値」形式は、図1の「値」CDDL規則で定義されています。「値」形式の意味はセクション3.3.7で説明されています。
As an example of a correct JTD schema of the "values" form,
「値」形式の正しいJTDスキーマの例として、
{ "values": { "type": "uint8" }}
is a correct JTD schema, whereas
正しいJTDスキーマですが、一方です
{ "values": true }
and
そして
{ "values": { "type": "foo" } }
are not correct schemas, as neither
どちらのように正しいスキーマではありません
true
true
nor
nor
{ "type": "foo" }
are correct JTD schemas, and the value of the member named "values" must be a correct JTD schema.
正しいJTDスキーマであり、「値」という名前のメンバーの値は正しいJTDスキーマでなければなりません。
The "discriminator" form is defined by the "discriminator" CDDL rule in Figure 1. The semantics of the "discriminator" form are described in Section 3.3.8. Understanding the semantics of the "discriminator" form will likely aid the reader in understanding why this section provides constraints on the "discriminator" form beyond those in Figure 1.
「識別器」形式は、図1の「識別器」CDDL規則によって定義されています。「差別器」形式の意味論については、セクション3.3.8に記載されています。「弁別器」フォームの意味論を理解すると、このセクションが図1のものを超えて「差別器」形式に対する制約を提供する理由を理解することで、読者に援助を受けます。
To prevent ambiguous or unsatisfiable constraints on the "discriminator" property of a tagged union, an additional constraint on schemas of the "discriminator" form exists. For schemas of the "discriminator" form:
タグ付き共用体の「識別子」プロパティに対するあいまいなまたは不満足な制約を防ぐために、「識別子」形式のスキーマに対する追加の制約が存在します。「弁別器」フォームのスキーマの場合：
* Let _D_ be the member of the schema with the name "discriminator".
* 「弁別器」という名前のスキーマのメンバーに_D_を取得します。
* Let _M_ be the member of the schema with the name "mapping".
* 「マッピング」という名前のスキーマのメンバーに_m_を使用します。
If the schema is correct, then all member values _S_ of _M_ will be schemas of the "properties" form. For each _S_:
スキーマが正しい場合は、_m_のすべてのメンバー値_s_が "Properties"フォームのスキーマになります。各_s_の場合：
* If _S_ has a member _N_ whose name equals "nullable", _N_'s value MUST NOT be the JSON primitive value "true".
* _s_がメンバー_n_が "nullable"に等しい場合、_n_の値はJSONプリミティブ値 "true"であってはいけません。
* For each member _P_ of _S_ whose name equals "properties" or "optionalProperties", _P_'s value, which must be an object, MUST NOT contain any members whose name equals _D_'s value.
* その名前のメンバー_p_の各名前は、「プロパティ」または「任意プロパティ」、オブジェクトでなければならない_p_の値を、名前が_D_の値に等しいメンバーを含んではいけません。
Thus,
したがって、
{
"discriminator": "event_type",
"mapping": {
"can_the_object_be_null_or_not?": {
"nullable": true,
"properties": { "foo": { "type": "string" } }}
}
}
}
is an incorrect schema, as a member of "mapping" has a member named "nullable" whose value is "true". This would suggest that the instance may be null. Yet, the top-level schema lacks such a "nullable" set to "true", which would suggest that the instance in fact cannot be null. If this were a correct JTD schema, it would be unclear which piece of information takes precedence.
「マッピング」のメンバーには、その値が "true"のメンバーが "nullable"というメンバーがあるため、誤ったスキーマです。これは、インスタンスがnullになる可能性があることを示唆します。それでも、最上位のスキーマは、そのような「nullable」が「true」に設定されています。これは、実際のインスタンスがNULLになれないことを示唆しています。これが正しいJTDスキーマであれば、どの情報の一部が優先されるかは不明です。
JTD handles such possible ambiguity by disallowing, at the syntactic level, the possibility of contradictory specifications of whether an instance described by a schema of the "discriminator" form may be null. The schemas in a discriminator "mapping" cannot have "nullable" set to "true"; only the discriminator itself can use "nullable" in this way.
JTDは、構文レベルでは、「識別子」フォームのスキーマによって記述されたインスタンスがNULLになる可能性があるかどうかの矛盾する仕様の可能性を禁止することで、可能な可能性がある可能性があります。識別子の「マッピング」のスキーマは「NULLABLE」を「TRUE」に設定することはできません。このようにして、識別子自体だけが「nullable」を使用することができます。
It also follows that
それはまたそれに続く
{
"discriminator": "event_type",
"mapping": {
"is_event_type_a_string_or_a_float32?": {
"properties": { "event_type": { "type": "float32" }}
}
}
}
and
そして
{
"discriminator": "event_type",
"mapping": {
"is_event_type_a_string_or_an_optional_float32?": {
"optionalProperties": { "event_type": { "type": "float32" }}
}
}
}
are incorrect schemas, as "event_type" is both the value of "discriminator" and a member name in one of the "mapping" member "properties" or "optionalProperties". This is ambiguous, because ordinarily the "discriminator" keyword would indicate that "event_type" is expected to be a string, but another part of the schema specifies that "event_type" is expected to be a number.
「event_type」は、「識別子」の値と「マッピング」メンバー「プロパティ」または「オプションプロパティ」の両方の値であるため、誤ったスキーマです。通常、 "識別子"キーワードは "event_type"が文字列であると予想されることを示しているので、これはあいまいですが、スキーマのもう1つの部分は "event_type"が数値になると予想されることを指定します。
JTD handles such possible ambiguity by disallowing, at the syntactic level, the possibility of contradictory specifications of discriminator "tags". Discriminator "tags" cannot be redefined in other parts of the schema.
JTDは、構文レベルでは、識別子の「タグ」の矛盾する仕様の可能性を禁止することで、可能な可能性のあるあいまいさを処理します。弁別器「タグ」は、スキーマの他の部分では再定義できません。
By contrast,
対照的に、
{
"discriminator": "event_type",
"mapping": {
"account_deleted": {
"properties": {
"account_id": { "type": "string" }
}
},
"account_payment_plan_changed": {
"properties": {
"account_id": { "type": "string" },
"payment_plan": { "enum": ["FREE", "PAID"] }
},
"optionalProperties": {
"upgraded_by": { "type": "string" }
}
}
}
}
is a correct schema, describing a pattern of data common in JSON-based messaging systems. Section 3.3.8 provides examples of what this schema accepts and rejects.
JSONベースのメッセージングシステムで共通のデータのパターンを説明する正しいスキーマです。セクション3.3.8に、このスキーマが受け入れて拒否する例を示します。
This document does not describe any extension mechanisms for JTD schema validation, which is described in Section 3. However, schemas are defined to optionally contain a "metadata" keyword, whose value is an arbitrary JSON object. Call the members of this object "metadata members".
この文書では、セクション3で説明されているJTDスキーマ検証の拡張メカニズムについては説明していません。ただし、スキーマはオプションで "Metadata"キーワードを含みます。その値は任意のJSONオブジェクトです。このオブジェクトのメンバー「メタデータメンバー」を呼び出します。
Users MAY add metadata members to JTD schemas to convey information that is not pertinent to validation. For example, such metadata members could provide hints to code generators or trigger some special behavior for a library that generates user interfaces from schemas.
ユーザーは、検証に適切な情報を伝えるためにJTDスキーマにメタデータメンバーを追加することができます。たとえば、そのようなメタデータメンバーは、ヒントをコードジェネレータに提供することも、スキーマからユーザーインターフェイスを生成するライブラリのための特別な動作を引き起こすか、またはそのいくつかの特別な動作を引き起こす可能性があります。
Users SHOULD NOT expect metadata members to be understood by other parties. As a result, if consistent validation with other parties is a requirement, users MUST NOT use metadata members to affect how schema validation, as described in Section 3, works.
ユーザーは、メタデータメンバーが他の当事者によって理解されることを期待しないでください。その結果、他の当事者との一貫した検証が要件であれば、セクション3で説明されているように、メタデータメンバーをスキーマの検証に影響を与えるためにメタデータメンバーを使用しないでください。
Users MAY expect metadata members to be understood by other parties and MAY use metadata members to affect how schema validation works, if these other parties are somehow known to support these metadata members. For example, two parties may agree, out of band, that they will support an extended JTD with a custom metadata member that affects validation.
ユーザーはメタデータメンバーが他の当事者によって理解されることを期待することができ、メタデータメンバーを使用してスキーマの検証の仕組みは、どういうわけかこれらのメタデータメンバーをサポートすることが知られているかどうかに影響を与える可能性があります。たとえば、2つの締約国が帯域外に同意することができます。これは、検証に影響を与えるカスタムメタデータメンバーを持つ拡張JTDをサポートします。
This section describes when an instance is valid against a correct JTD schema and the error indicators to produce when an instance is invalid.
このセクションでは、インスタンスが正しいJTDスキーマに対して有効な場合、およびインスタンスが無効なときに生成するエラーインジケータを次のように説明します。
Users will have different desired behavior with respect to "unspecified" members in an instance. For example, consider the JTD schema in Figure 2:
ユーザーは、インスタンス内の「不特定」メンバーに関して異なる望ましい行動を持ちます。たとえば、図2のJTDスキーマを考えてみましょう。
{ "properties": { "a": { "type": "string" }}}
Figure 2: An Illustrative JTD Schema
図2：例示的なJTDスキーマ
Some users may expect that
何人かのユーザーがそれを期待するかもしれません
{"a": "foo", "b": "bar"}
satisfies the schema in Figure 2. Others may disagree, as "b" is not one of the properties described in the schema. In this document, allowing such "unspecified" members, like "b" in this example, happens when evaluation is in "allow additional properties" mode.
図2のスキーマを満たしています。この他のものは、「b」がスキーマに記述されているプロパティの1つではないため、同意することができます。この文書では、この例では "B"のような「未指定」メンバーが、評価が「追加のプロパティを許可する」モードになっている場合に発生します。
Evaluation of a schema does not allow additional properties by default, but this can be overridden by having the schema include a member named "additionalProperties", where that member has a value of "true".
スキーマの評価はデフォルトで追加のプロパティを許可しませんが、このメンバが "true"の値を持つメンバーが含まれている場合、これは上書きされる可能性があります。
More formally, evaluation of a schema _S_ is in "allow additional properties" mode if there exists a member of _S_ whose name equals "additionalProperties" and whose value is a boolean "true". Otherwise, evaluation of _S_ is not in "allow additional properties" mode.
より正式には、スキーマ_s_の評価は「追加プロパティを許可する」モードで、その名前が「追加プロパティ」に等しいメンバが存在し、その値がブール値「true」である場合には、_S_のメンバが存在する場合に存在する。それ以外の場合、_s_の評価は「追加のプロパティを許可する」モードにはなりません。
See Section 3.3.6 for how allowing unknown properties affects schema evaluation, but briefly, the schema
未知のプロパティがスキーマ評価に影響を与える方法については、3.3.6項を参照してください。
{ "properties": { "a": { "type": "string" }}}
rejects
拒絶する
{ "a": "foo", "b": "bar" }
However, the schema
しかし、スキーマ
{
"additionalProperties": true,
"properties": { "a": { "type": "string" }}
}
accepts
accept accept
{ "a": "foo", "b": "bar" }
Note that "additionalProperties" does not get "inherited" by subschemas. For example, the JTD schema
SubsChemasによって「追加プロパティー」が「継承」しないことに注意してください。たとえば、JTDスキーマ
{
"additionalProperties": true,
"properties": {
"a": {
"properties": {
"b": { "type": "string" }
}
}
}
}
accepts
accept accept
{ "a": { "b": "c" }, "foo": "bar" }
but rejects
しかし拒絶する
{ "a": { "b": "c", "foo": "bar" }}
because the "additionalProperties" at the root level does not affect the behavior of subschemas.
ルートレベルの「追加プロパティ」はサブスキーマの動作に影響を与えないためです。
Note from Figure 1 that only schemas of the "properties" form may have a member named "additionalProperties".
注1から、「プロパティ」フォームのスキーマだけが「追加プロパティー」という名前のメンバーを持つことができます。
To facilitate consistent validation error handling, this document specifies a standard error indicator format. Implementations SHOULD support producing error indicators in this standard form.
一貫した検証エラー処理を容易にするために、このドキュメントは標準のエラーインジケータフォーマットを指定します。実装は、この標準形式でエラーインジケータの生成をサポートする必要があります。
The standard error indicator format is a JSON array. The order of the elements of this array is not specified. The elements of this array are JSON objects with:
標準エラーインジケータフォーマットはJSONアレイです。この配列の要素の順序は指定されていません。この配列の要素は、以下のJSONオブジェクトです。
* A member with the name "instancePath", whose value is a JSON string encoding a JSON Pointer. This JSON Pointer will point to the part of the instance that was rejected.
* "instancepath"という名前のメンバー。その値は、JSONポインタをエンコードするJSON文字列です。このJSONポインタは、拒否されたインスタンスの一部を指します。
* A member with the name "schemaPath", whose value is a JSON string encoding a JSON Pointer. This JSON Pointer will point to the part of the schema that rejected the instance.
* "schemapath"という名前のメンバー。その値がJSONポインタをエンコードするJSON文字列です。このJSONポインタは、インスタンスを拒否したスキーマの一部を指します。
The values for "instancePath" and "schemaPath" depend on the form of the schema and are described in detail in Section 3.3.
"instancepath"と "schemapath"の値はスキーマの形式に依存し、セクション3.3で詳しく説明されています。
This section describes, for each of the eight JTD schema forms, the rules dictating whether an instance is accepted, as well as the error indicators to produce when an instance is invalid.
このセクションでは、8つのJTDスキーマ形式のそれぞれについて、インスタンスが受け入れられているかどうかを決定する規則、およびインスタンスが無効なときに生成するエラーインジケータが説明されています。
The forms a correct schema may take on are formally described in Section 2.
正しいスキーマを形成することができる。
The "empty" form is meant to describe instances whose values are unknown, unpredictable, or otherwise unconstrained by the schema. The syntax of the "empty" form is described in Section 2.2.1.
「空」フォームは、そのスキーマによって、値が不明、予測不可能な、またはその他の方法では制約がないインスタンスを記述することを目的としています。「空」形式の構文は、セクション2.2.1で説明されています。
If a schema is of the "empty" form, then it accepts all instances. A schema of the "empty" form will never produce any error indicators.
スキーマが「空」フォームの場合は、すべてのインスタンスを受け入れます。「空」フォームのスキーマは、エラーインジケータを生成することはありません。
The "ref" form is for when a schema is defined in terms of something in the "definitions" of the root schema. The "ref" form enables schemas to be less repetitive and also enables describing recursive structures. The syntax of the "ref" form is described in Section 2.2.2.
「REF」フォームは、ルートスキーマの「定義」内の何かに関してスキーマが定義されているときのものです。「REF」フォームは、スキーマが繰り返しのないことを可能にし、また再帰的構造を説明することを可能にします。「REF」形式の構文は2.2.2項に記載されています。
If a schema is of the "ref" form, then:
スキーマが "ref"フォームの場合、次のようにします。
* If the schema has a member named "nullable" whose value is the boolean "true", and the instance is the JSON primitive value "null", then the schema accepts the instance.
* スキーマに「nullable」という名前のメンバがある場合、その値がboolean "true"で、インスタンスがJSONプリミティブ値 "null"である場合、スキーマはインスタンスを受け入れます。
Otherwise:
さもないと：
- Let _R_ be the value of the schema member with the name "ref".
- _r_をスキーマメンバーの値に "REF"という名前にする。
- Let _B_ be the root schema containing the schema or the schema itself if it is a root schema.
- _b_をルートスキーマであれば、スキーマまたはスキーマ自体を含むルートスキーマにします。
- Let _D_ be the member of _B_ with the name "definitions". Per Section 2, we know _D_ exists.
- ______________________________________________________________________________________________セクション2ごとに、_D_が存在することがわかります。
- Let _S_ be the value of the member of _D_ whose name equals _R_. Per Section 2.2.2, we know _S_ exists and is a schema.
- 名前が_r_に等しい_d_のメンバーの値を_s_させます。セクション2.2.2ごとに、_S_が存在することを知っていて、スキーマです。
The schema accepts the instance if and only if _S_ accepts the instance. Otherwise, the error indicators to return in this case are the union of the error indicators from evaluating _S_ against the instance.
スキーマは、_s_の場合に限り、インスタンスを受け入れる場合に限り、インスタンスを受け入れます。それ以外の場合、この場合に戻るエラーインジケータは、インスタンスに対して_S_を評価することのエラーインジケータの共用体です。
For example, the schema
たとえば、スキーマ
{
"definitions": { "a": { "type": "float32" }},
"ref": "a"
}
accepts
accept accept
123
123
but rejects
しかし拒絶する
null
ヌル
with the error indicator
エラーインジケータを使って
[{ "instancePath": "", "schemaPath": "/definitions/a/type" }]
The schema
スキーマ
{
"definitions": { "a": { "type": "float32" }},
"ref": "a",
"nullable": true
}
accepts
accept accept
null
ヌル
because the schema has a "nullable" member whose value is "true".
スキーマには、その値が "true"の "nullable"メンバーがあるからです。
Note that "nullable" being "false" has no effect in any of the forms described in this document. For example, the schema
"false"である "nullable"は、この文書に記載されている形式のいずれにも効果がありません。たとえば、スキーマ
{
"definitions": { "a": { "nullable": false, "type": "float32" }},
"ref": "a",
"nullable": true
}
accepts
accept accept
null
ヌル
In other words, it is not the case that putting a "false" value for "nullable" will ever override a "nullable" member in schemas of the "ref" form; it is correct, though ineffectual, to have a value of "false" for the "nullable" member in a schema.
つまり、「NULLABLE」に「false」値を入れることは、「REF」フォームのスキーマに「NULL可能な」メンバを上書きすることはそうではありません。スキーマ内の「nullable」メンバに対して「false」という値を持つように、無効ではありません。
The "type" form is meant to describe instances whose value is a boolean, number, string, or timestamp [RFC3339]. The syntax of the "type" form is described in Section 2.2.3.
「Type」フォームは、値がブール値、数、文字列、またはタイムスタンプ[RFC3339]であるインスタンスを記述することを意味します。「タイプ」形式の構文は、セクション2.2.3で説明されています。
If a schema is of the "type" form, then:
スキーマが「タイプ」フォームの場合は、次のようにします。
* If the schema has a member named "nullable" whose value is the boolean "true", and the instance is the JSON primitive value "null", then the schema accepts the instance.
* スキーマに「nullable」という名前のメンバがある場合、その値がboolean "true"で、インスタンスがJSONプリミティブ値 "null"である場合、スキーマはインスタンスを受け入れます。
Otherwise:
さもないと：
Let _T_ be the value of the member with the name "type". The following table describes whether the instance is accepted, as a function of _T_'s value:
_T_を「Type」という名前のメンバーの値にする。次の表は、インスタンスが_t_の値の関数として受け入れられているかどうかを示しています。
+============+=========================================+
| If _"T"_ | then the instance is accepted if it is |
| equals ... | ... |
+============+=========================================+
| boolean | equal to "true" or "false" |
+------------+-----------------------------------------+
| float32 | a JSON number |
+------------+-----------------------------------------+
| float64 | a JSON number |
+------------+-----------------------------------------+
| int8 | See Table 2 |
+------------+-----------------------------------------+
| uint8 | See Table 2 |
+------------+-----------------------------------------+
| int16 | See Table 2 |
+------------+-----------------------------------------+
| uint16 | See Table 2 |
+------------+-----------------------------------------+
| int32 | See Table 2 |
+------------+-----------------------------------------+
| uint32 | See Table 2 |
+------------+-----------------------------------------+
| string | a JSON string |
+------------+-----------------------------------------+
| timestamp | a JSON string that follows the standard |
| | format described in [RFC3339], as |
| | refined by Section 3.3 of [RFC4287] |
+------------+-----------------------------------------+
Table 1: Accepted Values for Type
表1：タイプの受け入れ値
"float32" and "float64" are distinguished from each other in their intent. "float32" indicates data intended to be processed as an IEEE 754 single-precision float, whereas "float64" indicates data intended to be processed as an IEEE 754 double-precision float. Tools that generate code from JTD schemas will likely produce different code for "float32" than for "float64".
「フロート32」と「FLOOT64」は、その意図で互いに区別されています。「float32」は、IEEE 754単精度フロートとして処理されることを意図したデータを示し、「FLOOT64」は、IEEE 754倍精度浮遊物として処理されることを意図したデータを示す。JTDスキーマからコードを生成するツールは、 "float64"よりも "float32"のための異なるコードを生成するでしょう。
If _T_ starts with "int" or "uint", then the instance is accepted if and only if it is a JSON number encoding a value with zero fractional part. Depending on the value of _T_, this encoded number must additionally fall within a particular range:
_t_が "int"または "uint"で始まる場合、そのインスタンスは、ゼロ部分部分を持つ値をエンコードするJSON番号の場合に限り、インスタンスは受け入れられます。_t_の値に応じて、この符号化された数はさらに特定の範囲内に入る必要があります。
+========+===========================+===========================+
| _"T"_ | Minimum Value (Inclusive) | Maximum Value (Inclusive) |
+========+===========================+===========================+
| int8 | -128 | 127 |
+--------+---------------------------+---------------------------+
| uint8 | 0 | 255 |
+--------+---------------------------+---------------------------+
| int16 | -32,768 | 32,767 |
+--------+---------------------------+---------------------------+
| uint16 | 0 | 65,535 |
+--------+---------------------------+---------------------------+
| int32 | -2,147,483,648 | 2,147,483,647 |
+--------+---------------------------+---------------------------+
| uint32 | 0 | 4,294,967,295 |
+--------+---------------------------+---------------------------+
Table 2: Ranges for Integer Types
表2：整数型の範囲
Note that
ご了承ください
10
10.
and
そして
10.0
10.0
and
そして
1.0e1
1.0e1
encode values with zero fractional part, whereas
ゼロ小数部で値をエンコードします
10.5
10.5
encodes a number with a non-zero fractional part. Thus, the schema
ゼロ以外の小数部分で数値を符号化します。したがって、スキーマ
{"type": "int8"}
accepts
accept accept
10
10.
and
そして
10.0
10.0
and
そして
1.0e1
1.0e1
but rejects
しかし拒絶する
10.5
10.5
as well as
及び
false
false
because "false" is not a number at all.
"false"はまったく数字ではありません。
If the instance is not accepted, then the error indicator for this case shall have an "instancePath" pointing to the instance and a "schemaPath" pointing to the schema member with the name "type".
インスタンスが受け入れられていない場合、この場合のエラーインジケータには、インスタンスを指す「Insempath」と「type」という名前のスキーマ・メンバーを指す「schemapath」があります。
For example, the schema
たとえば、スキーマ
{"type": "boolean"}
accepts
accept accept
false
false
but rejects
しかし拒絶する
127
127
The schema
スキーマ
{"type": "float32"}
accepts
accept accept
10.5
10.5
and
そして
127
127
but rejects
しかし拒絶する
false
false
The schema
スキーマ
{"type": "string"}
accepts
accept accept
"1985-04-12T23:20:50.52Z"
"1985-04-12t23：20：50.52z"
and
そして
"foo"
"foo"
but rejects
しかし拒絶する
false
false
The schema
スキーマ
{"type": "timestamp"}
accepts
accept accept
"1985-04-12T23:20:50.52Z"
"1985-04-12t23：20：50.52z"
but rejects
しかし拒絶する
"foo"
"foo"
and
そして
false
false
The schema
スキーマ
{"type": "boolean", "nullable": true}
accepts
accept accept
null
ヌル
and
そして
false
false
but rejects
しかし拒絶する
127
127
In all of the examples of rejected instances given in this section, the error indicator to produce is:
このセクションで指定された拒否されたインスタンスの例として、生成するエラーインジケータは次のとおりです。
[{ "instancePath": "", "schemaPath": "/type" }]
The "enum" form is meant to describe instances whose value must be one of a given set of string values. The syntax of the "enum" form is described in Section 2.2.4.
「enum」フォームは、値が指定された文字列値のセットのうちの1つでなければならないインスタンスを記述することを意味します。「enum」形式の構文は、2.2.4項で説明されています。
If a schema is of the "enum" form, then:
スキーマが "enum"フォームの場合、次のようにします。
* If the schema has a member named "nullable" whose value is the boolean "true", and the instance is the JSON primitive value "null", then the schema accepts the instance.
* スキーマに「nullable」という名前のメンバがある場合、その値がboolean "true"で、インスタンスがJSONプリミティブ値 "null"である場合、スキーマはインスタンスを受け入れます。
Otherwise:
さもないと：
Let _E_ be the value of the schema member with the name "enum". The instance is accepted if and only if it is equal to one of the elements of _E_.
_e_をスキーマメンバーの値に "enum"という名前にする。インスタンスは、_e_の要素の1つに等しい場合に限り、インスタンスは受け入れられます。
If the instance is not accepted, then the error indicator for this case shall have an "instancePath" pointing to the instance and a "schemaPath" pointing to the schema member with the name "enum".
インスタンスが受け入れられていない場合、この場合のエラーインジケータには、インスタンスを指す「Insempath」と「enum」という名前のスキーマ・メンバーを指す「Schemapath」があります。
For example, the schema
たとえば、スキーマ
{ "enum": ["PENDING", "DONE", "CANCELED"] }
accepts
accept accept
"PENDING"
"保留中"
and
そして
"DONE"
"完了"
and
そして
"CANCELED"
"キャンセル"
but rejects all of
しかし、すべてを拒否します
0
0
and
そして
1
1
and
そして
2
2.
and
そして
"UNKNOWN"
"わからない"
and
そして
null
ヌル
with the error indicator
エラーインジケータを使って
[{ "instancePath": "", "schemaPath": "/enum" }]
The schema
スキーマ
{ "enum": ["PENDING", "DONE", "CANCELED"], "nullable": true }
accepts
accept accept
"PENDING"
"保留中"
and
そして
null
ヌル
but rejects
しかし拒絶する
1
1
and
そして
"UNKNOWN"
"わからない"
with the error indicator
エラーインジケータを使って
[{ "instancePath": "", "schemaPath": "/enum" }]
The "elements" form is meant to describe instances that must be arrays. A further subschema describes the elements of the array. The syntax of the "elements" form is described in Section 2.2.5.
「要素」フォームは、配列でなければならないインスタンスを記述するためのものです。さらなるサブシーマは、配列の要素を記述します。「要素」形式の構文は、セクション2.2.5で説明されています。
If a schema is of the "elements" form, then:
スキーマが「要素」フォームの場合は、次のようにします。
* If the schema has a member named "nullable" whose value is the boolean "true", and the instance is the JSON primitive value "null", then the schema accepts the instance.
* スキーマに「nullable」という名前のメンバがある場合、その値がboolean "true"で、インスタンスがJSONプリミティブ値 "null"である場合、スキーマはインスタンスを受け入れます。
Otherwise:
さもないと：
Let _S_ be the value of the schema member with the name "elements". The instance is accepted if and only if all of the following are true:
_s_をスキーマメンバーの値に "要素"という名前にする。次のすべてが当てはまる場合に限り、インスタンスは受け入れられます。
o The instance is an array. Otherwise, the error indicator for this case shall have an "instancePath" pointing to the instance and a "schemaPath" pointing to the schema member with the name "elements".
o インスタンスは配列です。それ以外の場合、この場合のエラーインジケータは、インスタンスを指す「instancepath」と、「要素」という名前のスキーマメンバーを指す「Schemapath」を持ちます。
o If the instance is an array, then every element of the instance must be accepted by _S_. Otherwise, the error indicators for this case are the union of all the errors arising from evaluating _S_ against elements of the instance.
o インスタンスが配列の場合、インスタンスのすべての要素は_s_によって受け入れる必要があります。それ以外の場合、この場合のエラーインジケータは、インスタンスの要素に対して_S_を評価することから生じるすべてのエラーの共用体です。
For example, the schema
たとえば、スキーマ
{
"elements": {
"type": "float32"
}
}
accepts
accept accept
[]
[]
and
そして
[1, 2, 3]
[1,2,3]
but rejects
しかし拒絶する
null
ヌル
with the error indicator
エラーインジケータを使って
[{ "instancePath": "", "schemaPath": "/elements" }]
and rejects
そして拒否します
[1, 2, "foo", 3, "bar"]
[1,2、 "Foo"、3、 "Bar"]
with the error indicators
エラーインジケータを使って
[
{ "instancePath": "/2", "schemaPath": "/elements/type" },
{ "instancePath": "/4", "schemaPath": "/elements/type" }
]
The schema
スキーマ
{
"elements": {
"type": "float32"
},
"nullable": true
}
accepts
accept accept
null
ヌル
and
そして
[]
[]
and
そして
[1, 2, 3]
[1,2,3]
but rejects
しかし拒絶する
[1, 2, "foo", 3, "bar"]
[1,2、 "Foo"、3、 "Bar"]
with the error indicators
エラーインジケータを使って
[
{ "instancePath": "/2", "schemaPath": "/elements/type" },
{ "instancePath": "/4", "schemaPath": "/elements/type" }
]
The "properties" form is meant to describe JSON objects being used as a "struct". The syntax of the "properties" form is described in Section 2.2.6.
「プロパティ」フォームは、 "struct"として使用されているJSONオブジェクトを説明することを意味します。「プロパティ」形式の構文は、セクション2.2.6で説明されています。
If a schema is of the "properties" form, then:
スキーマが "Properties"フォームの場合は、次のようにします。
* If the schema has a member named "nullable" whose value is the boolean "true", and the instance is the JSON primitive value "null", then the schema accepts the instance.
* スキーマに「nullable」という名前のメンバがある場合、その値がboolean "true"で、インスタンスがJSONプリミティブ値 "null"である場合、スキーマはインスタンスを受け入れます。
Otherwise:
さもないと：
- The instance must be an object.
- インスタンスはオブジェクトである必要があります。
Otherwise, the schema rejects the instance. The error indicator for this case shall have an "instancePath" pointing to the instance, and a "schemaPath" pointing to the schema member with the name "properties" if such a schema member exists; if such a member doesn't exist, "schemaPath" shall point to the schema member with the name "optionalProperties".
それ以外の場合、スキーマはインスタンスを拒否します。この場合のエラーインジケータには、インスタンスを指す「instancepath」と、そのようなスキーマメンバーが存在する場合は「プロパティ」という名前のスキーマ・メンバーを指す「schemapath」があります。そのようなメンバーが存在しない場合、 "schemapath"は "optionalproperties"という名前のスキーマメンバーを指すものとします。
- If the instance is an object, and the schema has a member named "properties", then let _P_ be the value of the schema member named "properties". Per Section 2.2.6, we know _P_ is an object. For every member name in _P_, a member of the same name in the instance must exist.
- インスタンスがオブジェクトの場合、スキーマに「プロパティ」という名前のメンバーがある場合は、_p_を「プロパティ」という名前のスキーマメンバーの値にしてください。セクション2.2.6では、_p_がオブジェクトであることを知っています。_P_のすべてのメンバー名に対して、インスタンス内の同じ名前のメンバーが存在している必要があります。
Otherwise, the schema rejects the instance. The error indicator for this case shall have an "instancePath" pointing to the instance, and a "schemaPath" pointing to the member of _P_ failing the requirement just described.
それ以外の場合、スキーマはインスタンスを拒否します。この場合のエラーインジケータは、インスタンスを指す「InstancePath」を持ち、_P_のメンバーを指す「Schemapath」を持たなければなりません。
- If the instance is an object, then let _P_ be the value of the schema member named "properties" (if it exists) and _O_ be the value of the schema member named "optionalProperties" (if it exists).
- インスタンスがオブジェクトの場合は、_p_を「プロパティ」（存在する場合）と_o_が "optionalproperties"という名前のスキーマメンバの値である（存在する場合）。
For every member _I_ of the instance, find a member with the same name as _I_'s in _P_ or _O_. Per Section 2.2.6, we know it is not possible for both _P_ and _O_ to have such a member. If the "discriminator tag exemption" is in effect on _I_ (see Section 3.3.8), then ignore _I_.
インスタンスのメンバー_i_ごとに、_p_または_O_の_i_と同じ名前のメンバーを見つけます。セクション2.2.6によると、_P_と_O_の両方がそのようなメンバーを持つことができないことがわかります。「識別タグ免除」が_I_（セクション3.3.8を参照）に有効である場合は、_I_を無視してください。
Otherwise:
さもないと：
o If no such member in _P_ or _O_ exists and validation is not in "allow additional properties" mode (see Section 3.1), then the schema rejects the instance.
o _P_または_O_のそのようなメンバーが存在せず、検証が「追加のプロパティを許可する」モードではない場合（セクション3.1を参照）、スキーマはインスタンスを拒否します。
The error indicator for this case has an "instancePath" pointing to _I_ and a "schemaPath" pointing to the schema.
この場合のエラーインジケータには、スキーマを指す "instancepath"を指す "instancepath"があります。
o If such a member in _P_ or _O_ does exist, then call this member _S_. If _S_ rejects _I_'s value, then the schema rejects the instance.
o そのようなメンバーが_P_または_O_のメンバーが存在する場合は、このメンバー_s_を呼び出します。_S_が_I_の値を拒否すると、スキーマはインスタンスを拒否します。
The error indicators for this case are the union of the error indicators from evaluating _S_ against _I_'s value.
この場合のエラーインジケータは、_I_の値に対して_S_を評価することのエラーインジケータの共用体です。
If an instance is an object, it may have multiple errors arising from the second and third bullet in the list above. In this case, the error indicators are the union of the errors.
インスタンスがオブジェクトの場合、上記のリストの2番目と3番目の箇条書きから発生する複数のエラーが発生する可能性があります。この場合、エラーインジケータはエラーの和集合です。
For example, the schema
たとえば、スキーマ
{
"properties": {
"a": { "type": "string" },
"b": { "type": "string" }
},
"optionalProperties": {
"c": { "type": "string" },
"d": { "type": "string" }
}
}
accepts
accept accept
{ "a": "foo", "b": "bar" }
and
そして
{ "a": "foo", "b": "bar", "c": "baz" }
and
そして
{ "a": "foo", "b": "bar", "c": "baz", "d": "quux" }
and
そして
{ "a": "foo", "b": "bar", "d": "quux" }
but rejects
しかし拒絶する
null
ヌル
with the error indicator
エラーインジケータを使って
[{ "instancePath": "", "schemaPath": "/properties" }]
and rejects
そして拒否します
{ "b": 3, "c": 3, "e": 3 }
with the error indicators
エラーインジケータを使って
[
{ "instancePath": "",
"schemaPath": "/properties/a" },
{ "instancePath": "/b",
"schemaPath": "/properties/b/type" },
{ "instancePath": "/c",
"schemaPath": "/optionalProperties/c/type" },
{ "instancePath": "/e",
"schemaPath": "" }
]
If instead the schema had "additionalProperties: true" but was otherwise the same:
代わりにスキーマに「追加プロパティー：true」がある場合は、そうでない場合も同じです。
{
"properties": {
"a": { "type": "string" },
"b": { "type": "string" }
},
"optionalProperties": {
"c": { "type": "string" },
"d": { "type": "string" }
},
"additionalProperties": true
}
and the instance remained the same:
そしてインスタンスは同じままでした。
{ "b": 3, "c": 3, "e": 3 }
then the error indicators from evaluating the instance against the schema would be:
その後、スキーマに対してインスタンスを評価することのエラーインジケータは次のとおりです。
[
{ "instancePath": "",
"schemaPath": "/properties/a" },
{ "instancePath": "/b",
"schemaPath": "/properties/b/type" },
{ "instancePath": "/c",
"schemaPath": "/optionalProperties/c/type" },
]
These are the same errors as before, except the final error (associated with the additional member named "e" in the instance) is no longer present. This is because "additionalProperties: true" enables "allow additional properties" mode on the schema.
これらは、以前と同じエラーです。最後のエラー（インスタンス内の "e"という名前の追加メンバに関連付けられている）が存在しなくなったことを除いて、以前と同じエラーです。これは、「追加プロパティ：true」がスキーマ上で「追加のプロパティを許可する」モードを有効にするためです。
Finally, the schema
最後に、スキーマ
{
"nullable": true,
"properties": {
"a": { "type": "string" },
"b": { "type": "string" }
},
"optionalProperties": {
"c": { "type": "string" },
"d": { "type": "string" }
},
"additionalProperties": true
}
accepts
accept accept
null
ヌル
but rejects
しかし拒絶する
{ "b": 3, "c": 3, "e": 3 }
with the error indicators
エラーインジケータを使って
[
{ "instancePath": "",
"schemaPath": "/properties/a" },
{ "instancePath": "/b",
"schemaPath": "/properties/b/type" },
{ "instancePath": "/c",
"schemaPath": "/optionalProperties/c/type" },
]
The "values" form is meant to describe instances that are JSON objects being used as an associative array. The syntax of the "values" form is described in Section 2.2.7.
「値」フォームは、連想配列として使用されているJSONオブジェクトであるインスタンスを記述することを意味します。「値」形式の構文はセクション2.2.7で説明されています。
If a schema is of the "values" form, then:
スキーマが "値"フォームの場合、次のようにします。
* If the schema has a member named "nullable" whose value is the boolean "true", and the instance is the JSON primitive value "null", then the schema accepts the instance.
* スキーマに「nullable」という名前のメンバがある場合、その値がboolean "true"で、インスタンスがJSONプリミティブ値 "null"である場合、スキーマはインスタンスを受け入れます。
Otherwise:
さもないと：
Let _S_ be the value of the schema member with the name "values". The instance is accepted if and only if all of the following are true:
「値」という名前のスキーマ・メンバーの値を_s_させます。次のすべてが当てはまる場合に限り、インスタンスは受け入れられます。
o The instance is an object. Otherwise, the error indicator for this case shall have an "instancePath" pointing to the instance and a "schemaPath" pointing to the schema member with the name "values".
o インスタンスはオブジェクトです。それ以外の場合、この場合のエラーインジケータは、インスタンスを指す「instancepath」と、「値」という名前のスキーマ・メンバーを指す「Schemapath」を持ちます。
o If the instance is an object, then every member value of the instance must be accepted by _S_. Otherwise, the error indicators for this case are the union of all the error indicators arising from evaluating _S_ against member values of the instance.
o インスタンスがオブジェクトの場合、インスタンスのすべてのメンバー値は_s_で受け入れる必要があります。それ以外の場合、この場合のエラーインジケータは、インスタンスのメンバー値に対して_S_を評価することから生じるすべてのエラーインジケータの共用体です。
For example, the schema
たとえば、スキーマ
{
"values": {
"type": "float32"
}
}
accepts
accept accept
{}
{}
and
そして
{"a": 1, "b": 2}
but rejects
しかし拒絶する
null
ヌル
with the error indicator
エラーインジケータを使って
[{ "instancePath": "", "schemaPath": "/values" }]
and rejects
そして拒否します
{ "a": 1, "b": 2, "c": "foo", "d": 3, "e": "bar" }
with the error indicators
エラーインジケータを使って
[
{ "instancePath": "/c", "schemaPath": "/values/type" },
{ "instancePath": "/e", "schemaPath": "/values/type" }
]
The schema
スキーマ
{
"nullable": true,
"values": {
"type": "float32"
}
}
accepts
accept accept
null
ヌル
but rejects
しかし拒絶する
{ "a": 1, "b": 2, "c": "foo", "d": 3, "e": "bar" }
with the error indicators
エラーインジケータを使って
[
{ "instancePath": "/c", "schemaPath": "/values/type" },
{ "instancePath": "/e", "schemaPath": "/values/type" }
]
The "discriminator" form is meant to describe JSON objects being used in a fashion similar to a discriminated union construct in C-like languages. The syntax of the "discriminator" form is described in Section 2.2.8.
「弁別器」形式は、C型言語で識別されたユニオン構築物と同様の方法で使用されているJSONオブジェクトを説明することを意味する。「弁別器」形式の構文はセクション2.2.8で説明されています。
When a schema is of the "discriminator" form, it validates that:
スキーマが「識別子」フォームのものである場合、それは次のことを検証します。
* the instance is an object,
* インスタンスはオブジェクトです。
* the instance has a particular "tag" property,
* インスタンスには特定の "Tag"プロパティがあります。
* this "tag" property's value is a string within a set of valid values, and
* この「タグ」プロパティの値は、一連の有効な値の文字列です。
* the instance satisfies another schema, where this other schema is chosen based on the value of the "tag" property.
* このインスタンスは別のスキーマを満たします。ここで、この他のスキーマは "Tag"プロパティの値に基づいて選択されます。
The behavior of the "discriminator" form is more complex than the other keywords. Readers familiar with CDDL may find the final example in Appendix B helpful in understanding its behavior. What follows in this section is a description of the "discriminator" form's behavior, as well as some examples.
「識別子」フォームの動作は他のキーワードよりも複雑です。CDDLに精通している読者は、付録Bの最終的な例を見つけることができます。このセクションでは、「差別化」フォームの動作、およびいくつかの例の説明があります。
If a schema is of the "discriminator" form, then:
スキーマが「識別子」形式の場合、次のようにします。
* Let _D_ be the schema member with the name "discriminator".
* _d_という名前の「弁別器」のスキーマ・メンバーにしてください。
* Let _M_ be the schema member with the name "mapping".
* 「マッピング」という名前のスキーマメンバーに_M_を使用してください。
* Let _I_ be the instance member whose name equals _D_'s value. _I_ may, for some rejected instances, not exist.
* 名前が_d_の値に等しいインスタンスメンバーに_i_を取得します。_i_は、拒否されたインスタンスについては存在しないようにします。
* Let _S_ be the member of _M_ whose name equals _I_'s value. _S_ may, for some rejected instances, not exist.
* _m_のメンバーを_i_の値に等しいメンバーにします。_s_は、拒否されたインスタンスについては存在しない場合があります。
If the schema has a member named "nullable" whose value is the boolean "true", and the instance is the JSON primitive value "null", then the schema accepts the instance. Otherwise, the instance is accepted if and only if all of the following are true:
スキーマに「nullable」という名前のメンバがある場合、その値がboolean "true"で、インスタンスがJSONプリミティブ値 "null"である場合、スキーマはインスタンスを受け入れます。それ以外の場合は、次のすべてが当てはまる場合に限り、インスタンスは受け入れられます。
* The instance is an object.
* インスタンスはオブジェクトです。
Otherwise, the error indicator for this case shall have an "instancePath" pointing to the instance and a "schemaPath" pointing to _D_.
それ以外の場合、この場合のエラーインジケータは、インスタンスを指す「instancepath」と_D_を指す「schemapath」を持たなければなりません。
* If the instance is a JSON object, then _I_ must exist.
* インスタンスがJSONオブジェクトの場合は、_I_が存在している必要があります。
Otherwise, the error indicator for this case shall have an "instancePath" pointing to the instance and a "schemaPath" pointing to _D_.
それ以外の場合、この場合のエラーインジケータは、インスタンスを指す「instancepath」と_D_を指す「schemapath」を持たなければなりません。
* If the instance is a JSON object and _I_ exists, _I_'s value must be a string.
* インスタンスがJSONオブジェクトと_I_存在する場合、_I_の値は文字列でなければなりません。
Otherwise, the error indicator for this case shall have an "instancePath" pointing to _I_ and a "schemaPath" pointing to _D_.
それ以外の場合、この場合のエラーインジケータには、_I_を指す「InstancePath」と_D_を指す "Schemapath"があります。
* If the instance is a JSON object and _I_ exists and has a string value, then _S_ must exist.
* インスタンスがJSONオブジェクトと_I_が存在し、文字列値がある場合は、_S_が存在している必要があります。
Otherwise, the error indicator for this case shall have an "instancePath" pointing to _I_ and a "schemaPath" pointing to _M_.
それ以外の場合、この場合のエラーインジケータは、_i_を指す「instancepath」と_m_を指す "schemapath"を持ちます。
* If the instance is a JSON object, _I_ exists, and _S_ exists, then the instance must satisfy _S_'s value. Per Section 2, we know _S_'s value is a schema of the "properties" form. Apply the "discriminator tag exemption" afforded in Section 3.3.6 to _I_ when evaluating whether the instance satisfies _S_'s value.
* インスタンスがJSONオブジェクトの場合、_I_が存在し、_S_が存在し、そのインスタンスは_S_の値を満たす必要があります。セクション2ごとに、_S_の値は「プロパティ」フォームのスキーマです。インスタンスが_s_の値を満たすかどうかを評価するときは、セクション3.3.6で設定された「識別タグの免除」を_i_に適用してください。
Otherwise, the error indicators for this case shall be error indicators from evaluating _S_'s value against the instance, with the "discriminator tag exemption" applied to _I_.
それ以外の場合、この場合のエラーインジケータは、インスタンスに対する_S_の値を評価することのエラーインジケータとなります。
The list items above are defined in a mutually exclusive way. For any given instance and schema, exactly one of the list items above will apply.
上記のリスト項目は相互に排他的な方法で定義されています。特定のインスタンスとスキーマの場合、上記のリスト項目の1つが適用されます。
For example, the schema
たとえば、スキーマ
{
"discriminator": "version",
"mapping": {
"v1": {
"properties": {
"a": { "type": "float32" }
}
},
"v2": {
"properties": {
"a": { "type": "string" }
}
}
}
}
rejects
拒絶する
null
ヌル
with the error indicator
エラーインジケータを使って
[{ "instancePath": "", "schemaPath": "/discriminator" }]
(This is the case of the instance not being an object.)
（これは、インスタンスがオブジェクトではない場合です。）
Also rejected is
また拒絶されたものです
{}
{}
with the error indicator
エラーインジケータを使って
[{ "instancePath": "", "schemaPath": "/discriminator" }]
(This is the case of _I_ not existing.)
（これは既存の_i_の場合です。）
Also rejected is
また拒絶されたものです
{ "version": 1 }
with the error indicator
エラーインジケータを使って
[
{
"instancePath": "/version",
"schemaPath": "/discriminator"
}
]
(This is the case of _I_ existing but not having a string value.)
（これは既存の存在ですが文字列値を持たない場合です。）
Also rejected is
また拒絶されたものです
{ "version": "v3" }
with the error indicator
エラーインジケータを使って
[
{
"instancePath": "/version",
"schemaPath": "/mapping"
}
]
(This is the case of _I_ existing and having a string value but _S_ not existing.)
（これは既存の存在の場合、文字列値が存在しませんが存在しません。）
Also rejected is
また拒絶されたものです
{ "version": "v2", "a": 3 }
with the error indicator
エラーインジケータを使って
[
{
"instancePath": "/a",
"schemaPath": "/mapping/v2/properties/a/type"
}
]
(This is the case of _I_ and _S_ existing but the instance not satisfying _S_'s value.)
（これは_i_および_s_既存の場合ですが、インスタンスは_s_の値を満たしていません。）
Finally, the schema accepts
最後に、スキーマは受け入れます
{ "version": "v2", "a": "foo" }
This instance is accepted even though "version" is not mentioned by "/mapping/v2/properties"; the "discriminator tag exemption" ensures that "version" is not treated as an additional property when evaluating the instance against _S_'s value.
"/ mapping / v2 / properties"で "version"が言及されていなくてもこのインスタンスは受け入れられます。「識別タグ免除」は、インスタンスを_S_の値に対して評価するときに「バージョン」が追加のプロパティとして扱われないことを保証します。
By contrast, consider the same schema but with "nullable" being "true". The schema
対照的に、同じスキーマを考慮してくださいが、「ヌルタブル」が「真」であることを考慮してください。スキーマ
{
"nullable": true,
"discriminator": "version",
"mapping": {
"v1": {
"properties": {
"a": { "type": "float32" }
}
},
"v2": {
"properties": {
"a": { "type": "string" }
}
}
}
}
accepts
accept accept
null
ヌル
To further illustrate the "discriminator" form with examples, recall the JTD schema in Section 2.2.8, reproduced here:
例の「識別子」フォームをさらに説明するために、ここで再現されたセクション2.2.8のJTDスキーマを思い出してください。
{
"discriminator": "event_type",
"mapping": {
"account_deleted": {
"properties": {
"account_id": { "type": "string" }
}
},
"account_payment_plan_changed": {
"properties": {
"account_id": { "type": "string" },
"payment_plan": { "enum": ["FREE", "PAID"] }
},
"optionalProperties": {
"upgraded_by": { "type": "string" }
}
}
}
}
This schema accepts
このスキーマは受け入れます
{ "event_type": "account_deleted", "account_id": "abc-123" }
and
そして
{
"event_type": "account_payment_plan_changed",
"account_id": "abc-123",
"payment_plan": "PAID"
}
and
そして
{
"event_type": "account_payment_plan_changed",
"account_id": "abc-123",
"payment_plan": "PAID",
"upgraded_by": "users/mkhwarizmi"
}
but rejects
しかし拒絶する
{}
{}
with the error indicator
エラーインジケータを使って
[{ "instancePath": "", "schemaPath": "/discriminator" }]
and rejects
そして拒否します
{ "event_type": "some_other_event_type" }
with the error indicator
エラーインジケータを使って
[
{
"instancePath": "/event_type",
"schemaPath": "/mapping"
}
]
and rejects
そして拒否します
{ "event_type": "account_deleted" }
with the error indicator
エラーインジケータを使って
[{
"instancePath": "",
"schemaPath": "/mapping/account_deleted/properties/account_id"
}]
and rejects
そして拒否します
{
"event_type": "account_payment_plan_changed",
"account_id": "abc-123",
"payment_plan": "PAID",
"xxx": "asdf"
}
with the error indicator
エラーインジケータを使って
[{
"instancePath": "/xxx",
"schemaPath": "/mapping/account_payment_plan_changed"
}]
This document has no IANA actions.
この文書にはIANAの行動がありません。
Implementations of JTD will necessarily be manipulating JSON data. Therefore, the security considerations of [RFC8259] are all relevant here.
JTDの実装は必然的にJSONデータを操作することになります。したがって、[RFC8259]のセキュリティ上の考慮事項はすべてここに関連しています。
Implementations that evaluate user-inputted schemas SHOULD implement mechanisms to detect and abort circular references that might cause a naive implementation to go into an infinite loop. Without such mechanisms, implementations may be vulnerable to denial-of-service attacks.
ユーザ入力されたスキーマを評価する実装は、単純な実装が無限ループに入るようにする可能性がある円形の参照を検出および中止するためのメカニズムを実装するべきです。そのようなメカニズムがなければ、実装はサービス拒否攻撃に対して脆弱な場合があります。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] BRADNER、S、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, <https://www.rfc-editor.org/info/rfc3339>.
[RFC3339] Klyne、G.およびC. NEWMAN、「インターネット上の日時：Timestamps」、RFC 3339、DOI 10.17487 / RFC3339、2002年7月、<https：//www.rfc-editor.org/info/rfc3339>。
[RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom Syndication Format", RFC 4287, DOI 10.17487/RFC4287, December 2005, <https://www.rfc-editor.org/info/rfc4287>.
[RFC4287]ノッティンガム、M、ED。R. Sayre、Ed。、「Atom Syndication Format」、RFC 4287、DOI 10.17487 / RFC4287、2005年12月、<https：//www.rfc-editor.org/info/rfc4287>。
[RFC6901] Bryan, P., Ed., Zyp, K., and M. Nottingham, Ed., "JavaScript Object Notation (JSON) Pointer", RFC 6901, DOI 10.17487/RFC6901, April 2013, <https://www.rfc-editor.org/info/rfc6901>.
[RFC6901] Bryan、P.、ED。、ZYP、K.、およびM. Nottingham、Ed。、「JavaScriptオブジェクト表記（JSON）ポインタ」、RFC 6901、DOI 10.17487 / RFC6901、2013年4月、<https：//www.rfc-editor.org/info/rfc6901>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B、「RFC 2119キーワードの大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <https://www.rfc-editor.org/info/rfc8259>.
[RFC8259] Bray、T.、ED。、「JavaScriptオブジェクト表記（JSON）データ交換フォーマット」、STD 90、RFC 8259、DOI 10.17487 / RFC8259、2017年12月、<https：//www.rfc-editor.org/ info / rfc8259>。
[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, June 2019, <https://www.rfc-editor.org/info/rfc8610>.
[RFC8610] Birkholz、H.、Vigano、C. Bormann、「簡潔なデータ定義言語（CDDL）：簡潔なバイナリオブジェクト表現（CBOR）とJSONデータ構造を表現する表記規則」、RFC 8610、DOI 10.17487/ RFC8610、2019年6月、<https://www.rfc-editor.org/info/rfc8610>。
[JSON-SCHEMA] Wright, A., Andrews, H., Hutton, B., and G. Dennis, "JSON Schema: A Media Type for Describing JSON Documents", Work in Progress, Internet-Draft, draft-handrews-json-schema-02, 17 September 2019, <https://tools.ietf.org/html/draft-handrews-json-schema-02>.
[JSON-Schema]ライト、A。、Andrews、H.、Hutton、B.、およびG. Dennis、「JSONスキーマ：JSON文書を記述するためのメディアタイプ」、進行中の作業、インターネットドラフト、ドラフト手順 - json-schema-02,2019、<https://tools.ietf.org/html/draft-handrews-json-schema-02>。
[OPENAPI] OpenAPI Initiative, "OpenAPI Specification", February 2020, <https://spec.openapis.org/oas/v3.0.3>.
[OpenAPI] OpenAPIイニシアチブ、「OpenAPI仕様」、2020年2月、<https://spec.openapis.org/oas/v3.0.3>。
[RFC7071] Borenstein, N. and M. Kucherawy, "A Media Type for Reputation Interchange", RFC 7071, DOI 10.17487/RFC7071, November 2013, <https://www.rfc-editor.org/info/rfc7071>.
[RFC7071] Borenstein、N.およびM.Kucherawy、「評判交換のためのメディアタイプ」、RFC 7071、DOI 10.17487 / RFC7071、2013年11月、<https：//www.rfc-editor.org/info/rfc7071>。
[RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, DOI 10.17487/RFC7493, March 2015, <https://www.rfc-editor.org/info/rfc7493>.
[RFC7493] Bray、T.、Ed。、「I-JSONメッセージフォーマット」、RFC 7493、DOI 10.17487 / RFC7493、2015年3月、<https：//www.rfc-editor.org/info/rfc7493>。
This appendix is not normative.
この付録は規範的ではありません。
This section describes possible features that are intentionally left out of JSON Type Definition and justifies why these features are omitted.
このセクションでは、意図的にJSONタイプの定義から除外されている可能な機能について説明し、これらの機能を省略する理由を正当化します。
This document does not allow "int64" or "uint64" as values for the JTD "type" keyword (see Sections 2.2.3 and 3.3.3). Such hypothetical "int64" or "uint64" types would behave like "int32" or "uint32" (respectively) but with the range of values associated with 64-bit instead of 32-bit integers. That is:
この文書では、JTDの「Type」キーワードの値として「INT64」または「UINT64」を使用することはありません（セクション2.2.3と3.3.3を参照）。そのような仮説の「INT64」または「UINT64」型は、「それぞれINT32」または「UINT32」（それぞれ）のように動作しますが、32ビット整数の代わりに64ビットに関連付けられている値の範囲があります。あれは：
* "int64" would accept numbers between -(2**63) and (2**63)-1
* "uint64" would accept numbers between 0 and (2**64)-1
Users of "int64" and "uint64" would likely expect that the full range of signed or unsigned 64-bit integers could interoperably be transmitted as JSON without loss of precision. But this assumption is likely to be incorrect, for the reasons given in Section 2.2 of [RFC7493].
「INT64」および「UINT64」のユーザは、正確さを損なうことなく、符号付きまたは符号なし64ビット整数の全範囲が相互運用可能に送信される可能性があると予想される可能性が高い。しかし、[RFC7493]のセクション2.2のセクション2.2に与えられる理由で、この仮定は間違っている可能性があります。
"int64" and "uint64" likely would have led users to falsely assume that the full range of 64-bit integers can be interoperably processed as JSON without loss of precision. To avoid leading users astray, JTD omits "int64" and "uint64".
「INT64」および「UINT64」は、64ビット整数の全範囲が正確な損失を損なうことなくJSONとして相互運用できると誤って想定することができるようになる可能性が高い。主要なユーザーを避けないようにするために、JTDは「INT64」と「uint64」を省略しています。
This document disallows the "definitions" keyword from appearing outside of root schemas (see Figure 1). Conceivably, this document could have instead allowed "definitions" to appear on any schema, even non-root ones. Under this alternative design, "ref"s would resolve to a definition in the "nearest" (i.e., most nested) schema that both contained the "ref" and had a suitably named "definitions" member.
このドキュメントは、ルートスキーマの外側に表示されることの「定義」キーワードを許可しません（図1を参照）。この文書では、代わりに「定義」が任意のスキーマに表示されることができます。この代替設計の下で、「REF」は「最も近い」（すなわち、最も入れ子になった）スキーマの定義に解決され、両方とも「Ref」を含み、適切には「定義」メンバーを有する。
For instance, under this alternative approach, one could define schemas like the one in Figure 3.
たとえば、この代替アプローチの下では、図3のようなスキーマを定義することができます。
{
"properties": {
"foo": {
"definitions": {
"user": { "properties": { "user_id": {"type": "string" }}}
},
"ref": "user"
},
"bar": {
"definitions": {
"user": { "properties": { "user_id": {"type": "string" }}}
},
"ref": "user"
},
"baz": {
"definitions": {
"user": { "properties": { "userId": {"type": "string" }}}
},
"ref": "user"
}
}
}
Figure 3: A Hypothetical Schema Had This Document Permitted Non-root Definitions. This Is Not a Correct JTD Schema.
図3：仮想スキーマには、この文書が非ルート定義を許可されていました。これは正しいJTDスキーマではありません。
If schemas like that in Figure 3 were permitted, code generation from JTD schemas would be more difficult, and the generated code would be less useful.
図3のようなスキーマが許可されていた場合、JTDスキーマからのコード生成はより困難になり、生成されたコードはそれほど有用ではありません。
Code generation would be more difficult because it would force code generators to implement a name-mangling scheme for types generated from definitions. This additional difficulty is not immense, but it adds complexity to an otherwise relatively trivial task.
コードジェネレータは、定義から生成されたタイプのための名前マングリング方式を実装するようにコードジェネレータを強制するので、コード生成はより困難になるでしょう。この追加の難易度は莫大ではありませんが、それは比較的些細な仕事に複雑さを増します。
Generated code would be less useful because generated, mangled struct names are less pithy than human-defined struct names. For instance, the "user" definitions in Figure 3 might have been generated into types named "PropertiesFooUser", "PropertiesBarUser", and "PropertiesBazUser"; obtuse names like these are less useful to human-written code than names like "User".
生成されたコードは、生成された、マングルされた構造の名前は、人間定義の構造名よりも窮地が低いため、有用ではありません。たとえば、図3の「ユーザー」定義は、「PropertiesFooder」、「PropertiesBarUser」、および「PropertiesBazuser」という名前の型に生成された可能性があります。これらのような致命的な名前は、 "user"のような名前よりも人間が書かれたコードに有用ではありません。
Furthermore, even though "PropertiesFooUser" and "PropertiesBarUser" would be essentially identical, they would not be interchangeable in many statically typed programming languages. A code generator could attempt to circumvent this by deduplicating identical definitions, but then the user might be confused as to why the subtly distinct "PropertiesBazUser", defined from a schema allowing a property named "userId" (not "user_id"), was not deduplicated.
さらに、「PropertyFooder」と「PropertiesBarUser」が本質的に同一であっても、多くの静的に入力されたプログラミング言語で交換可能ではありません。コードジェネレータは、同一の定義を重複排除することによってこれを回避しようとする可能性がありますが、ユーザーは「userid」という名前のプロパティを許可するSubtly異なる「PROPECIPAVAZUSER」（ "user_id"）ではなかった理由に関して混乱します。重複排除
Because there seem to be implementation and usability challenges associated with non-root definitions, and because it would be easier to later amend JTD to permit for non-root definitions than to later amend JTD to prohibit them, this document does not permit non-root definitions in JTD schemas.
非ルート定義に関連した実装と使いやすさの課題があるように思われるので、後で非root定義を許可するのが簡単であるため、JTDがそれらを禁止することよりも根本的な定義が許可されているため、この文書は非根を許可しません。JTDスキーマの定義
This appendix is not normative.
この付録は規範的ではありません。
To aid the reader familiar with CDDL, this section illustrates how JTD works by presenting JTD schemas and CDDL schemas that accept and reject the same instances.
CDDLに精通しているリーダーを支援するために、このセクションではJTDスキーマと同じインスタンスを受け入れて拒否するJTDスキーマとCDDLスキーマを提示する方法を説明します。
The JTD schema
JTDスキーマ
{}
{}
accepts the same instances as the CDDL rule
CDDLルールと同じインスタンスを受け入れます
root = any
The JTD schema
JTDスキーマ
{
"definitions": {
"a": { "elements": { "ref": "b" }},
"b": { "type": "float32" }
},
"elements": {
"ref": "a"
}
}
accepts the same instances as the CDDL rule
CDDLルールと同じインスタンスを受け入れます
root = [* a]
a = [* b]
b = number
The JTD schema
JTDスキーマ
{ "enum": ["PENDING", "DONE", "CANCELED"]}
accepts the same instances as the CDDL rule
CDDLルールと同じインスタンスを受け入れます
root = "PENDING" / "DONE" / "CANCELED"
The JTD schema
JTDスキーマ
{"type": "boolean"}
accepts the same instances as the CDDL rule
CDDLルールと同じインスタンスを受け入れます
root = bool
The JTD schemas:
JTDスキーマ：
{"type": "float32"}
and
そして
{"type": "float64"}
both accept the same instances as the CDDL rule
どちらもCDDLルールと同じインスタンスを受け入れます
root = number
The JTD schema
JTDスキーマ
{"type": "string"}
accepts the same instances as the CDDL rule
CDDLルールと同じインスタンスを受け入れます
root = tstr
The JTD schema
JTDスキーマ
{"type": "timestamp"}
accepts the same instances as the CDDL rule
CDDLルールと同じインスタンスを受け入れます
root = tdate
The JTD schema
JTDスキーマ
{ "elements": { "type": "float32" }}
accepts the same instances as the CDDL rule
CDDLルールと同じインスタンスを受け入れます
root = [* number]
The JTD schema
JTDスキーマ
{
"properties": {
"a": { "type": "boolean" },
"b": { "type": "float32" }
},
"optionalProperties": {
"c": { "type": "string" },
"d": { "type": "timestamp" }
}
}
accepts the same instances as the CDDL rule
CDDLルールと同じインスタンスを受け入れます
root = { a: bool, b: number, ? c: tstr, ? d: tdate }
The JTD schema
JTDスキーマ
{ "values": { "type": "float32" }}
accepts the same instances as the CDDL rule
CDDLルールと同じインスタンスを受け入れます
root = { * tstr => number }
Finally, the JTD schema
最後に、JTDスキーマ
{
"discriminator": "a",
"mapping": {
"foo": {
"properties": {
"b": { "type": "float32" }
}
},
"bar": {
"properties": {
"b": { "type": "string" }
}
}
}
}
accepts the same instances as the CDDL rule
CDDLルールと同じインスタンスを受け入れます
root = { a: "foo", b: number } / { a: "bar", b: tstr }
This appendix is not normative.
この付録は規範的ではありません。
As a demonstration of JTD, in Figure 4 is a JTD schema closely equivalent to the plain-English definition "reputation-object" described in Section 6.2.2 of [RFC7071]:
JTDのデモンストレーションとして、図4は[RFC7071]の6.2.2項で説明されている平凡な定義「評判オブジェクト」と密接に等しいJTDスキーマです。
{
"properties": {
"application": { "type": "string" },
"reputons": {
"elements": {
"additionalProperties": true,
"properties": {
"rater": { "type": "string" },
"assertion": { "type": "string" },
"rated": { "type": "string" },
"rating": { "type": "float32" },
},
"optionalProperties": {
"confidence": { "type": "float32" },
"normal-rating": { "type": "float32" },
"sample-size": { "type": "float64" },
"generated": { "type": "float64" },
"expires": { "type": "float64" }
}
}
}
}
}
Figure 4: A JTD Schema Describing "reputation-object" from Section 6.2.2 of [RFC7071]
図4：[RFC7071]のセクション6.2.2からの「評判オブジェクト」を記述するJTDスキーマ
This schema does not enforce the requirement that "sample-size", "generated", and "expires" be unbounded positive integers. It does not express the limitation that "rating", "confidence", and "normal-rating" should not have more than three decimal places of precision.
このスキーマは、「sample-size」、「生成」、および「有効期限」が無制限の正の整数になるという要件を強制しません。「評価」、「信頼」、および「正常評価」には、小数点以下の小数を持たないはずではありません。
The example in Figure 4 can be compared against the equivalent example in Appendix H of [RFC8610].
図4の例は、[RFC8610]の付録Hの等価例と比較できます。
Acknowledgments
謝辞
Carsten Bormann provided lots of useful guidance and feedback on JTD's design and the structure of this document.
Carsten Bormannは、JTDの設計とこの文書の構造についての有用なガイダンスとフィードバックをたくさん提供しました。
Evgeny Poberezkin suggested the addition of "nullable" and thoroughly vetted this document for mistakes and opportunities for simplification.
Evgeny Poberezkinは「Nullable」の追加を提案し、この文書を間違いや簡素化のために徹底的に吟味させた。
Tim Bray suggested the current "ref" model and the addition of "enum". Anders Rundgren suggested extending "type" to have more support for numerical types. James Manger suggested additional clarifying examples of how integer types work. Adrian Farrel suggested many improvements to help make this document clearer.
TIM BRAYは、現在の「REF」モデルと「列挙」の追加を提案しました。Anders Rundgrenは、数値型をよりサポートするために「タイプ」を拡張することを提案しました。James Mangerは、整数型がどのように機能するかの追加の説明例を提案しました。Adrian Farrelはこの文書をより明確にするのを助けるために多くの改良を示唆していました。
Members of the IETF JSON mailing list -- in particular, Pete Cordell, Phillip Hallam-Baker, Nico Williams, John Cowan, Rob Sayre, and Erik Wilde -- provided lots of useful feedback.
特に、Pete Cordell、Phillip Hallam-Baker、Nico Williams、John Cowan、Rob Sayre、Erik Wilde - wilde - resol fode - を提供しました。
OpenAPI's "discriminator" object [OPENAPI] inspired the "discriminator" form. [JSON-SCHEMA] influenced various parts of JTD's early design.
OpenAPIの「識別子」オブジェクト[OpenAPI]は「差別器」フォームを刺激しました。[JSON-SCHEMA] JTDの初期設計のさまざまな部分に影響を与えました。
Author's Address
著者の住所
Ulysse Carion Segment.io, Inc 100 California Street San Francisco, CA 94111 United States of America
Ulysse Carion Segment.io、Inc 100 California Streetサンフランシスコ、CA 94111アメリカ合衆国
Email: ulysse@segment.com