Unclear status of language-independent YAML tags
The specification https://yaml.org/spec/1.2/spec.html refers to some tags defined in http://yaml.org/type/
In 2.4. Tags there are links and examples for tags: https://yaml.org/type/binary.html https://yaml.org/type/omap.html https://yaml.org/type/set.html
In 10.4 The tag repository is intentionally left out of the scope of this specification. This allows it to evolve to better support YAML applications.
In https://github.com/yaml/yaml/wiki/YAML-1.2-Changelog there is a link in section other: TODO Include missing things from https://eemeli.org/yaml/#version-differences
The !!pairs, !!omap, !!set, !!timestamp and !!binary types have been dropped. The merge << and value = special mapping keys have been removed
I understand that the tags above are not a part of the core schema, but why are they in the specification?
In the test matrix ares examples for this types: https://matrix.yaml.io/sheet/valid.html#77H8 https://matrix.yaml.io/sheet/valid.html#2XXW https://matrix.yaml.io/sheet/valid.html#J7PZ
Regarding the test suite/test matrix: Indeed I would like to remove those tags from the tests.
As a naive yaml user, should I replace the << key? (and with what?)
Until now I thought it was perfectly fine, because it is suggested in the GitLab docs and in articles on docker-compose; even recent ones. Oh and the docs
Reading, that support for it was actually dropped in spec v1.2 got me quite confused. I guess if I keep using <<, I cannot rely on yaml tooling to support it. Shouldn’t such information be documented more prominently?
As the merge key << is the most used tag from the 1.1 tag repository, I personally would recommend to YAML library authors to implement it even for YAML 1.2, but make it an optional feature.
We are currently working on a new revision of the spec where typos are fixed and some paragraphs are clarified.
Unfortunately because of the history of YAML versions and the spec many tools out there using YAML do not specify exactly what version and features they support.
For the next YAML version, we are trying to come up with a merge feature that is easier to implement, as the merge key is difficult to implement in a generic way.
Optionally extensions undermine the interoperability.
we are trying to come up with a merge feature that is easier to implement
<< is everywhere :) it would be great to have it without changing all existing files :P
<<is everywhere :) it would be great to have it without changing all existing files :P
agreed. while << is not officially in YAML 1.2, library authors can choose to implement this tag optionally, so tool authors can turn this feature on if they want.
@perlpunk I found that here the idea is
What we are hoping to do in YAML 1.3 and beyond, is define a standard library of useful data functions. We are also working on ways to make the tagging implicit so you don't need to use explicit !function tags all over the place. Hopefully there will be very few changes to the YAML syntax proper.
The outlook is great: is there some way to help?