{"action":"created","issue":{"url":"https://api.github.com/repos/json-schema-org/json-schema-spec/issues/160","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/160/labels{/name}","comments_url":"https://api.github.com/repos/json-schema-org/json-schema-spec/issues/160/comments","events_url":"https://api.github.com/repos/json-schema-org/json-schema-spec/issues/160/events","html_url":"https://github.com/json-schema-org/json-schema-spec/issues/160","id":191244215,"number":160,"title":"Simplify schema re-use (ids, baseURI, etc.) - $uri, $id, $call","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},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":7,"created_at":"2016-11-23T11:16:11Z","updated_at":"2016-11-23T21:47:09Z","closed_at":null,"body":"Everybody seems to agree that base URI change is one area of the standard that:\r\n- lacks compatibility between implementations even only in JavaScript\r\n- takes substantial efforts to implement, even inconsistently\r\n- rarely used\r\n\r\nLet's think for a second what problems id and $ref solve. The only problem that really needs to be solved is schema re-use (and the usage practice shows it). If you were writing code, the file traditionally defines a namespace and all the symbols that can be accessed from outside of the file should be explicitly made public. Although @awwright cites the departure from the file model in some standard bodies, it doesn't seem to be relevant to software development and JSON, and the fact there is JSON-LD means little for JSON schema, there should be JSON-LD schema for it. Software developers will not depart from file model in a hurry and unless JSON-schema acknowledges it it would simply lose touch with them.\r\n\r\nI suggest that to both enable code re-use and  ensure the stability of it, we require explicitly declaring pointers to objects that can be used from outside of the schema file. I.e. not only suggesting to drop base URI change from the spec but also drop JSON pointer support in references. That would allow schema authors to have clearly defined symbols that can be used outside and at the same time have freedom to refactor and restructure the rest of their schemas as they wish. One of the valid arguments against $merge was that schema authors may want to prevent modification. This argument equally applies to the desire of popular schema authors to prevent direct access to some areas of the schema and only publish some access points that they would maintain in consistent way (like a schema public API).\r\n\r\nThe proposal is to:\r\n- use one attribute as schema uri that identifies the schema globally and where it (optionally) can be retrieved from. E.g. $uri. This attribute can be used only once per schema file on the top level only and it is also a base URI for other references inside.\r\n- use another attribute to define public names pointing to parts of the schema that can be re-used in other schemas. E.g. $id. This keyword value MUST be identifier (`^[a-z]+[a-z0-9_]*$` for public names that can be accessed from outside of the schema file and `^_[a-z]+[a-z0-9_]*$` for private names that can only be used within the file) and its value MUST be unique within the file; redefining it would make schema invalid. The $id keyword should be used at the root of sub-schema that will be referenced by it.\r\n- references should use the format `<uri>#<id>` for references to other schemas (and `<uri>` will be resolved based on $uri) and `#<id>` for references within the file (which is consistent with $uri providing the base uri for resolution). Given that $ref implies using JSON pointer and using it violates isolation (by providing direct access into private code that can be changed without notice), the proposal is to drop $ref and instead use some other keyword as part of JSON-schema spec, e.g. $call and/or $include. Both keywords can be used with different meaning - $call would be validated in the context of the source schema and $include in the current context. $include is optional, $call is more or less what we have now.\r\n\r\nI appreciate that this is the most radical change proposal to simplify schema re-use issue. Please consider it not comparing with what we have now, because we have a mess leading to the lack of compatibility, but from the point of view of existing software development practices. Modularisation, isolation, etc. are normal things in writing code, but for some reasons they are not available to schema authors who craft thousand line documents simply to avoid using $ref that is not consistently implemented and have no way to reliably expose anything less than the whole schema file (reliably = provide guarantee for consumers that it won't change without notice).\r\n\r\nI think many of the proposals previously submitted here are focussed on theoretical aspects rather than on practical problems of users and implementations. E.g. @awwright repeatedly cites XML and HTML as inspiration, and I think that these arguments although theoretically correct are in essence fundamentally flawed and completely ignore the fact that JSON is on purpose a much simpler standard and that it is the main reason for its wide adoption. Given that this standard is JSON-Schema and not JSON-LD schema or XML-schema I don't see why arguments referring to the practices existing there should be seriously considered here, while the arguments referring to the actual usage practice of JSON-schema should be ignored. I suggest we ignore all references to XML/HTML practices as irrelevant for JSON Schema.\r\n\r\nI would very much appreciate the feedback from @awwright @handrews @Relequestual @fge @jdesrosiers and in particular from the people who were implementing base URI change in existing JSON schema validators: @mafintosh @bugventure @AlexeyGrishin @atrniv @zaggino @automatthew @tdegrunt @Prestaul @natesilva @geraintluff @daveclayton @erosb @stevehu @Julian @hoxworth @hasbridge @justinrainbow @yuloh @JamesNK @rsuter @seagreen @sigu-399 (I see very few people from this list in these conversations which is another sign of standard deterioration and I don't think any decisions about changing the standard should be made without the wider involvement of people who create validators)."},"comment":{"url":"https://api.github.com/repos/json-schema-org/json-schema-spec/issues/comments/262637871","html_url":"https://github.com/json-schema-org/json-schema-spec/issues/160#issuecomment-262637871","issue_url":"https://api.github.com/repos/json-schema-org/json-schema-spec/issues/160","id":262637871,"user":{"login":"seagreen","id":1310143,"avatar_url":"https://avatars.githubusercontent.com/u/1310143?v=3","gravatar_id":"","url":"https://api.github.com/users/seagreen","html_url":"https://github.com/seagreen","followers_url":"https://api.github.com/users/seagreen/followers","following_url":"https://api.github.com/users/seagreen/following{/other_user}","gists_url":"https://api.github.com/users/seagreen/gists{/gist_id}","starred_url":"https://api.github.com/users/seagreen/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/seagreen/subscriptions","organizations_url":"https://api.github.com/users/seagreen/orgs","repos_url":"https://api.github.com/users/seagreen/repos","events_url":"https://api.github.com/users/seagreen/events{/privacy}","received_events_url":"https://api.github.com/users/seagreen/received_events","type":"User","site_admin":false},"created_at":"2016-11-23T21:47:09Z","updated_at":"2016-11-23T21:47:09Z","body":"> parameters, macros etc\r\n\r\nNot sure I agree with this.\r\n\r\nI may have an odd approach to things, but my personal view of what JSON Schema should be is inspired by the old [ECMA JSON specification](http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf):\r\n\r\n> Because it  is so simple,  it is not expected that  the JSON grammar  will ever change.\r\n\r\nI think this is a good thing to aspire to with JSON Schema as well. (Obviously we won't come as close as JSON itself because we have a harder problem, but we can at least try). Validators like `\"items\"` are great because they're so simple -- I don't think we'll ever need to change `\"items\"`. \r\n\r\nProgramming language features are a different story. There are thousands of them we could add and they could be implemented in many different ways. If we start adding programming features to JSON Schema our chance of ever converging on a \"simple, unlikely to change again\" specification drops away entirely."}}
{"actor":{"display_login":"seagreen"}}