v3.2: Only use YAML for examples#4577
Conversation
We still use JSON for example payloads, and there is one example in Appendix F that discusses retrieving OADs by content type, so those continue to show JSON. Also standardize on lowercase language names for fenced code blocks, as that was more common (I think the uppercase ones were mostly added by me).
ralfhandl
left a comment
ralfhandl
left a comment
There was a problem hiding this comment.
we don't need both JSON and YAML examples
Correct, the same example in both JSON and YAML is redundant.
However I'd like to have some examples in JSON only, and some in YAML only, to avoid the impression that YAML is preferred or even mandatory.
|
@ralfhandl that's not what I recall being discussed, and it would be work that I don't really have bandwidth for to figure out which should be which and go back and change it. I also just disagree in general- people can figure out JSON from YAML and JSON wastes space. Also, Appendix F does show both and discusses retrieval strategies for supporting both media types. |
|
@ralfhandl if later on you want to switch some to JSON to balance it out, I definitely will not object. But I appreciate being able to reduce the duplication for now as a first step. Thank you for the approval! 🙏 |
3 participants
IIRC, we discussed a while ago that we don't need both JSON and YAML examples. And there are many examples now that are only shown in YAML. This standardizes on YAML for all OAD examples. In addition to cutting down on the ever-growing length of the spec, I find this more readable when there are a bunch of examples in a row, as you're not constantly skipping over duplicates.
We still use JSON for example payloads, and there is one example in Appendix F that discusses retrieving OADs by content type, so those continue to show JSON.
Also standardize on lowercase language names for fenced code blocks, as that was more common (I think the uppercase ones were mostly added by me).