YAMLGenerator: String unnecessarily quoted with MINIMIZE_QUOTES enabled

[bjpe]

Hi, moving from Jackson 2.10.3 to 2.11.3 we discovered that the YAMLGenerator now has a different behaviour when serializing strings that contain special charaters like {, }, [, ], ,. I suspect that this is due to https://github.com/FasterXML/jackson-dataformats-text/issues/180. This issue references the YAML spec (https://yaml.org/spec/1.2/spec.html#id2788859), which says

In addition, inside flow collections, or when used as implicit keys, plain scalars must not contain the “[”, “]”, “{”, “}” and “,” characters. These characters would cause ambiguity with flow collection structures.

However, the spec says that quoting of strings containing the above mentioned characters is only necessary in flow collections, but not outside.

Are there flags controlling the output of collections as flow collections vs block collections that could additionally be considered? At least, we output YAML in block style, and therefore would expect no quoting for string containing above characters.

A more elaborated solution might also consider the local context of a string value (in flow collection/in block collection/outside collection).

Our example file reads

TranslatorSpringTest:
  namedParameters: Test with parameter 0 = "{{param0}}" and parameter 1 = "{{param1}}".

and could be read and output as is with Jackson 2.10.3, but got converted to

TranslatorSpringTest:
  namedParameters: "Test with parameter 0 = \"{{param0}}\" and parameter 1 = \"{{param1}}\"."

with Jackson 2.11.3.

[cowtowncoder]

All low-level formatting details are handled by SnakeYAML (for 2.x, and snakeyaml-engine, its sequel for 3.0). YAMLGenerator.Feature has some options to change settings passed to SnakeYAML. So, changes are possible if they are supported by SnakeYAML and can then be ideally expressed as simple on/off options; or, if someone has more time and interest, using some more versatile settings.

However I'd prefer not want to expose specific SnakeYAML configuration options partly as 2.x/3.x will use different backends.

[cowtowncoder]

Another possibility (for which PRs would be accepted) would be pluggable handlers that could indicate if certain output mode was to be forced. That could be implemented in a way to prevent close-coupling, if suitable response values could be enumerated.