JSON-Schema: "allof" mit "additionalProperties"

[Autor des Entwurfs v4 Validierung Skillung hier]

Haben Sie stolperte über die häufigsten Probleme in JSON-Schema, das heißt, seine grundlegende Unfähigkeit, die Vererbung als Benutzer erwarten; aber zur gleichen Zeit ist es eines der Kern-features.

Wenn du dies tust:

"allOf": [ { "schema1": "here" }, { "schema2": "here" } ]

schema1 und schema2 haben keine wissen eines anderen; Sie werden ausgewertet, in Ihrem eigenen Kontext.

In Ihrem Szenario, die vielen, vielen Menschen begegnen, die Sie erwarten, dass die definierten Eigenschaften in schema1 bekannt schema2; aber dies ist nicht der Fall und wird es nie sein.

Dieses problem ist der Grund, warum ich diese zwei Vorschläge für den Entwurf von v5:

• strictProperties,
• merge.

Ihrem schema für shipping_address wäre dann:

{
    "merge": {
        "source": { "$ref": "#/definitions/address" },
        "with": {
            "properties": {
                "type": { "enum": [ "residential", "business" ] }
            }
        }
    }
}

zusammen mit der Definition strictProperties zu true im address.

Ich bin übrigens auch der Autor der website, auf die Sie sich beziehen.

Nun, lassen Sie mich wieder ansetzen zu Entwurf v3. Entwurf v3 hat definieren extends, und sein Wert war entweder ein schema oder ein array von schemas. Durch die definition dieses Schlüsselwort, das bedeutete, dass die Instanz musste um gültig zu sein, gegen das aktuelle schema und alle schemas angegeben in extends; im Grunde Entwurf v4 ist allOf Entwurf v3 extends.

Betrachten Sie diese (draft v3):

{
    "extends": { "type": "null" },
    "type": "string"
}

Und jetzt das:

{
    "allOf": [ { "type": "string" }, { "type": "null" } ]
}

Sind Sie gleich. Oder vielleicht das?

{
    "anyOf": [ { "type": "string" }, { "type": "null" } ]
}

Oder?

{
    "oneOf": [ { "type": "string" }, { "type": "null" } ]
}

Alles in allem bedeutet dies, dass extends im Entwurf v3 nie wirklich getan hat, was Menschen erwartet, es zu tun. Mit dem Entwurf v4 *Of Schlüsselwörter sind klar definiert.

Aber das problem, das Sie haben, ist das am häufigsten auftretende problem, bei weitem. Daher meine Vorschläge, die stillen würde diese Quelle von Missverständnissen ein für alle mal!

InformationsquelleAutor der Antwort fge

Hier ist eine leicht vereinfachte version von Yves-M-Lösung:

{
  "$schema": "http://json-schema.org/draft-04/schema#",
  "definitions": {
    "address": {
      "type": "object",
      "properties": {
        "street_address": {
          "type": "string"
        },
        "city": {
          "type": "string"
        },
        "state": {
          "type": "string"
        }
      },
      "required": [
        "street_address",
        "city",
        "state"
      ]
    }
  },
  "type": "object",
  "properties": {
    "billing_address": {
      "$ref": "#/definitions/address"
    },
    "shipping_address": {
      "allOf": [
        {
          "$ref": "#/definitions/address"
        }
      ],
      "properties": {
        "type": {
          "enum": [
            "residential",
            "business"
          ]
        },
        "street_address": {},
        "city": {},
        "state": {}
      },
      "required": [
        "type"
      ],
      "additionalProperties": false
    }
  }
}

Dadurch bleibt die Validierung der geforderten Eigenschaften in der Basis address schema, und fügt nur die benötigten type Eigenschaft in der shipping_address.

Es ist bedauerlich, dass additionalProperties nimmt nur die unmittelbaren, Geschwister-level-Eigenschaften berücksichtigt. Vielleicht gibt es einen Grund für diese. Aber das ist, warum wir brauchen, um zu wiederholen die vererbten Eigenschaften.

Hier, wir wiederholen die vererbten Eigenschaften in vereinfachter form, mit leeren Objekt-syntax. Dies bedeutet, dass Eigenschaften mit diesen Namen würde gültig sein, egal, welche Art von Wert, den Sie enthalten. Aber verlassen wir uns auf die allOf Stichwort zu erzwingen, die Typ-Einschränkungen (und andere Einschränkungen) erklärt in der Basis address schema.

InformationsquelleAutor der Antwort Ted Epstein