YAML 1.2 support #20

SoniEx2 · 2016-10-08T21:07:06Z

Hi, I'd like YAML 1.2 support.

ingydotnet · 2016-10-10T20:37:36Z

The next step is to make a list of the changes needed to get there.

SoniEx2 · 2016-10-11T17:41:29Z

Is "start from scratch" a valid change?

sigmavirus24 · 2016-10-11T18:23:36Z

@SoniEx2 you mean, rm libyaml and start a new?

SoniEx2 · 2016-10-11T18:24:28Z

@sigmavirus24 Yes.

sigmavirus24 · 2016-10-11T19:40:48Z

That may be a valid change, but it's not a change that would happen without good reasoning. What reasoning do you have for wanting to start from scratch? Further, if that's your desired first step, why not write a different implementation from scratch and forget this project? That's the easiest way to start from scratch.

SoniEx2 · 2016-10-11T19:52:26Z

Refactoring is good. rm -rf is only the most extreme form of it.

polyzen · 2017-03-26T17:46:50Z

The next step is to make a list of the changes needed to get there.

https://yaml.readthedocs.io/en/latest/pyyaml.html#defaulting-to-yaml-1-2-support

Promising oss-fuzz in /src/oss-fuzz creates lots of confusion about where files come from. Let's make everything explicit. Fixes yaml#20

EvanCarroll · 2018-06-25T18:22:58Z

Just for reference from the 1.2 spec

The primary objective of this revision is to bring YAML into compliance with JSON as an official subset. YAML 1.2 is compatible with 1.1 for most practical applications - this is a minor revision. An expected source of incompatibility with prior versions of YAML, especially the syck implementation, is the change in implicit typing rules. We have removed unique implicit typing rules and have updated these rules to align them with JSON's productions. In this version of YAML, boolean values may be serialized as “true” or “false”; the empty scalar as “null”. Unquoted numeric values are a superset of JSON's numeric production. Other changes in the specification were the removal of the Unicode line breaks and production bug fixes. We also define 3 built-in implicit typing rule sets: untyped, strict JSON, and a more flexible YAML rule set that extends JSON typing.

spgarbet · 2020-02-03T12:37:34Z

Looks like most of the changes are dropped features. I would posit that most of the upgrade would be just dropping some tokens from the parse tree. Or course, I've been bitten by things that seem so simple in the past. There is an additional escape added. This upgrade has been lingering for several years and there's even a stale branch that claimed to be the 1.2 upgrade.

If someone submitted a pull request, with tests to upgrade to 1.2 would this push this along?

perlpunk · 2020-02-03T19:16:36Z

I think we should make a list of things that need to be changed.
I started listing the changes between 1.1 and 1.2 a while ago:
https://github.com/yaml/yaml/wiki/YAML-1.2-Changelog

1 is not relevant, 3 and 4 are done.
I think 2 could be complicated. But we could probably allow this for both versions
For 5 I made a PR to change the output accordingly: Always output document end before directive (YAML 1.2 compatibility) #160
For 6 we need to change behaviour depending on the YAML directive, so we don't break existing YAML.

There are probably more changes, but I think they are mostly removing ambiguity from the 1.1 spec.

Can you think of anything else I should add?

This will allow `%YAML 1.2` directives. See also #20 No changes are needed regarding tag directives. In YAML 1.2 tag directives are for the following document only. This is already implemented like that in libyaml. We would rather have to fix the code if we want to have the correct behaviour (global directives) in YAML 1.1. This would be a bit more complicated, as we would have to save the default version and the current version in the parser object. New passing parser tests: * 27NA: Spec Example 5.9. Directive Indicator * 6ZKB: Spec Example 9.6. Stream * 9DXL: Spec Example 9.6. Stream [1.3] * RTP8: Spec Example 9.2. Document Markers New failing error parser tests (before they were errors for the wrong reason): * EB22: Missing document-end marker before directive * RHX7: YAML directive without document end marker

perlpunk · 2020-03-30T16:48:43Z

Actually number 6 (Directives are not global anymore) is not implemented correctly in libyaml currently. Directives are not global.
That means we could actually support %YAML 1.2 simply by adding one condition to the relevant if statement.

Fixing global directives for 1.1 would also be possible, but the question is if we want this.

I created #172

This will simply allow `%YAML 1.2` directives additionally to `%YAML 1.1`. There is no change in behaviour. See also #20 No changes are needed regarding tag directives. In YAML 1.2 tag directives are for the following document only. This is already implemented like that in libyaml. We would rather have to fix the code if we want to have the correct behaviour (global directives) in YAML 1.1. This would be a bit more complicated, as we would have to save the default version and the current version in the parser object. New passing parser tests: * 27NA: Spec Example 5.9. Directive Indicator * 6ZKB: Spec Example 9.6. Stream * 9DXL: Spec Example 9.6. Stream [1.3] * RTP8: Spec Example 9.2. Document Markers New failing error parser tests (before they were errors for the wrong reason): * EB22: Missing document-end marker before directive * RHX7: YAML directive without document end marker

rriemann · 2020-10-13T17:43:07Z

#172 was merged. How far is now 1.2 support?

andry81 · 2020-10-23T18:46:35Z

May be it is not my business, but the idea "YAML is a superset of JSON" is a bad idea at very beginning.

andypost · 2021-03-24T21:08:59Z

As i see inital support for 1.2 already released as 0.2.3 (2020-04-11) but not clear what's left to do

spgarbet · 2023-05-29T15:09:42Z

How does one compile the library to get the closest 1.2 support? Are there any configure options?

perlpunk · 2023-05-29T15:29:15Z

See https://github.com/yaml/libyaml/wiki/YAML-1.2 for the status on YAML 1.2.
There are no configure options regarding that, it is already close to YAML 1.2 by default.

perlpunk · 2023-05-29T15:54:41Z

Note that there are other things where libyaml diverges from the spec, that don't have anything to do with the differences of 1.1 and 1.2.

I collected those cases for libyaml and pyyaml together here: https://github.com/yaml/pyyaml/wiki/Testsuite---Failing-cases

andry81 · 2023-05-29T16:13:44Z

edited by @perlpunk and split out to #269

perlpunk · 2023-05-29T17:24:05Z

@andry81 that has nothing to do with YAML 1.2 support, so it doesn't belong in this issue.

perlpunk · 2023-05-29T17:29:36Z

I recommend to try out libfyaml. It fully supports YAML 1.2. Depending on your use cases it might already have every functionality you need.

sigmavirus24 pushed a commit to sigmavirus24/libyaml that referenced this issue Apr 6, 2017

[infra] do not checkout oss-fuzz (yaml#23)

dae2012

Promising oss-fuzz in /src/oss-fuzz creates lots of confusion about where files come from. Let's make everything explicit. Fixes yaml#20

This was referenced May 10, 2018

Support configuration files with YAML directives or marker lines travis-ci/travis-ci#9600

Closed

Docs should specify Travis CI config's YAML conformance details travis-ci/docs-travis-ci-com#1831

Closed

rriemann mentioned this issue Oct 9, 2018

Regression: Could not parse YAML metadata jgm/pandoc#4959

Closed

lorenzwalthert mentioned this issue Jul 23, 2019

yaml 1.2 support vubiostat/r-yaml#76

Open

Scriptkiddi mentioned this issue Sep 8, 2019

yaml parser Netflix/dynomite#703

Open

perlpunk mentioned this issue Mar 30, 2020

Support %YAML 1.2 directives #172

Merged

favonia mentioned this issue Jun 22, 2020

Support YAML 1.2 avsm/ocaml-yaml#37

Merged

cderv mentioned this issue Nov 2, 2020

Stricter YAML parsing in Pandoc >= 2.2.2 generates Pandoc WARNINGs rstudio/rmarkdown#1474

Open

asciimike mentioned this issue Aug 3, 2021

schedule.time's data type interpretation may be confusing dependabot/dependabot-core#3615

Closed

Alessandro-Barbieri mentioned this issue Jan 29, 2022

system libyaml vubiostat/r-yaml#102

Closed

bd808 mentioned this issue Feb 27, 2022

YAML 1.2 php/pecl-file_formats-yaml#64

Open

vkleen mentioned this issue Apr 4, 2023

Exported YAML may be ambiguous tweag/nickel#1222

Open

perlpunk mentioned this issue May 29, 2023

Add support of blank lines and comments (re)format support, because people seems has been fighting with these issues for ages: #269

Open

emiltin mentioned this issue Jul 7, 2023

Fix broken YAML rsmp-nordic/rsmp_schema#74

Merged

vlazar mentioned this issue Jan 17, 2024

shards add/get crystal-lang/shards#144

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

YAML 1.2 support #20

YAML 1.2 support #20

SoniEx2 commented Oct 8, 2016

ingydotnet commented Oct 10, 2016

SoniEx2 commented Oct 11, 2016

sigmavirus24 commented Oct 11, 2016

SoniEx2 commented Oct 11, 2016

sigmavirus24 commented Oct 11, 2016

SoniEx2 commented Oct 11, 2016

polyzen commented Mar 26, 2017 •

edited

EvanCarroll commented Jun 25, 2018

spgarbet commented Feb 3, 2020

perlpunk commented Feb 3, 2020 •

edited

perlpunk commented Mar 30, 2020

rriemann commented Oct 13, 2020

andry81 commented Oct 23, 2020

andypost commented Mar 24, 2021

spgarbet commented May 29, 2023

perlpunk commented May 29, 2023 •

edited

perlpunk commented May 29, 2023

andry81 commented May 29, 2023 •

edited by perlpunk

perlpunk commented May 29, 2023

perlpunk commented May 29, 2023

YAML 1.2 support #20

YAML 1.2 support #20

Comments

SoniEx2 commented Oct 8, 2016

ingydotnet commented Oct 10, 2016

SoniEx2 commented Oct 11, 2016

sigmavirus24 commented Oct 11, 2016

SoniEx2 commented Oct 11, 2016

sigmavirus24 commented Oct 11, 2016

SoniEx2 commented Oct 11, 2016

polyzen commented Mar 26, 2017 • edited

EvanCarroll commented Jun 25, 2018

spgarbet commented Feb 3, 2020

perlpunk commented Feb 3, 2020 • edited

perlpunk commented Mar 30, 2020

rriemann commented Oct 13, 2020

andry81 commented Oct 23, 2020

andypost commented Mar 24, 2021

spgarbet commented May 29, 2023

perlpunk commented May 29, 2023 • edited

perlpunk commented May 29, 2023

andry81 commented May 29, 2023 • edited by perlpunk

perlpunk commented May 29, 2023

perlpunk commented May 29, 2023

polyzen commented Mar 26, 2017 •

edited

perlpunk commented Feb 3, 2020 •

edited

perlpunk commented May 29, 2023 •

edited

andry81 commented May 29, 2023 •

edited by perlpunk