Comment by DougBTX | Hacker News Reader

Comment by DougBTX | Hacker News Reader

This article claims that 1e2 is interpreted as a string, while this other article on the front page[0] claims that 556474e378 is interpreted as a number. What's correct?

The YAML "Scalars" section[1] says:

> A few examples also use the int, float and null types from the JSON schema.

And includes these examples:

    canonical: 1.23015e+3
    exponential: 12.3015e+02

So, is the "+" required here or not? Is a YAML parser buggy if it doesn't parse all JSON numbers as numbers?

Edit: Ah, further on, it says:

    Canonical Form
    Either 0, .inf, -.inf, .nan or scientific notation matching the regular expression
    -? [1-9] ( \. [0-9]* [1-9] )? ( e [-+] [1-9] [0-9]* )?

The example 1e2 clearly matches this regex, so his YAML parser is broken.

Edit edit:

In YAML 1.1, there were separate definitions of float[2] and int[3] types, where only floats support "scientific" notation, and must have a ".", unlike JSON.

So this article is talking about YAML 1.1, while the other article is talking about YAML 1.2.

[0] https://news.ycombinator.com/item?id=41498264

[1] https://yaml.org/spec/1.2.2/#23-scalars

[2] https://yaml.org/type/float.html

[3] https://yaml.org/type/int.html

What's "correct" depends on whether your YAML parser defaults to YAML 1.1 or 1.2.

Most YAML parsers default to 1.1 for compatibility reasons, because if they default to 1.2 then existing YAML documents expecting 1.1 behavior will be parsed incorrectly.

YAML is a difficult language to parse if you care about getting the correct data.

Which only goes to prove that every replacement of XML eventually ran into the exactly same complexity issues they thought to solve in the first place. Another example of why "just use..." is a losing approach.

> The example 1e2 clearly matches this regex, so his YAML parser is broken.

1e2 does not match this regex. 1e+2 or 1e-2 would, though.

The "canonical" form indeed requires an exponent sign, but the tag resolution process in YAML 1.2 (section 10.2.2) does allow its omission. That said however, the equivalent specification in YAML 1.1 [1] does require an exponent sign at any case! It should be no surprise that YAML 1.1 isn't a superset of any version of JSON, but I don't know whether this is intentional or simply an oversight.

[1] https://yaml.org/type/float.html

YAML 1.2.2 still isn't a superset of JSON, because it requires all keys to be unique:

> The content of a mapping node is an unordered set of key/value node pairs, with the restriction that each of the keys is unique

While JSON doesn't prevent duplicate keys per se, it doesn't fully specify its semantics anyway and only states that duplicate keys are less "interoperable". And there is an explicit profile of JSON with this requirement (I-JSON [1]), so YAML 1.2.2 can be said to be a superset of some version of JSON.

[1] https://datatracker.ietf.org/doc/html/rfc7493

"X is a superset of some subset of Y" is a weak statement.

This is not about semantics, it's about grammar. While it's fair to say that JSON "usually" is valid YAML, it's still good to be strict about it, because the existence of a single counterexample can be used maliciously.

Agreed, though it is more like "X is a superset of some common but not de jure interpretation of Y". The real culprit is the ambiguity of Y...

A JSON implementation that rejects non-unique keys is a valid JSON implementation, so a valid YAML 1.2 implementation is still a valid JSON implementation.

Some things in the world of JSON depend on order, too. There is a Microsoft way of indicating the type of an object using a key that must be first in the JSON syntax.

Same situation as above - a JSON parser that ignores order is a valid JSON implementation.

And such a parser could work with that convention. However, if its complementary formatter printed the objects such that that type field doesn't appear first, it wouldn't be correctly implementing the specification.

> So this article is talking about YAML 1.1, while the other article is talking about YAML 1.2.

Precisely. The article is really noticing quirks and limitations libyaml, the library doing the heavy lifting behind PyYAML, not YAML-the-spec proper.

Granted, in practice, library limitations are probably what you want to know about. AFAIK, libfyaml[0] (not libyaml) is the most spec-compliant library around. It's a shame more downstream languages aren't using it.

[0]:https://github.com/pantoniou/libfyaml

No, the YAML parser is a valid YAML 1.1 parser, where this behaviour is totally correct and in spec.

Reply on news.ycombinator.com