{"action":"created","issue":{"url":"https://api.github.com/repos/bali182/autocomplete-json/issues/64","repository_url":"https://api.github.com/repos/bali182/autocomplete-json","labels_url":"https://api.github.com/repos/bali182/autocomplete-json/issues/64/labels{/name}","comments_url":"https://api.github.com/repos/bali182/autocomplete-json/issues/64/comments","events_url":"https://api.github.com/repos/bali182/autocomplete-json/issues/64/events","html_url":"https://github.com/bali182/autocomplete-json/issues/64","id":216540435,"number":64,"title":"Relative references are not supported","user":{"login":"zandaleph","id":3478453,"avatar_url":"https://avatars3.githubusercontent.com/u/3478453?v=3","gravatar_id":"","url":"https://api.github.com/users/zandaleph","html_url":"https://github.com/zandaleph","followers_url":"https://api.github.com/users/zandaleph/followers","following_url":"https://api.github.com/users/zandaleph/following{/other_user}","gists_url":"https://api.github.com/users/zandaleph/gists{/gist_id}","starred_url":"https://api.github.com/users/zandaleph/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/zandaleph/subscriptions","organizations_url":"https://api.github.com/users/zandaleph/orgs","repos_url":"https://api.github.com/users/zandaleph/repos","events_url":"https://api.github.com/users/zandaleph/events{/privacy}","received_events_url":"https://api.github.com/users/zandaleph/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":2,"created_at":"2017-03-23T19:10:02Z","updated_at":"2017-03-24T02:09:47Z","closed_at":null,"body":"I'm trying to write a SchemaProvider which provides a collection of related schemata which share some underlying types.  Rather than copy-pasting the shared types into each schema, I'd prefer to use references to a shared schema which defines the shared types.  For security / deployment reasons I cannot put these on a webserver (ruling out http references), and because I don't know the details of other user's Atom installs I can't use absolute file references either.  Based on https://spacetelescope.github.io/understanding-json-schema/structuring.html#reuse , it seems that relative urls should be viable, however the following example seems to fail:\r\n\r\n```\r\n# common.schema.json\r\n{\r\n  \"$schema\": \"http://json-schema.org/schema#\",\r\n  \"id\": \"my.common.schema.json\",\r\n  \"definitions\": {\r\n    \"numberArray\": {\r\n      \"type\": \"array\",\r\n      \"items\": {\r\n        \"type\": \"number\"\r\n      }\r\n    }\r\n  }\r\n}\r\n```\r\n\r\n```\r\n# specific.schema.json\r\n\r\n{\r\n  \"$schema\": \"http://json-schema.org/schema#\",\r\n  \"id\": \"my.specific.schema.json\",\r\n  \"type\": \"array\",\r\n  \"items\": {\r\n    \"type\": \"object\",\r\n    \"properties\": {\r\n      \"id\": {\"type\": \"number\"},\r\n      \"digits\": {\"$ref\": \"common.schema.json#/definitions/Metrics\"},\r\n    },\r\n    \"required\": [\"id\", \"replicaNo\", \"taskTypeId\"]\r\n  }\r\n}\r\n```\r\n\r\nWhen I supply `file:///path/to/specific.schema.json` to autocomplete-json through the https://github.com/bali182/autocomplete-json/wiki/SchemaProvider interface it does not work.  However, if I pull the common definition into the file, it does.\r\n\r\nFrom reading `json-schema-resolver.js` and `json-schema-loader.js`, it appears you don't use the current uri / id as a base url for resolving relative uris.  Could you take a look at supporting relative references?"},"comment":{"url":"https://api.github.com/repos/bali182/autocomplete-json/issues/comments/288913606","html_url":"https://github.com/bali182/autocomplete-json/issues/64#issuecomment-288913606","issue_url":"https://api.github.com/repos/bali182/autocomplete-json/issues/64","id":288913606,"user":{"login":"bali182","id":3879181,"avatar_url":"https://avatars2.githubusercontent.com/u/3879181?v=3","gravatar_id":"","url":"https://api.github.com/users/bali182","html_url":"https://github.com/bali182","followers_url":"https://api.github.com/users/bali182/followers","following_url":"https://api.github.com/users/bali182/following{/other_user}","gists_url":"https://api.github.com/users/bali182/gists{/gist_id}","starred_url":"https://api.github.com/users/bali182/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/bali182/subscriptions","organizations_url":"https://api.github.com/users/bali182/orgs","repos_url":"https://api.github.com/users/bali182/repos","events_url":"https://api.github.com/users/bali182/events{/privacy}","received_events_url":"https://api.github.com/users/bali182/received_events","type":"User","site_admin":false},"created_at":"2017-03-24T02:09:47Z","updated_at":"2017-03-24T02:09:47Z","body":"The id concept makes a lot of sense, sorry I didn't get it the first time. The resolution order however is tricky since it has to be done async, and if let's say schema `A` references a child from `B` by id, but the resolution of `A` was requested first (or only) then it has no way of knowing that someone might provide the schema later from which `B` can be resolved. Or am I overcomplicating this? It would trivial if you provide all root URIs (be that remote, file or whatever) for your schemas where any piece of the final schema resides, they are all resolved first, then the final schema is pieced together from the already resolved sub-schemas.\r\n\r\nThis however as far as I see would be a breaking change, since currently you can only provide a single path to a schema in a provider and the above requires multiple.\r\n\r\nAlso right now I'm really thinking about figuring out a proper way to do this and create a separate module with good test coverage to tackle this problem and move it entirely out of the scope of the plugin, since I feel like it will get a bit too messy in here..."}}
{"actor":{"display_login":"bali182"}}