Fragments for schema+json media type: Need to add to IANA Considerations

[handrews]

Currently the section on "id" (or "$id" if the recent PR goes through) shows the keyword being used to define simple one-word fragment identifiers such as {"id": "#bar"}, while also showing the use of fragments with JSON Pointer such as "#/definitions/B".

What are the official rules for fragments for the application/schema+json media type? Do we want to standardize on JSON Pointers? Or do we support both of this by saying that if the fragment begins with a "/" then it should be interpreted as a JSON Pointer, but otherwise it should be looked up as an "id"? Defining an "id" that appears to be a JSON Pointer but does not point to the current schema would either have an undefined effect or produce an error, presumably.

@awwright I know we were talking about fragments for the media type but I don't recall exactly what, if anything, we decided to do. I just remember being confused about whether JSON Pointers were generally the fragment type for application/json (for everyone else: no, they aren't, the JSON Pointer specification says so directly).

[handrews]

Reading up on http://www.w3.org/TR/fragid-best-practices/ and looking at how application/xml and application/*+xml fragments are defined in https://tools.ietf.org/html/rfc7303 it seems clear that having both of these fragment identifier styles should be just fine (although I still need to do a bit more reading).

Assuming I don't find anything to the contrary, I will write up a PR adding a formal fragment identifier specification for application/schema+json.

[awwright]

It's something we'll have to build out in the IANA Considerations section.

In the absence of a section describing fragment interpretation for application/schema+json, implementations should be reading the fragment as a JSON Pointer.

[handrews]

Based on the best practices doc and what I see in the XML RFC and others, it shouldn't be too hard to write this up so I'll give it a shot. We do not need to define any new fragid structures as we are just using plain name fragids in a way that is completely consistent with their use elsewhere, and we're using JSON Pointer which is already a standard which addresses its own use as a fragid structure.

[handrews]

Addressed by PR #245

[handrews]

PR #245 merged. While there may be more details to address in the IANA registration, this gets us where we need to be for now.