D-Yaml chokes on tabs when in flow style

[schveiguy]

The following should be a valid Yaml document (and valid JSON).

{
"root": {
	"key": "value"
    }
}

However, D Yaml chokes on it because of the leading tab before "key". The 1.1 spec states that in flow style (using braces and brackets to denote maps and arrays), leading whitespace is NOT considered indentation.

This feature is critical for DYaml to be considered a "superset" of JSON.

PyYaml, upon which this is based, also chokes on this.

[Herringway]

checked with other yaml devs and confirmed that this is valid YAML. I'm not sure when I'll be able to get around to implementing this, though...

[schveiguy]

Just to give a bit of background, we are discussing possibly moving to YAML for dub configuration instead of (or in addition to) json. I wrote a small test program to go through all projects on code.dlang.org to find out how well dyaml would parse the various dub.json files. A surprising amount have leading tabs (over 50% of all dub.json files in all versions of projects). I was hoping to just include one parser for the config files, but dyaml doesn't support this. So even if we used YAML as a new format, we would have to keep including the json parser (the one inside dub appears to be a custom version of a json parser).

[Herringway]

unfortunately, YAML 1.1 doesn't fully support JSON. it should be compatible in most simple cases already, but YAML 1.2 is the one that almost guarantees compatibility (duplicate keys are unsupported, which I don't think are usable in dub.json files anyway)

I'm still working out what needs to be done to fully support 1.2, but I'm just one person with a whole lot of other interesting projects on the table.

[schveiguy]

Believe it or not, duplicate keys were present in a few projects (and DYaml choked on those too). The end result I think is that the second one wins, but it was limited to one or two projects. We are probably OK with that level of breakage.

Someone tested DYAML with some of the "incompatibilities" (spaces required after commas and colons) and said it worked. Now looking back at it, I wonder if it parsed as expected, or if it parsed into something not expected. I didn't actually test if the parsed json matched the parsed yaml, only that I got a result and not an exception.

[Herringway]

there's a tojson subpackage that translates stdin from yaml to json. it might be useful for double checking.