为什么 JSONSchema 同时允许不同类型的约束答案

【问题标题】：Why JSONSchema allows different types constraints simultaneously为什么 JSONSchema 同时允许不同类型的约束
【发布时间】：2016-12-09 20:21:38
【问题描述】：

假设我想将 JSON 对象限制为 > 42 的整数或此类整数的数组。

有效的 draft-04 架构

{
    "minimum" : 42,
    "items" : { "type":"integer", "minimum" : 42 }
}

验证 42 和 [52, 62] 以及 "hello"。所以构造模式的方法是错误的。

除了正确的模式之外还包含多余的“type”字段，因为“items”暗示了数组类型：

{
    "oneOf": [
       { 
          "type": "integer", 
          "minimum" : 42 
       },
       {  
          "type": "array", 
          "items" : { "type":"integer", "minimum" : 42 }
       }
     ]

}

问题

同时允许不同类型约束的原因是什么？

这是一个糟糕的设计还是我错过了什么？

【问题讨论】：

标签： jsonschema

【解决方案1】：

https://github.com/json-schema/json-schema/issues/172

此链接上的讨论应该可以帮助您理解为什么它会以这种方式工作。简短的版本是 JSON Schema 被设计为简单、一致和灵活。这些品质允许在模式中具有更大的表现力，但它也允许您编写您可能不应该编写的模式。在链接讨论的最后，我给出了一些例子来说明这种表达能力是如何有用的，并且如果一些粗糙的边缘被收紧，那么 JSON Schema 会变得不那么优雅。

【讨论】：

感谢您的链接。有趣的讨论。因此，JSON Schema 在某种程度上被破坏了。如果参数暗示类型，我认为可以避免许多问题。它使架构对读者来说更加清晰，甚至可以使架构更加简洁。
嗯，这不是我希望你从讨论中得到的结论。我认为要求（或暗示）type 破坏了 JSON Schema 架构，这是一个坏主意。但是，如果您阅读了整个讨论，您应该有足够的信息来得出自己的结论。
讨论中有很多好的观点，但它们往往相互矛盾。它使我确信当前的 RFC 草案远非理想。我认为除了写一个没有这些陷阱的更好的提案外，没有什么可做的。