Fragment identifier for yaml and +yaml

[ioggstream]

Question

Compile fragment identifier section

• for yaml
• for +yaml? See: #21. +yaml fragment identifier. #39

Can we pospone this?

[richsalz]

It seems strange to me that a media type would define a new "language" intrinsic.

[cjaccino]

I believe the registration should include the fragment identifier. +json does not identify one, which creates problems. It probably should have a registration update to address it.

Not registering fragment handling means that a reference to a YAML-borne schema cannot be referenced. The part beyond the # would be formally nonsensical (as it is today).

We can take some inspiration from the work on the same issue for JSON Schema. JSON Pointer tells us how to craft fragments. The same format applies to the semantic equivalent in YAML documents.

I'll put in a pull request.

[ioggstream]

@cjaccino we have splitted the two documents. I think that yaml fragment identifiers should probably be delegated to "structured" media types since there are multiple possibilities (eg. json-path, json pointers, ...)

WRT openapi+yaml for example, we can state that the fragment uses json pointers.

[ioggstream]

@eemeli Can you confirm that the YAML community agrees with the current statement wrt fragment identifiers?

[eemeli]

I'm pretty sure that fragment identifiers should not be defined for +yaml at least for now. As demonstrated e.g. by the work going on even in this repo, YAML is used to represent multiple different forms of structured data, some of which may at times be represented by other formats, such as JSON.

So while YAML 1.1 and 1.2 do explicitly support &anchors on nodes that would rather naturally work as fragment identifiers, there's somewhat significant risk that this would complicate usage with sub-formats that natively use different methods, such as JSON Pointers.

On the other hand, defining fragment identifiers for application/yaml to follow the YAML spec for referring to anchors would make sense.

[richsalz]

I'm pretty sure that fragment identifiers should not be defined for +yaml at least for now.

FWIW, I completely agree.

[ioggstream]

The choice to leave the fragment identifier of the structured syntax suffix to the media type is sensible: I will PR that.