Revive Relative JSON Pointer I-D

[handrews]

The $data proposal (#51) has a good bit of support and no objections since it was re-filed (I came the closest to objecting, but I've pretty much gotten over it).

In order to move forward with $data, we need Relative JSON Pointers, which are also referenced in several other issues (#52, #108, probably others). But $data is the most broadly accepted use.

What is the right way to revive this I-D ( https://tools.ietf.org/html/draft-luff-relative-json-pointer-00 )? @geraintluff is there a git repo for it somewhere?

[handrews]

Adding some stuff from an IRC session with @awwright yesterday (these are my interpretations, not necessarily endorsed by @awwright ):

Relative JSON Pointers could also be defined within JSON Schema

• There is some doubt as to its viability or ability to get adopted by an IETF working group on its own.
• Could be split back out later if viability becomes our clear.

Relative JSON Pointers are NOT for use with URI resolution

• In particular, Relative JSON Pointers are not URI references of any sort
• The JSON Pointer RFC 6901 includes URI fragments as a use for absolute JSON Pointers, but allows for other uses
• Relative JSON Pointers are applied to document-local JSON Pointers to produce new document-local JSON Pointers
• The resulting absolute pointer could then be used as a fragment, but the application of the relative pointer MUST take place outside of the URI reference resolution process from RFC 3986

I think some concerns over relative pointer have been around trying to treat them as some sort of relative fragment resolution protocol folded in with RFC 3986 rules. We should be clear that they are a completely distinct process.

[handrews]

@awwright if we were to define Relative JSON Pointers within JSON Schema, where would that go? We have both validation and hyper-schema proposals that rely on it, so would it be part of the core spec?

[awwright]

Seems like Core: Core defines the application/schema+json media type,
including all the features that implementations must support no matter what
vocabulary is being used.

On Nov 14, 2016 16:10, "Henry Andrews" notifications@github.com wrote:

@awwright https://github.com/awwright if we were to define Relative
JSON Pointers within JSON Schema, where would that go? We have both
validation and hyper-schema proposals that rely on it, so would it be part
of the core spec?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#126 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAatDdfMGYYCHazIpW0d6rfnCyiq7Hfbks5q-OpCgaJpZM4Ko3s3
.

[HotelDon]

There was an issue on the old repo about adding the ability to access object keys with relative json pointers (in the current version of relative json pointers, you can access the entire object, or the value contained at a certain key, but you're out of luck if you want just the keys). Whether we resurrect the old proposal, or just bake it into JSON schema, could we use that as an opportunity to add this feature? I'll admit that my particular use case for that feature is a bit strange, but I'm not the only person asking it.

[handrews]

Actually I was working on a trial-balloon PR to put it into core and looked at that old issue yesterday, and thought it made sense. I was going to include that and the array-sibling proposal as well. Although I still need to convince @awwright of the indispensability of relative pointers- we'll see how that goes :-)

[handrews]

This is blocked on the question of whether we even need relative JSON Pointers.

[HotelDon]

Is that in relation to the limbo that $data is in, or just judging relative pointers on their own merits?

[handrews]

@HotelDon related but not exclusive. There are several proposals that would require relative pointers, but also some ideas for doing at least some of those in other ways (don't ask me, not my ideas). At least one feature using relative pointers needs to gain acceptance before we can consider whether or not to resurrect it as a separate draft.

I'm avoiding pushing any of this until after Draft 6 is published. We're having a hard enough time focusing on the few remaining Draft 6 tasks as it is, even though there is very little left to do.

[epoberezkin]

@handrews yep, let's focus on 6.

[handrews]

@HotelDon and anyone else interested, there are two PRs for draft-07 that would require Relative JSON Pointers: #381 and #382. Neither adds features to Relative JSON Pointer, but if those PRs are accepted and we either revive the Relative JSON Pointer RFC or fold it into core, then the property names request can get some discussion in the next draft.

Those PRs reference the expired draft, but that was just to keep the PR size down. If either is accepted, then I'll do a PR for pulling the external spec into core.