Even if you have a YAML 1.2 parser, here's another one:
In [1]: v = "\N{PILE OF POO}"
In [2]: yaml.load(json.dumps(v), yaml.SafeLoader) == v
Out[2]: False
The specification is woefully underspecified with regards to Unicode escapes. E.g., it uses "Unicode characters" practically throughout, a construct that doesn't exist in Unicode & (AFAICT) is not defined by YAML. A reasonable interpretation of that leads us to \uabcd
(which the spec says is "Escaped 16-bit Unicode character.") …decoding to the USV with value 0xabcd. But that's not compatible with JSON.(PyYAML is not the only library with that reading of the spec, either. Rust's will outright error on the input here, as its `str` type is equivalent to [USV], whereas Python's `str` is not. (The value Python decodes in the example above is a representable but illegal value.))
I wonder how widespread YAML 1.1 is.
If you assume that YAML 1.2 is the default, you don't need that nasty %YAML header.
This doesn't translate to arbitrary, open environments, but you can make that choice in closed environments.
While JSON numbers are grammatically simple, they're almost always distinct from how you'd implement numbers in any language that has JSON parsers, syntactically, exactness and precision-wise.
So while YAML is a lot more complex, you always need to limit yourself from what kinds of numbers you actually try to express in JSON. This is especially true for scientific numbers, big numbers, and numbers exact down to many digits.
> 1e2 is a valid JSON number, but YAML 1.1 requires it to be written as 1.0e+2
Then a program can be made that writes it as "1.0e+2", which is also valid in JSON as well as YAML, regardless of what the reader expects. (However, some formats will not need numbers that will need the scientific notation anyways.)
It does not help if you are trying to use a YAML parser to parse a JSON file, but at least, it avoids a different problem.
If you are making your own which does not need to work with an existing format, then you do not necessarily need to use YAML nor JSON; you can choose the appropriate format for it. You can consider what numbers and what character sets you intend to use, and if you will use binary data, etc. If you like the structured data but do not need a text format than DER is another way.
If you really must embed JSON in YAML, just encode it to base64.
YAML.load '[FI,NO,SE]'
=> ["FI", false, "SE"]
Ah yes, I remember that. %YAML 1.2
Absolutely no truck with this either. If you want another whitespace obsessed bug farm, you can give it a new name.Stay with XML. It's fine. I wrote a bunch earlier this evening, even though you're not really meant to edit it by hand, and that was fine too. Emacs totally understands what XML is.
> Regardless of whether YAML 1.2 has been (or will be) widely adopted, it does not help those who want to parse a JSON document with a YAML parser.
Who are these hypothetical lunatics?