Are there any standards or drafts that even use 'relative' pointers?I haven't really seen any compelling cases for them, in any event.
"Moving forwards" right now means fixing bad language and broken references, mostly, so I think we can still move forward.
Relative pointers would mean breaking several JSON Schema conventions that are enforced for performance. I think for most all of the new features proposed, there's ways to implement them without relative pointers.
Do you have a list of things that this feature would be desirable for?
On Thursday, September 15, 2016 at 11:24:24 AM UTC-7, Austin William Wright wrote:Are there any standards or drafts that even use 'relative' pointers?I haven't really seen any compelling cases for them, in any event.The "advanced templating" proposal, which would now be a v6 proposal, relies on them and was absolutely essential for the success of the JSON Schema-based project at Riverbed. You can see the template+vars pattern all over the published service definitions. I can pull up some specific examples if that would be helpful. We didn't exactly use hyper-schema, but what we did use was mostly assembled out of hyper-schema ideas (I will do another big analysis for hyper-schema soon like the one I did for the re-use proposals).So to me, hyper-media APIs based on JSON Schema are a non-starter without advanced templating and therefore also relative JSON pointers. It's simply not feasible without them.
"Moving forwards" right now means fixing bad language and broken references, mostly, so I think we can still move forward.This doesn't have anything to do with moving forwards (or not) on JSON Schema Draft 05 (as purely a clean-up of Draft 04). I assume you've got the Draft 05 work under control, and while I can help with the various mechanical chores for that, I'm mostly looking ahead to Draft 06. Draft 05 is a key step in getting this going again, but it (intentionally) will not address the significant limitations of Draft 04.Relative pointers would mean breaking several JSON Schema conventions that are enforced for performance. I think for most all of the new features proposed, there's ways to implement them without relative pointers.Could you elaborate on this a bit? Unless I'm forgetting something, if you don't actually use relative pointers in your schema, the performance impact is limited to checking for whether your pointers start with '/' or with a number. Any code for dealing with relative JSON pointers should only come into play if you find at least one pointer that starts with a number.
Do you have a list of things that this feature would be desirable for?The 'vars' section of a link from within a schema that is re-used in larger schemas. Using a relative pointer means that the re-usable schema is re-usable from anywhere within a larger schema. If you must use an absolute pointer, you cannot include links except in the final schema because you will not know what the absolute paths will look like.I can probably come up with more examples, but that is the most immediately obvious one that cannot be done with an absolute pointer.
thanks,-henry
On Thursday, September 15, 2016 at 3:51:31 PM UTC-7, Henry Andrews wrote:The "advanced templating" proposal, which would now be a v6 proposal, relies on them and was absolutely essential for the success of the JSON Schema-based project at Riverbed. You can see the template+vars pattern all over the published service definitions. I can pull up some specific examples if that would be helpful. We didn't exactly use hyper-schema, but what we did use was mostly assembled out of hyper-schema ideas (I will do another big analysis for hyper-schema soon like the one I did for the re-use proposals).So to me, hyper-media APIs based on JSON Schema are a non-starter without advanced templating and therefore also relative JSON pointers. It's simply not feasible without them.I think I should take a look at some concrete examples then. I just can't think of anything myself that would need this.JSON Hyper-schema definitely still needs a bit more functionality to cover even a majority of use cases, I think (for example, see <https://github.com/json-schema-org/json-schema-spec/issues/49>). But I'm really squeamish about turning JSON Schema into a fully fledged Turing-complete language.Or maybe that is to say, if your JSON API is so compact (or in some cases, so poorly designed) that you need a lot of powerful functionality to extract links from it, maybe we should just define a way to link to a script that will generate a list of links from your JSON document.
Relative pointers would mean breaking several JSON Schema conventions that are enforced for performance. I think for most all of the new features proposed, there's ways to implement them without relative pointers.Could you elaborate on this a bit? Unless I'm forgetting something, if you don't actually use relative pointers in your schema, the performance impact is limited to checking for whether your pointers start with '/' or with a number. Any code for dealing with relative JSON pointers should only come into play if you find at least one pointer that starts with a number.The big theory behind JSON Schema is that if this validates:var schema = { type:"object", properties:{"list": { type: "string" }} };assertValid(instance, schema);// ... then so will this, always, 100% of the time:assertValid(instance.list, schema.properties.list);But if you're using relative pointers, then that breaks this property, because the validation function doesn't know what the original "instance" was in this case, only "instance.list".