Enhance Reference Object verbiage to add clarity for $ref fragments

[frankkilcommins]

          > Section [Reference Object](https://github.com/OAI/sig-workflows/blob/main/versions/1.0.0.md#reference-object), field `$ref` says

This MUST be in the form of a URI.

Which is only half of the truth: the fragment part - if present - apparently MUST be in the form of a JSON Pointer URI Fragment Identifier Representation.

Otherwise how is an implementation supposed to interpret the fragment part?

@ralfhandl I'll look to update the media type registrations to specify JSON Pointer as the fragment identifier mechanism, and add some additional text also into the section to clarify

Originally posted by @frankkilcommins in #49 (comment)

[frankkilcommins]

See also:

• Launch Implementer Version of the Specification #49 (comment)
• Launch Implementer Version of the Specification #49 (comment)

[handrews]

@frankkilcommins RFC 6901 specifically states that JSON Pointers are not the fragment syntax for application/json, and RFC 8259 does not define any fragment syntax.

This, of course, has not stopped people from treating JSON Pointer as a universal JSON fragment syntax, because in practical terms one is needed and that's the one that makes sense. I've never figured out how to make this RFC-compliant, except perhaps by saying that implementation should "cast" application/json to application/whatever+json and then apply the fragment. I've never tried to get that through a formal standards body, though.

But technically you MUST use a +json media type that defines that fragment syntax.

The proposed YAML RFC, which is nearing publicaton as a numbered RFC, does define JSON Pointer as a fragment syntax for application/yaml, although it is not automatic for +yaml media types and must be defined in each one.