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" [email protected] 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.

[handrews]

@geraintluff any objection to me taking your draft and re-submitting it to make it current again? Or do you think we should pull it directly into the JSON Schema specifications?

[handrews]

I emailed Geraint and he's fine with me/us re-submitting the I-D or pulling it in. His thoughts:

I had originally separated it out into its own document (as opposed to adding it to the JSON Schema draft) because I thought it worked well as a standalone spec - I was already using the syntax in some of my own unrelated code because I felt it was a natural extension of JSON Pointer. It was also a clearer and stronger way to explain all the details than a forum post or GitHub comment.

If JSON Schema references it then it's a dependency for standardisation, but since the Relative JSON Pointer spec is much smaller I imagine it could be reviewed and finalised faster, and leave the JSON Schema spec slightly simpler. So, I don't know which will get you to your goal faster - from a practical perspective I don't mind, because if it ends up folded into the JSON Schema spec it can still be cited by referencing a particular subsection.

I'm inclined to just rebuild the XML (Geraint could not find the sources) and re-submit it as a separate I-D myself leaving Geraint as the author and putting myself as editor on the grounds of doing the mechanics to get it going again (he and I discussed this in email). It hardly matters at this stage, and that's just a lot easier than figuring out the best way to merge it into JSON Schema.

While this isn't technically part of the draft-07 work, it is a dependency so I'm putting it in the milestone.

[handrews]

For anyone who has not followed the Hyper-Schema work, we've made the decision (after some off-GitHub discussion with @awwright) to revive this on the grounds of the anchorPointer and hrefPointers (which may become templatePointers) keywords for JSON Hyper-Schema. See #381, #382, #385, #386, and #417.

I'm just going to add the XML alongside our existing set of I-Ds unless someone has another suggestion.

[handrews]

This was merged, as was an update with changelogs and acknowledgements.