Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a relative-json-pointer format #417

Merged
merged 2 commits into from
Oct 8, 2017

Conversation

handrews
Copy link
Contributor

We have generally included formats necessary for describing
JSON Schema vocabularies, and JSON Hyper-Schema now uses
Relative JSON Pointers.

Also use it in the links meta-schema (as a separate commit).

I did not bother to file an issue for this as it seems pretty straightforward
and in line with existing precedent. Also, it was faster to write a PR
so even if rejected this was less work :-)

We have generally included formats necessary for describing
JSON Schema vocabularies, and JSON Hyper-Schema now uses
Relative JSON Pointers.
This is more clear than the regular expression, and more accurate.
@handrews handrews added this to the draft-07 (wright-*-02) milestone Sep 23, 2017
@awwright
Copy link
Member

We might have to pull in the text of "draft-luff-relative-json-pointer", or figure out how to advance that draft.

And in my opinion, I'm still not really sure if relative pointers are actually ever necessary.

@handrews
Copy link
Contributor Author

And in my opinion, I'm still not really sure if relative pointers are actually ever necessary.

How would you handle #385 and #386 without them? And without making up some other arbitrary new format, because there is no reason to introduce an entirely different syntax when there is one that is compatible with the syntax (JSON Pointer) that we already use extensively.

@handrews
Copy link
Contributor Author

@awwright 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.

@handrews
Copy link
Contributor Author

@awwright and I chatted off-github and (I think) agreed that anchorPointer and hrefPointers/templatePointers are sufficient justification for this, as neither of us have an alternative proposal for implementing them. @awwright would you be OK with signing off on this now? If we end up finding a different solution and dropping Relative JSON Pointer from Hyper-Schema, I'd assume we could drop this as well.

@handrews
Copy link
Contributor Author

handrews commented Oct 4, 2017

@awwright this is coming up on 2 weeks in a couple of days. Given our discussion offlist I'm going to assume you've dropped your objections to this unless you comment otherwise.

@handrews handrews merged commit 6624c1a into json-schema-org:master Oct 8, 2017
@handrews handrews deleted the relptr-fmt branch October 8, 2017 02:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants