{"action":"created","issue":{"url":"https://api.github.com/repos/json-schema-org/json-schema-spec/issues/77","repository_url":"https://api.github.com/repos/json-schema-org/json-schema-spec","labels_url":"https://api.github.com/repos/json-schema-org/json-schema-spec/issues/77/labels{/name}","comments_url":"https://api.github.com/repos/json-schema-org/json-schema-spec/issues/77/comments","events_url":"https://api.github.com/repos/json-schema-org/json-schema-spec/issues/77/events","html_url":"https://github.com/json-schema-org/json-schema-spec/issues/77","id":182080963,"number":77,"title":"v6 validation: exclusive minimum/maximum validation should not rely on keyword combinations","user":{"login":"handrews","id":2358015,"avatar_url":"https://avatars.githubusercontent.com/u/2358015?v=3","gravatar_id":"","url":"https://api.github.com/users/handrews","html_url":"https://github.com/handrews","followers_url":"https://api.github.com/users/handrews/followers","following_url":"https://api.github.com/users/handrews/following{/other_user}","gists_url":"https://api.github.com/users/handrews/gists{/gist_id}","starred_url":"https://api.github.com/users/handrews/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/handrews/subscriptions","organizations_url":"https://api.github.com/users/handrews/orgs","repos_url":"https://api.github.com/users/handrews/repos","events_url":"https://api.github.com/users/handrews/events{/privacy}","received_events_url":"https://api.github.com/users/handrews/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/json-schema-org/json-schema-spec/labels/enhancement","name":"enhancement","color":"84b6eb"},{"url":"https://api.github.com/repos/json-schema-org/json-schema-spec/labels/Feedback%20period","name":"Feedback period","color":"fbca04"}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":{"url":"https://api.github.com/repos/json-schema-org/json-schema-spec/milestones/2","html_url":"https://github.com/json-schema-org/json-schema-spec/milestones/draft-6","labels_url":"https://api.github.com/repos/json-schema-org/json-schema-spec/milestones/2/labels","id":2056242,"number":2,"title":"draft-6","description":"","creator":{"login":"awwright","id":437517,"avatar_url":"https://avatars.githubusercontent.com/u/437517?v=3","gravatar_id":"","url":"https://api.github.com/users/awwright","html_url":"https://github.com/awwright","followers_url":"https://api.github.com/users/awwright/followers","following_url":"https://api.github.com/users/awwright/following{/other_user}","gists_url":"https://api.github.com/users/awwright/gists{/gist_id}","starred_url":"https://api.github.com/users/awwright/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/awwright/subscriptions","organizations_url":"https://api.github.com/users/awwright/orgs","repos_url":"https://api.github.com/users/awwright/repos","events_url":"https://api.github.com/users/awwright/events{/privacy}","received_events_url":"https://api.github.com/users/awwright/received_events","type":"User","site_admin":false},"open_issues":11,"closed_issues":1,"state":"open","created_at":"2016-10-08T09:22:52Z","updated_at":"2016-10-11T11:50:30Z","due_on":null,"closed_at":null},"comments":6,"created_at":"2016-10-10T18:21:17Z","updated_at":"2016-10-11T13:33:09Z","closed_at":null,"body":"This is somewhat related to the general idea of issue #55 (clearly document validation principles).  One such principle is that for the most part, each schema validation keyword can be evaluated against an instance independent of the presence, absence, or value of any other keyword.  This is a highly desirable property when refactoring or otherwise reasoning about complex schemas.\r\n\r\nMore formally, for nearly all validation keywords k1, k2, k3... the following holds true:\r\n\r\n```JSON\r\n{\r\n    \"k1\": \"something\",\r\n    \"k2\": {},\r\n    \"k3\": [\"etc.\"]\r\n}\r\n```\r\n\r\nis equivalent to\r\n\r\n```JSON\r\n{\r\n    \"allOf\": [\r\n        {\"k1\": \"something\"},\r\n        {\"k2\": {}},\r\n        {\"k3\": [\"etc.\"]}\r\n    ]\r\n}\r\n```\r\n\r\nThere are only four exceptions:\r\n\r\n* `minimum` is controlled by `exclusiveMinimum`'s value\r\n* `maximum` is controlled by `exclusiveMaximum`'s value\r\n* `additionalItems` is controlled by the value of `items`\r\n* `additionalProperties` is controlled by the values of `properties` and `patternProperties`\r\n\r\nThe issues around `additionalItems` and `additionalProperties` are outside the scope of this issue, but I mention them as they (especially `additionalProperties`) are more obvious examples of the problems this sort of dependency causes.  In particular, the behavior when working with `allOf` can be counter-intuitive.\r\n\r\nGetting back to numeric validation, here is how `minimum` and `maximum` behave:\r\n\r\n```JSON\r\n{\r\n    \"type\": \"number\",\r\n    \"minimum\": 0,\r\n    \"exclusiveMinimum\": true,\r\n    \"maximum\": 1,\r\n    \"exclusiveMaximum\": true\r\n}\r\n```\r\n\r\nis equivalent to\r\n\r\n```JSON\r\n{\r\n    \"allOf\": [\r\n        {\"type\": \"number\"},\r\n        {\r\n            \"minimum\": 0,\r\n            \"exclusiveMinimum\": true\r\n        },\r\n        {\r\n            \"maximum\": 1,\r\n            \"exclusiveMaximum\": true\r\n        }\r\n    ]\r\n}\r\n```\r\n\r\nbut cannot be further separated.  This is particularly vexing since `exclusiveMinimum` and `exclusiveMaximum` could have been defined to take numbers like this:\r\n\r\n```JSON\r\n{\r\n    \"type\": \"number\",\r\n    \"exclusiveMinimum\": 0,\r\n    \"exclusiveMaximum\": 1\r\n}\r\n```\r\n\r\nwhich now behaves nicely, being equivalent to this:\r\n\r\n```JSON\r\n{\r\n    \"allOf\": [\r\n        {\"type\": \"number\"},\r\n        {\"exclusiveMinimum\": 0},\r\n        {\"exclusiveMaximum\": 1}\r\n    ]\r\n}\r\n```\r\n\r\nI propose that in Draft 06 we either change the value of `exclusiveMinimum`/`exclusiveMaximum` or replace them with differently named keywords that take numeric values.  Migrating from Draft 05 to Draft 06 for this would be easily scriptable, as the presence of the old `exclusiveMinimum` or `exclusiveMaximum` keywords with boolean value `true` just means to replace the boolean with the value of `minimum` or `maximum` respectively, and remove those properties (and change the name of the \"exclusive\" keywords if we replace them with new names rather than changing their type)."},"comment":{"url":"https://api.github.com/repos/json-schema-org/json-schema-spec/issues/comments/252917575","html_url":"https://github.com/json-schema-org/json-schema-spec/issues/77#issuecomment-252917575","issue_url":"https://api.github.com/repos/json-schema-org/json-schema-spec/issues/77","id":252917575,"user":{"login":"epoberezkin","id":2769109,"avatar_url":"https://avatars.githubusercontent.com/u/2769109?v=3","gravatar_id":"","url":"https://api.github.com/users/epoberezkin","html_url":"https://github.com/epoberezkin","followers_url":"https://api.github.com/users/epoberezkin/followers","following_url":"https://api.github.com/users/epoberezkin/following{/other_user}","gists_url":"https://api.github.com/users/epoberezkin/gists{/gist_id}","starred_url":"https://api.github.com/users/epoberezkin/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/epoberezkin/subscriptions","organizations_url":"https://api.github.com/users/epoberezkin/orgs","repos_url":"https://api.github.com/users/epoberezkin/repos","events_url":"https://api.github.com/users/epoberezkin/events{/privacy}","received_events_url":"https://api.github.com/users/epoberezkin/received_events","type":"User","site_admin":false},"created_at":"2016-10-11T13:33:09Z","updated_at":"2016-10-11T13:33:09Z","body":"Schema is fundamentally different from code - it is often manipulated and constructed with code. But my main argument against cosmetic changes is that introduces higher cost than benefits to everybody - both users and implementations. I see absolutely no reason to change existing schemas unless it improves the functionality. It is a change based on opinions and preferences; in my opinion :) it is always better to avoid such changes.\r\n\r\nThe main priority should be the consistency, it helps users to continue using the standard. If you both introduce new valuable features and make changes that require migration effort, then instead of switching to a new version, users can switch to something else completely.\r\n\r\nThat's exactly the reason why programming languages only extend and almost never change their semantics - it becomes too costly and risky for users to upgrade versions.\r\n\r\nWe can't really use common sense and analogies with other languages as the main decision criteria - the existing base of users should be the main priority. There are plenty of improvements to make to the standard without changing what works. Why are you so keen to introduce confusion and cause unnecessary efforts to migrate to the next version? What is the value? The fact that somebody is confused with the way it is, likes it more etc. are not strong enough arguments for a change I think.\r\n\r\nAlso, bear in mind, that by changing existing semantics you invalidate all the existing manuals, documentations, etc., so you complicate not only migration but also the adoption of the standard. There were quite a few promising technologies over the past 40 years that died exactly because people who were pushing their development at some point decided that they \"knew better\" and instead of evolving and extending started to redefine things. The result was always the same - people switch to a different technology, that has no past baggage. One of the latest casualty of \"knowing better\" is probably Angular web framework. To me, the choice is simple, you either redefine something from scratch, in which case you may or may not get a sufficient user base for a new thing, or you fully respect the baggage you have and live with it, apart from cases when the change brings some serious improvement. I completely fail to see what this serious improvement is in this and some other similar proposed changes."}}
{"actor":{"display_login":"epoberezkin"}}