2.2.1. 빈 형식

"empty" 형식은 그림 1의 "empty" CDDL 규칙으로 정의된다. "empty" 형식의 의미론은 Section 3.3.1에 설명되어 있다.¶

"empty"라는 이름에도 불구하고, "empty" 형식의 스키마가 반드시 빈 JSON 객체인 것은 아니다. 여덟 형식 중 어떤 형식의 스키마와 마찬가지로, "empty" 형식의 스키마도 "nullable"(그 값은 "true" 또는 "false"여야 함)이라는 이름의 멤버나 "metadata"(그 값은 객체여야 함)라는 이름의 멤버, 또는 둘 다를 포함할 수 있다.¶

따라서,¶

   {}

및¶

   { "nullable": true }

및¶

   { "nullable": true, "metadata": { "foo": "bar" }}

는 "empty" 형식의 올바른 JTD 스키마이지만,¶

   { "nullable": "foo" }

는 그렇지 않다. "nullable"이라는 이름의 멤버 값은 "true" 또는 "false"여야 하기 때문이다.¶

2.2.2. 참조

"ref" 형식은 그림 1의 "ref" CDDL 규칙으로 정의된다. "ref" 형식의 의미론은 Section 3.3.2에 설명되어 있다.¶

"ref" 형식의 스키마가 올바르려면, "ref"라는 이름의 멤버 값은 그 스키마가 나타나는 스키마의 루트 수준에서 발견되는 정의 중 하나를 참조해야 한다. 더 형식적으로, "ref" 형식의 스키마 S에 대해:¶

• B를 해당 스키마를 포함하는 루트 스키마, 또는 그 스키마 자체가 루트 스키마인 경우에는 그 스키마 자체라고 하자.¶
• R을 이름이 "ref"인 S의 멤버 값이라고 하자.¶

스키마가 올바르다면, B는 이름이 "definitions"인 멤버 D를 가져야 MUST 하며, D는 그 이름이 R과 같은 멤버를 포함해야 MUST 한다.¶

따라서,¶

   {
     "definitions": {
       "coordinates": {
         "properties": {
           "lat": { "type": "float32" },
           "lng": { "type": "float32" }
         }
       }
     },
     "properties": {
       "user_location": { "ref": "coordinates" },
       "server_location": { "ref": "coordinates" }
     }
   }

는 올바른 JTD 스키마이며, 같은 것을 두 번 다시 정의하지 않기 위한 "ref" 형식의 목적을 보여준다. 그러나,¶

   { "ref": "foo" }

는 올바른 JTD 스키마가 아니다. 최상위 "definitions"가 없으므로 "ref" 형식이 올바를 수 없기 때문이다. 마찬가지로,¶

   { "definitions": { "foo": {}}, "ref": "bar" }

는 올바른 JTD 스키마가 아니다. 최상위 "definitions" 안에 "bar"라는 이름의 멤버가 없기 때문이다.¶

2.2.3. 타입

"type" 형식은 그림 1의 "type" CDDL 규칙으로 정의된다. "type" 형식의 의미론은 Section 3.3.3에 설명되어 있다.¶

"type" 형식의 올바른 JTD 스키마 예로,¶

   { "type": "uint8" }

는 올바른 JTD 스키마이지만,¶

   { "type": true }

및¶

   { "type": "foo" }

는 올바른 스키마가 아니다. "true"와 JSON 문자열 "foo" 모두 그림 1의 "type" CDDL 규칙에 설명된 "type" 멤버의 허용 값 목록에 없기 때문이다.¶

2.2.4. 열거형

"enum" 형식은 그림 1의 "enum" CDDL 규칙으로 정의된다. "enum" 형식의 의미론은 Section 3.3.4에 설명되어 있다.¶

"enum" 형식의 스키마가 올바르려면, "enum"이라는 이름의 멤버 값은 비어 있지 않은 문자열 배열이어야 하며, 그 배열은 중복 값을 포함해서는 안 된다. 더 형식적으로, "enum" 형식의 스키마 S에 대해:¶

• E를 이름이 "enum"인 S의 멤버 값이라고 하자.¶

스키마가 올바르다면, E의 요소 쌍 중 같은 문자열 값을 인코딩하는 어떤 쌍도 존재해서는 MUST NOT 안 된다. 여기서 문자열 동등성은 Section 8.3 of [RFC8259]에 정의된 대로이다.¶

따라서,¶

   { "enum": [] }

는 올바른 JTD 스키마가 아니다. "enum"이라는 이름의 멤버 값은 비어 있지 않아야 하기 때문이다. 또한¶

   { "enum": ["a\\b", "a\u005Cb"] }

는 올바른 JTD 스키마가 아닌데, 그 이유는¶

   "a\\b"

및¶

   "a\u005Cb"

가 Section 8.3 of [RFC8259]에 제시된 문자열 동등성 정의에 따라 같은 문자열을 인코딩하기 때문이다. 반대로,¶

   { "enum": ["PENDING", "IN_PROGRESS", "DONE" ]}

는 "enum" 형식의 올바른 JTD 스키마의 예이다.¶

2.2.5. 요소

"elements" 형식은 그림 1의 "elements" CDDL 규칙으로 정의된다. "elements" 형식의 의미론은 Section 3.3.5에 설명되어 있다.¶

"elements" 형식의 올바른 JTD 스키마 예로,¶

   { "elements": { "type": "uint8" }}

는 올바른 JTD 스키마이지만,¶

   { "elements": true }

및¶

   { "elements": { "type": "foo" } }

는 올바른 스키마가 아니다. 왜냐하면¶

   true

도¶

   { "type": "foo" }

도 올바른 JTD 스키마가 아니며, "elements"라는 이름의 멤버 값은 올바른 JTD 스키마여야 하기 때문이다.¶

2.2.6. 속성

"properties" 형식은 그림 1의 "properties" CDDL 규칙으로 정의된다. "properties" 형식의 의미론은 Section 3.3.6에 설명되어 있다.¶

"properties" 형식의 스키마가 올바르려면, 속성은 필수(즉, "properties" 안에 있음)이거나 선택적(즉, "optionalProperties" 안에 있음)이어야 하며, 둘 다일 수는 없다.¶

더 형식적으로, 어떤 스키마가 "properties"라는 이름의 멤버(값은 P)와 "optionalProperties"라는 이름의 다른 멤버(값은 O)를 모두 가진다면, O와 P는 공통된 멤버 이름을 가져서는 MUST NOT 안 된다. 즉, P의 어떤 멤버도 Section 8.3 of [RFC8259]에 제시된 문자열 동등성 정의에 따라 O의 어떤 멤버 이름과도 같은 이름을 가져서는 안 된다.¶

따라서,¶

   {
     "properties": { "confusing": {} },
     "optionalProperties": { "confusing": {} }
   }

는 올바른 JTD 스키마가 아니다. "confusing"이 "properties"와 "optionalProperties" 모두에 나타나기 때문이다. 반대로,¶

   {
     "properties": {
       "users": {
         "elements": {
           "properties": {
             "id": { "type": "string" },
             "name": { "type": "string" },
             "create_time": { "type": "timestamp" }
           },
           "optionalProperties": {
             "delete_time": { "type": "timestamp" }
           }
         }
       },
       "next_page_token": { "type": "string" }
     }
   }

는 "properties" 형식의 올바른 JTD 스키마이며, 사용자들의 페이지가 매겨진 목록을 설명하고 JTD 스키마 구문의 재귀적 성격을 보여준다.¶

2.2.7. 값

"values" 형식은 그림 1의 "values" CDDL 규칙으로 정의된다. "values" 형식의 의미론은 Section 3.3.7에 설명되어 있다.¶

"values" 형식의 올바른 JTD 스키마 예로,¶

   { "values": { "type": "uint8" }}

는 올바른 JTD 스키마이지만,¶

   { "values": true }

및¶

   { "values": { "type": "foo" } }

는 올바른 스키마가 아니다. 왜냐하면¶

   true

도¶

   { "type": "foo" }

도 올바른 JTD 스키마가 아니며, "values"라는 이름의 멤버 값은 올바른 JTD 스키마여야 하기 때문이다.¶

2.2.8. 판별자

"discriminator" 형식은 그림 1의 "discriminator" CDDL 규칙으로 정의된다. "discriminator" 형식의 의미론은 Section 3.3.8에 설명되어 있다. "discriminator" 형식의 의미론을 이해하면, 이 절이 그림 1에 있는 것 이상의 "discriminator" 형식 제약을 제공하는 이유를 이해하는 데 도움이 될 것이다.¶

tagged union의 "discriminator" 속성에 대해 모호하거나 만족할 수 없는 제약을 방지하기 위해, "discriminator" 형식의 스키마에는 추가 제약이 존재한다. "discriminator" 형식의 스키마에 대해:¶

• D를 이름이 "discriminator"인 스키마의 멤버라고 하자.¶
• M을 이름이 "mapping"인 스키마의 멤버라고 하자.¶

스키마가 올바르다면, M의 모든 멤버 값 S는 "properties" 형식의 스키마가 된다. 각 S에 대해:¶

• S가 이름이 "nullable"과 같은 멤버 N을 가지고 있다면, N의 값은 JSON 원시 값 "true"여서는 MUST NOT 안 된다.¶
• S의 각 멤버 P 중 이름이 "properties" 또는 "optionalProperties"와 같은 멤버에 대해, 객체여야 하는 P의 값은 D의 값과 이름이 같은 멤버를 포함해서는 MUST NOT 안 된다.¶

따라서,¶

   {
     "discriminator": "event_type",
     "mapping": {
       "can_the_object_be_null_or_not?": {
         "nullable": true,
         "properties": { "foo": { "type": "string" } }}
       }
     }
   }

는 잘못된 스키마이다. "mapping"의 한 멤버가 "nullable"이라는 이름의 멤버를 가지고 있고 그 값이 "true"이기 때문이다. 이는 인스턴스가 null일 수 있음을 시사한다. 그러나 최상위 스키마에는 "true"로 설정된 그러한 "nullable"이 없어서, 실제로 인스턴스가 null일 수 없음을 시사한다. 이것이 올바른 JTD 스키마라면, 어떤 정보가 우선하는지 불명확할 것이다.¶

JTD는 "discriminator" 형식의 스키마가 설명하는 인스턴스가 null일 수 있는지에 대한 모순된 명세의 가능성을 구문 수준에서 허용하지 않음으로써 이러한 가능한 모호성을 처리한다. discriminator "mapping" 안의 스키마는 "nullable"을 "true"로 설정할 수 없으며, discriminator 자체만 이런 방식으로 "nullable"을 사용할 수 있다.¶

또한 다음도 이에 따른다.¶

   {
     "discriminator": "event_type",
     "mapping": {
       "is_event_type_a_string_or_a_float32?": {
         "properties": { "event_type": { "type": "float32" }}
       }
     }
   }

및¶

   {
     "discriminator": "event_type",
     "mapping": {
       "is_event_type_a_string_or_an_optional_float32?": {
         "optionalProperties": { "event_type": { "type": "float32" }}
       }
     }
   }

는 잘못된 스키마이다. "event_type"이 "discriminator"의 값이면서 동시에 "mapping" 멤버의 "properties" 또는 "optionalProperties" 중 하나의 멤버 이름이기 때문이다. 이는 모호하다. 일반적으로 "discriminator" 키워드는 "event_type"이 문자열일 것으로 기대됨을 나타내지만, 스키마의 다른 부분은 "event_type"이 숫자일 것으로 기대된다고 명시하기 때문이다.¶

JTD는 discriminator "tags"의 모순된 명세 가능성을 구문 수준에서 허용하지 않음으로써 이러한 가능한 모호성을 처리한다. Discriminator "tags"는 스키마의 다른 부분에서 다시 정의될 수 없다.¶

반대로,¶

   {
     "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" }
         }
       }
     }
   }

는 올바른 스키마이며, JSON 기반 메시징 시스템에서 흔한 데이터 패턴을 설명한다. Section 3.3.8은 이 스키마가 무엇을 수락하고 거부하는지에 대한 예제를 제공한다.¶

3.3.1. 빈 형식

"empty" 형식은 값이 알 수 없거나 예측할 수 없거나 그 밖의 방식으로 스키마에 의해 제약되지 않는 인스턴스를 설명하기 위한 것이다. "empty" 형식의 구문은 Section 2.2.1에 설명되어 있다.¶

스키마가 "empty" 형식이면 모든 인스턴스를 수락한다. "empty" 형식의 스키마는 어떤 오류 표시자도 생성하지 않는다.¶

3.3.2. 참조

"ref" 형식은 스키마가 루트 스키마의 "definitions" 안에 있는 어떤 것의 관점에서 정의될 때 사용된다. "ref" 형식은 스키마를 덜 반복적으로 만들고 재귀 구조를 설명할 수도 있게 한다. "ref" 형식의 구문은 Section 2.2.2에 설명되어 있다.¶

스키마가 "ref" 형식이면 다음과 같다.¶

• 스키마가 이름이 "nullable"이고 값이 boolean "true"인 멤버를 가지고 있으며, 인스턴스가 JSON 원시 값 "null"이면, 스키마는 그 인스턴스를 수락한다.¶

  그렇지 않으면:¶

  • R을 이름이 "ref"인 스키마 멤버의 값이라고 하자.¶
  • B를 해당 스키마를 포함하는 루트 스키마, 또는 그 스키마 자체가 루트 스키마인 경우 그 스키마 자체라고 하자.¶
  • D를 이름이 "definitions"인 B의 멤버라고 하자. Section 2에 따라 D가 존재함을 안다.¶
  • S를 R과 이름이 같은 D의 멤버 값이라고 하자. Section 2.2.2에 따라 S가 존재하고 스키마임을 안다.¶

스키마는 S가 인스턴스를 수락하는 경우에 그리고 그 경우에만 인스턴스를 수락한다. 그렇지 않으면 이 경우 반환할 오류 표시자는 S를 인스턴스에 대해 평가하여 나온 오류 표시자의 합집합이다.¶

예를 들어, 스키마¶

   {
     "definitions": { "a": { "type": "float32" }},
     "ref": "a"
   }

는 다음을 수락하지만¶

   123

다음은 거부한다.¶

   null

오류 표시자는 다음과 같다.¶

   [{ "instancePath": "", "schemaPath": "/definitions/a/type" }]

스키마¶

   {
     "definitions": { "a": { "type": "float32" }},
     "ref": "a",
     "nullable": true
   }

는 다음을 수락한다.¶

   null

이는 스키마가 값이 "true"인 "nullable" 멤버를 가지고 있기 때문이다.¶

"nullable"이 "false"인 것은 이 문서에서 설명하는 어떤 형식에서도 효과가 없다는 점에 유의하라. 예를 들어, 스키마¶

   {
     "definitions": { "a": { "nullable": false, "type": "float32" }},
     "ref": "a",
     "nullable": true
   }

는 다음을 수락한다.¶

   null

다시 말해, "nullable"에 "false" 값을 넣는다고 해서 "ref" 형식의 스키마에서 "nullable" 멤버를 재정의하는 일은 결코 없다. 스키마의 "nullable" 멤버가 "false" 값을 가지는 것은 올바르지만 효과는 없다.¶

3.3.3. 타입

"type" 형식은 값이 boolean, number, string 또는 timestamp [RFC3339]인 인스턴스를 설명하기 위한 것이다. "type" 형식의 구문은 Section 2.2.3에 설명되어 있다.¶

스키마가 "type" 형식이면 다음과 같다.¶

• 스키마가 이름이 "nullable"이고 값이 boolean "true"인 멤버를 가지고 있으며, 인스턴스가 JSON 원시 값 "null"이면, 스키마는 그 인스턴스를 수락한다.¶

  그렇지 않으면:¶

  • T를 이름이 "type"인 멤버의 값이라고 하자. 다음 표는 T의 값에 따라 인스턴스가 수락되는지 여부를 설명한다.¶

  • 표 1: Type에 대해 수락되는 값

    "T"가 ...와 같다면	인스턴스가 ...이면 수락된다
    boolean	"true" 또는 "false"와 같음
    float32	JSON number
    float64	JSON number
    int8	표 2 참조
    uint8	표 2 참조
    int16	표 2 참조
    uint16	표 2 참조
    int32	표 2 참조
    uint32	표 2 참조
    string	JSON string
    timestamp	[RFC3339]에 설명되고, Section 3.3 of [RFC4287]에 의해 정제된 표준 형식을 따르는 JSON string

    "float32"와 "float64"는 의도에서 서로 구별된다. "float32"는 IEEE 754 단정밀도 부동소수점으로 처리되도록 의도된 데이터를 나타내는 반면, "float64"는 IEEE 754 배정밀도 부동소수점으로 처리되도록 의도된 데이터를 나타낸다. JTD 스키마로부터 코드를 생성하는 도구는 "float32"에 대해 "float64"와 다른 코드를 생성할 가능성이 높다.¶

T가 "int" 또는 "uint"로 시작한다면, 인스턴스가 소수부가 0인 값을 인코딩하는 JSON number인 경우에 그리고 그 경우에만 수락된다. T의 값에 따라, 이 인코딩된 숫자는 추가로 특정 범위 안에 있어야 한다.¶

다음은¶

   10

및¶

   10.0

및¶

   1.0e1

가 소수부가 0인 값을 인코딩하는 반면,¶

   10.5

는 0이 아닌 소수부를 가진 숫자를 인코딩한다는 점에 유의하라. 따라서 스키마¶

   {"type": "int8"}

는 다음을 수락하고¶

   10

및¶

   10.0

및¶

   1.0e1

다음은 거부하며¶

   10.5

다음도 거부한다.¶

   false

이는 "false"가 전혀 숫자가 아니기 때문이다.¶

인스턴스가 수락되지 않으면, 이 경우의 오류 표시자는 인스턴스를 가리키는 "instancePath"와 "type"이라는 이름의 스키마 멤버를 가리키는 "schemaPath"를 가져야 한다.¶

예를 들어, 스키마¶

   {"type": "boolean"}

는 다음을 수락하지만¶

   false

다음은 거부한다.¶

   127

스키마¶

   {"type": "float32"}

는 다음을 수락하고¶

   10.5

및¶

   127

다음은 거부한다.¶

   false

스키마¶

   {"type": "string"}

는 다음을 수락하고¶

   "1985-04-12T23:20:50.52Z"

및¶

   "foo"

다음은 거부한다.¶

   false

스키마¶

   {"type": "timestamp"}

는 다음을 수락하지만¶

   "1985-04-12T23:20:50.52Z"

다음은 거부하고¶

   "foo"

및¶

   false

스키마¶

   {"type": "boolean", "nullable": true}

는 다음을 수락하고¶

   null

및¶

   false

다음은 거부한다.¶

   127

이 절에서 제시된 거부된 인스턴스의 모든 예에서, 생성할 오류 표시자는 다음과 같다.¶

   [{ "instancePath": "", "schemaPath": "/type" }]

3.3.4. 열거형

"enum" 형식은 값이 주어진 문자열 값 집합 중 하나여야 하는 인스턴스를 설명하기 위한 것이다. "enum" 형식의 구문은 Section 2.2.4에 설명되어 있다.¶

스키마가 "enum" 형식이면 다음과 같다.¶

• 스키마가 이름이 "nullable"이고 값이 boolean "true"인 멤버를 가지고 있으며, 인스턴스가 JSON 원시 값 "null"이면, 스키마는 그 인스턴스를 수락한다.¶

  그렇지 않으면:¶

  • E를 이름이 "enum"인 스키마 멤버의 값이라고 하자. 인스턴스는 E의 요소 중 하나와 같은 경우에 그리고 그 경우에만 수락된다.¶

인스턴스가 수락되지 않으면, 이 경우의 오류 표시자는 인스턴스를 가리키는 "instancePath"와 이름이 "enum"인 스키마 멤버를 가리키는 "schemaPath"를 가져야 한다.¶

예를 들어, 스키마¶

   { "enum": ["PENDING", "DONE", "CANCELED"] }

는 다음을 수락하고¶

   "PENDING"

및¶

   "DONE"

및¶

   "CANCELED"

다음 모두를 거부한다.¶

   0

및¶

   1

및¶

   2

및¶

   "UNKNOWN"

및¶

   null

오류 표시자는 다음과 같다.¶

   [{ "instancePath": "", "schemaPath": "/enum" }]

스키마¶

   { "enum": ["PENDING", "DONE", "CANCELED"], "nullable": true }

는 다음을 수락하고¶

   "PENDING"

및¶

   null

다음은 거부하고¶

   1

및¶

   "UNKNOWN"

오류 표시자는 다음과 같다.¶

   [{ "instancePath": "", "schemaPath": "/enum" }]

3.3.5. 요소

"elements" 형식은 배열이어야 하는 인스턴스를 설명하기 위한 것이다. 추가 하위 스키마가 배열의 요소를 설명한다. "elements" 형식의 구문은 Section 2.2.5에 설명되어 있다.¶

스키마가 "elements" 형식이면 다음과 같다.¶

• 스키마가 이름이 "nullable"이고 값이 boolean "true"인 멤버를 가지고 있으며, 인스턴스가 JSON 원시 값 "null"이면, 스키마는 그 인스턴스를 수락한다.¶

  그렇지 않으면:¶

  • S를 이름이 "elements"인 스키마 멤버의 값이라고 하자. 인스턴스는 다음이 모두 참인 경우에 그리고 그 경우에만 수락된다.¶

  • • 인스턴스는 배열이다. 그렇지 않으면, 이 경우의 오류 표시자는 인스턴스를 가리키는 "instancePath"와 이름이 "elements"인 스키마 멤버를 가리키는 "schemaPath"를 가져야 한다.¶
    • 인스턴스가 배열이면, 인스턴스의 모든 요소는 S에 의해 수락되어야 한다. 그렇지 않으면, 이 경우의 오류 표시자는 S를 인스턴스의 요소에 대해 평가하면서 발생한 모든 오류의 합집합이다.¶

예를 들어, 스키마¶

   {
     "elements": {
       "type": "float32"
     }
   }

는 다음을 수락하고¶

   []

및¶

   [1, 2, 3]

다음은 거부한다.¶

   null

오류 표시자는 다음과 같다.¶

   [{ "instancePath": "", "schemaPath": "/elements" }]

그리고 다음을 거부한다.¶

   [1, 2, "foo", 3, "bar"]

오류 표시자는 다음과 같다.¶

   [
     { "instancePath": "/2", "schemaPath": "/elements/type" },
     { "instancePath": "/4", "schemaPath": "/elements/type" }
   ]

스키마¶

   {
     "elements": {
       "type": "float32"
     },
     "nullable": true
   }

는 다음을 수락하고¶

   null

및¶

   []

및¶

   [1, 2, 3]

다음은 거부한다.¶

   [1, 2, "foo", 3, "bar"]

오류 표시자는 다음과 같다.¶

   [
     { "instancePath": "/2", "schemaPath": "/elements/type" },
     { "instancePath": "/4", "schemaPath": "/elements/type" }
   ]

3.3.6. 속성

"properties" 형식은 "struct"로 사용되는 JSON 객체를 설명하기 위한 것이다. "properties" 형식의 구문은 Section 2.2.6에 설명되어 있다.¶

스키마가 "properties" 형식이면 다음과 같다.¶

• 스키마가 이름이 "nullable"이고 값이 boolean "true"인 멤버를 가지고 있으며, 인스턴스가 JSON 원시 값 "null"이면, 스키마는 그 인스턴스를 수락한다.¶

  그렇지 않으면:¶

  • 인스턴스는 객체여야 한다.¶

    그렇지 않으면 스키마는 인스턴스를 거부한다. 이 경우의 오류 표시자는 인스턴스를 가리키는 "instancePath"와, 그러한 스키마 멤버가 존재한다면 이름이 "properties"인 스키마 멤버를 가리키는 "schemaPath"를 가져야 한다. 그러한 멤버가 존재하지 않으면, "schemaPath"는 이름이 "optionalProperties"인 스키마 멤버를 가리켜야 한다.¶

  • 인스턴스가 객체이고 스키마가 "properties"라는 이름의 멤버를 가지고 있다면, P를 이름이 "properties"인 스키마 멤버의 값이라고 하자. Section 2.2.6에 따라 P가 객체임을 안다. P 안의 모든 멤버 이름에 대해, 인스턴스 안에 같은 이름의 멤버가 존재해야 한다.¶

    그렇지 않으면 스키마는 인스턴스를 거부한다. 이 경우의 오류 표시자는 인스턴스를 가리키는 "instancePath"와, 방금 설명한 요구사항을 충족하지 못한 P의 멤버를 가리키는 "schemaPath"를 가져야 한다.¶

  • 인스턴스가 객체이면, P를 이름이 "properties"인 스키마 멤버의 값(존재하는 경우)이라고 하고, O를 이름이 "optionalProperties"인 스키마 멤버의 값(존재하는 경우)이라고 하자.¶

    인스턴스의 모든 멤버 I에 대해, P 또는 O 안에서 I의 이름과 같은 이름을 가진 멤버를 찾는다. Section 2.2.6에 따라 P와 O 모두가 그러한 멤버를 가질 수 없음을 안다. "discriminator tag exemption"이 I에 대해 유효하다면(Section 3.3.8 참조), I를 무시한다.¶

    그렇지 않으면:¶

    • P 또는 O 안에 그러한 멤버가 존재하지 않고, 검증이 "allow additional properties" 모드에 있지 않다면 (Section 3.1 참조), 스키마는 인스턴스를 거부한다.¶

      이 경우의 오류 표시자는 I를 가리키는 "instancePath"와 스키마를 가리키는 "schemaPath"를 가진다.¶

    • 그러한 멤버가 P 또는 O 안에 존재한다면, 이 멤버를 S라고 부른다. S가 I의 값을 거부하면, 스키마는 인스턴스를 거부한다.¶

      이 경우의 오류 표시자는 S를 I의 값에 대해 평가하여 나온 오류 표시자의 합집합이다.¶

• 인스턴스가 객체이면, 위 목록의 두 번째와 세 번째 글머리 항목에서 발생하는 여러 오류를 가질 수 있다. 이 경우 오류 표시자는 오류들의 합집합이다.¶

  예를 들어, 스키마¶

     {
       "properties": {
         "a": { "type": "string" },
         "b": { "type": "string" }
       },
       "optionalProperties": {
         "c": { "type": "string" },
         "d": { "type": "string" }
       }
     }
  

  ¶

  는 다음을 수락하고¶

     { "a": "foo", "b": "bar" }
  

  ¶

  및¶

     { "a": "foo", "b": "bar", "c": "baz" }
  

  ¶

  및¶

     { "a": "foo", "b": "bar", "c": "baz", "d": "quux" }
  

  ¶

  및¶

     { "a": "foo", "b": "bar", "d": "quux" }
  

  ¶

  다음은 거부한다.¶

     null
  

  ¶

  오류 표시자는 다음과 같다.¶

     [{ "instancePath": "", "schemaPath": "/properties" }]
  

  ¶

  그리고 다음을 거부한다.¶

     { "b": 3, "c": 3, "e": 3 }
  

  ¶

  오류 표시자는 다음과 같다.¶

     [
       { "instancePath": "",
         "schemaPath": "/properties/a" },
       { "instancePath": "/b",
         "schemaPath": "/properties/b/type" },
       { "instancePath": "/c",
         "schemaPath": "/optionalProperties/c/type" },
       { "instancePath": "/e",
         "schemaPath": "" }
     ]
  

  ¶

  대신 스키마가 그 밖에는 같지만 "additionalProperties: true"를 가지고 있었다면:¶

     {
       "properties": {
         "a": { "type": "string" },
         "b": { "type": "string" }
       },
       "optionalProperties": {
         "c": { "type": "string" },
         "d": { "type": "string" }
       },
       "additionalProperties": true
     }
  

  ¶

  그리고 인스턴스가 그대로였다면:¶

     { "b": 3, "c": 3, "e": 3 }
  

  ¶

  그때 인스턴스를 스키마에 대해 평가하여 나온 오류 표시자는 다음과 같을 것이다.¶

     [
       { "instancePath": "",
         "schemaPath": "/properties/a" },
       { "instancePath": "/b",
         "schemaPath": "/properties/b/type" },
       { "instancePath": "/c",
         "schemaPath": "/optionalProperties/c/type" },
     ]
  

  ¶

  이들은 최종 오류(인스턴스의 "e"라는 이름의 추가 멤버와 관련된 오류)가 더 이상 존재하지 않는 것을 제외하면 이전과 같은 오류들이다. 이는 "additionalProperties: true"가 스키마에서 "allow additional properties" 모드를 활성화하기 때문이다.¶

  마지막으로, 스키마¶

     {
       "nullable": true,
       "properties": {
         "a": { "type": "string" },
         "b": { "type": "string" }
       },
       "optionalProperties": {
         "c": { "type": "string" },
         "d": { "type": "string" }
       },
       "additionalProperties": true
     }
  

  ¶

  는 다음을 수락하지만¶

     null
  

  ¶

  다음은 거부한다.¶

     { "b": 3, "c": 3, "e": 3 }
  

  ¶

  오류 표시자는 다음과 같다.¶

     [
       { "instancePath": "",
         "schemaPath": "/properties/a" },
       { "instancePath": "/b",
         "schemaPath": "/properties/b/type" },
       { "instancePath": "/c",
         "schemaPath": "/optionalProperties/c/type" },
     ]
  

  ¶

3.3.7. 값

"values" 형식은 연관 배열로 사용되는 JSON 객체인 인스턴스를 설명하기 위한 것이다. "values" 형식의 구문은 Section 2.2.7에 설명되어 있다.¶

스키마가 "values" 형식이면 다음과 같다.¶

• 스키마가 이름이 "nullable"이고 값이 boolean "true"인 멤버를 가지고 있으며, 인스턴스가 JSON 원시 값 "null"이면, 스키마는 그 인스턴스를 수락한다.¶

  그렇지 않으면:¶

  • S를 이름이 "values"인 스키마 멤버의 값이라고 하자. 인스턴스는 다음이 모두 참인 경우에 그리고 그 경우에만 수락된다.¶

    • 인스턴스는 객체이다. 그렇지 않으면, 이 경우의 오류 표시자는 인스턴스를 가리키는 "instancePath"와 이름이 "values"인 스키마 멤버를 가리키는 "schemaPath"를 가져야 한다.¶
    • 인스턴스가 객체이면, 인스턴스의 모든 멤버 값은 S에 의해 수락되어야 한다. 그렇지 않으면, 이 경우의 오류 표시자는 S를 인스턴스의 멤버 값에 대해 평가하면서 발생한 모든 오류 표시자의 합집합이다.¶

예를 들어, 스키마¶

   {
     "values": {
       "type": "float32"
     }
   }

는 다음을 수락하고¶

   {}

및¶

   {"a": 1, "b": 2}

다음은 거부한다.¶

   null

오류 표시자는 다음과 같다.¶

   [{ "instancePath": "", "schemaPath": "/values" }]

그리고 다음을 거부한다.¶

   { "a": 1, "b": 2, "c": "foo", "d": 3, "e": "bar" }

오류 표시자는 다음과 같다.¶

   [
     { "instancePath": "/c", "schemaPath": "/values/type" },
     { "instancePath": "/e", "schemaPath": "/values/type" }
   ]

스키마¶

   {
     "nullable": true,
     "values": {
       "type": "float32"
     }
   }

는 다음을 수락하지만¶

   null

다음은 거부한다.¶

   { "a": 1, "b": 2, "c": "foo", "d": 3, "e": "bar" }

오류 표시자는 다음과 같다.¶

   [
     { "instancePath": "/c", "schemaPath": "/values/type" },
     { "instancePath": "/e", "schemaPath": "/values/type" }
   ]

3.3.8. 판별자

"discriminator" 형식은 C 계열 언어의 discriminated union 구성과 유사한 방식으로 사용되는 JSON 객체를 설명하기 위한 것이다. "discriminator" 형식의 구문은 Section 2.2.8에 설명되어 있다.¶

스키마가 "discriminator" 형식이면, 다음을 검증한다.¶

• 인스턴스가 객체인지,¶
• 인스턴스가 특정 "tag" 속성을 가지는지,¶
• 이 "tag" 속성의 값이 유효한 값 집합 안의 문자열인지, 그리고¶
• 인스턴스가 다른 스키마를 만족하는지. 여기서 이 다른 스키마는 "tag" 속성의 값에 기반해 선택된다.¶

"discriminator" 형식의 동작은 다른 키워드보다 더 복잡하다. CDDL에 익숙한 독자는 부록 B의 마지막 예제가 그 동작을 이해하는 데 도움이 될 수 있다. 이 절의 다음 내용은 "discriminator" 형식의 동작 설명과 몇 가지 예제이다.¶

스키마가 "discriminator" 형식이면 다음과 같다.¶

• D를 이름이 "discriminator"인 스키마 멤버라고 하자.¶
• M을 이름이 "mapping"인 스키마 멤버라고 하자.¶
• I를 그 이름이 D의 값과 같은 인스턴스 멤버라고 하자. I는 일부 거부된 인스턴스의 경우 존재하지 않을 수 있다.¶
• S를 그 이름이 I의 값과 같은 M의 멤버라고 하자. S는 일부 거부된 인스턴스의 경우 존재하지 않을 수 있다.¶

스키마가 이름이 "nullable"이고 값이 boolean "true"인 멤버를 가지고 있으며, 인스턴스가 JSON 원시 값 "null"이면, 스키마는 그 인스턴스를 수락한다. 그렇지 않으면, 인스턴스는 다음이 모두 참인 경우에 그리고 그 경우에만 수락된다.¶

• 인스턴스가 객체이다.¶

  그렇지 않으면, 이 경우의 오류 표시자는 인스턴스를 가리키는 "instancePath"와 D를 가리키는 "schemaPath"를 가져야 한다.¶

• 인스턴스가 JSON 객체이면, I가 존재해야 한다.¶

  그렇지 않으면, 이 경우의 오류 표시자는 인스턴스를 가리키는 "instancePath"와 D를 가리키는 "schemaPath"를 가져야 한다.¶

• 인스턴스가 JSON 객체이고 I가 존재한다면, I의 값은 문자열이어야 한다.¶

  그렇지 않으면, 이 경우의 오류 표시자는 I를 가리키는 "instancePath"와 D를 가리키는 "schemaPath"를 가져야 한다.¶

• 인스턴스가 JSON 객체이고 I가 존재하며 문자열 값을 가진다면, S가 존재해야 한다.¶

  그렇지 않으면, 이 경우의 오류 표시자는 I를 가리키는 "instancePath"와 M을 가리키는 "schemaPath"를 가져야 한다.¶

• 인스턴스가 JSON 객체이고, I가 존재하며, S가 존재한다면, 인스턴스는 S의 값을 만족해야 한다. Section 2에 따라, S의 값이 "properties" 형식의 스키마임을 안다. 인스턴스가 S의 값을 만족하는지 평가할 때 Section 3.3.6에서 제공되는 "discriminator tag exemption"을 I에 적용한다.¶

  그렇지 않으면, 이 경우의 오류 표시자는 "discriminator tag exemption"을 I에 적용한 상태에서 S의 값을 인스턴스에 대해 평가하여 나온 오류 표시자여야 한다.¶

위 목록 항목들은 상호 배타적인 방식으로 정의되어 있다. 주어진 인스턴스와 스키마에 대해, 위 목록 항목 중 정확히 하나가 적용된다.¶

예를 들어, 스키마¶

   {
     "discriminator": "version",
     "mapping": {
       "v1": {
         "properties": {
           "a": { "type": "float32" }
         }
       },
       "v2": {
         "properties": {
           "a": { "type": "string" }
         }
       }
     }
   }

는 다음을 거부한다.¶

   null

오류 표시자는 다음과 같다.¶

   [{ "instancePath": "", "schemaPath": "/discriminator" }]

(이는 인스턴스가 객체가 아닌 경우이다.)¶

또한 거부되는 것은 다음이다.¶

   {}

오류 표시자는 다음과 같다.¶

   [{ "instancePath": "", "schemaPath": "/discriminator" }]

(이는 I가 존재하지 않는 경우이다.)¶

또한 거부되는 것은 다음이다.¶

   { "version": 1 }

오류 표시자는 다음과 같다.¶

   [
     {
       "instancePath": "/version",
       "schemaPath": "/discriminator"
     }
   ]

(이는 I가 존재하지만 문자열 값을 가지지 않는 경우이다.)¶

또한 거부되는 것은 다음이다.¶

   { "version": "v3" }

오류 표시자는 다음과 같다.¶

   [
     {
       "instancePath": "/version",
       "schemaPath": "/mapping"
     }
   ]

(이는 I가 존재하고 문자열 값을 가지지만 S가 존재하지 않는 경우이다.)¶

또한 거부되는 것은 다음이다.¶

   { "version": "v2", "a": 3 }

오류 표시자는 다음과 같다.¶

   [
     {
       "instancePath": "/a",
       "schemaPath": "/mapping/v2/properties/a/type"
     }
   ]

(이는 I와 S가 존재하지만 인스턴스가 S의 값을 만족하지 않는 경우이다.)¶

마지막으로, 스키마는 다음을 수락한다.¶

   { "version": "v2", "a": "foo" }

이 인스턴스는 "version"이 "/mapping/v2/properties"에 언급되어 있지 않더라도 수락된다. "discriminator tag exemption"은 인스턴스를 S의 값에 대해 평가할 때 "version"이 추가 속성으로 처리되지 않도록 보장한다.¶

반대로, 같은 스키마이지만 "nullable"이 "true"인 경우를 고려하라. 스키마¶

   {
     "nullable": true,
      "discriminator": "version",
      "mapping": {
        "v1": {
          "properties": {
            "a": { "type": "float32" }
          }
        },
        "v2": {
          "properties": {
            "a": { "type": "string" }
          }
        }
      }
   }

는 다음을 수락한다.¶

   null

"discriminator" 형식을 예제로 더 설명하기 위해, Section 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" }
         }
       }
     }
   }

이 스키마는 다음을 수락하고¶

   { "event_type": "account_deleted", "account_id": "abc-123" }

및¶

   {
     "event_type": "account_payment_plan_changed",
     "account_id": "abc-123",
     "payment_plan": "PAID"
   }

및¶

   {
     "event_type": "account_payment_plan_changed",
     "account_id": "abc-123",
     "payment_plan": "PAID",
     "upgraded_by": "users/mkhwarizmi"
   }

다음은 거부한다.¶

   {}

오류 표시자는 다음과 같다.¶

   [{ "instancePath": "", "schemaPath": "/discriminator" }]

그리고 다음을 거부한다.¶

   { "event_type": "some_other_event_type" }

오류 표시자는 다음과 같다.¶

   [
     {
       "instancePath": "/event_type",
       "schemaPath": "/mapping"
     }
   ]

그리고 다음을 거부한다.¶

   { "event_type": "account_deleted" }

오류 표시자는 다음과 같다.¶

   [{
     "instancePath": "",
     "schemaPath": "/mapping/account_deleted/properties/account_id"
   }]

그리고 다음을 거부한다.¶

   {
     "event_type": "account_payment_plan_changed",
     "account_id": "abc-123",
     "payment_plan": "PAID",
     "xxx": "asdf"
   }

오류 표시자는 다음과 같다.¶

   [{
     "instancePath": "/xxx",
     "schemaPath": "/mapping/account_payment_plan_changed"
   }]