gregsdennis
commented
3 years ago The ability to follow "relative" JSON pointers (i.e. URLS with just the fragment part)
I think some clarification needs to be made here.
All JSON Pointers are fully contained within the fragment of a URL. Generally, it's the entire fragment.
However, there is a thing called a Relative JSON Pointer, which builds upon the base spec. It prefixes the standard Pointer with a positive integer. This number is the number of parent levels to move up from the current location before dereferencing the rest of the pointer.
This spec doesn't intend to use the relative ones, only the base pointer definition, if anything.
cabo
glyn
In the W3C Web of Things, we have been working on a new standard for Discovery (which looks up metadata about IoT devices encoded in JSON-LD files) that includes JSON Path as one query mechanism. We are therefore very happy to see this effort to standardize JSON Path, as it will make it much much easier to reference (and keep consistent) in a W3C Recommendation (our alternative would be to make up our own JSON Path spec, which we obviously want to avoid at all costs). For general information on WoT Discovery, please see the w3c/wot-discovery repo and in particular the Editor's Draft of our spec. I should mention we also plan to support XPath and SPARQL as optional alternative query languages but would like to make JSON Path the basic requirement for all implementations.
We will likely follow up with other issues later related to the use of JSON Path WoT Discovery more generally later; however lately we have also been discussing geolocation and the use of JSON Pointers to define the location of this information in order to deal with various use cases like devices installed in a static location, devices using other devices for their location, devices with dynamic updates of location (vehicles, etc). Ultimately we would like to have a set of "geolocation filters" in WoT Discovery that lets us filter query results by location. These can be independent of JSON Path; however, we first have to collect the geolocation information together with a JSON Path query, and that (at least) requires the following:
See my geolocation proposal for a writeup and some examples. Note there are ALSO examples of JSON pointers referring to data schemas and to external files in that proposal, both of which would require an additional dereferencing step, and it would be OK to NOT support these in JSON Path (or rather, leave it up to the consumer to follow these external references themselves, so unresolved JSON Pointers could be included in the result in these cases).
If the above is confusing, I apologize, but let's discuss and hopefully I can clarify.