search

ietf-wg-httpapi / mediatypes

Other
5 stars 4 forks source link

Fragment identifier for yaml and +yaml #21

Closed ioggstream closed 2 years ago

ioggstream commented 2 years ago

Question

Compile fragment identifier section

Can we pospone this?

richsalz commented 2 years ago

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

cjaccino commented 2 years ago

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 commented 2 years ago

@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 commented 2 years ago

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

eemeli commented 2 years ago

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 commented 2 years ago

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

FWIW, I completely agree.

ioggstream commented 2 years ago

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