51–60 of 173 posts
Earlier quoted context omitted.
I use it liberally, but the only thing that I find wrong with json is the [\u2028\u2029] issue: {"The invisible character":"really messes with javascript "} Copy the text and paste it in console.
Nitpick: that's an issue with JavaScript, not JSON.
Earlier quoted context omitted.
In the authors own words[1]: { 'because': { '80': 'percent' }, {'of': 'JSON', 'is': 'brackets' } } [1] https://github.com/mojombo/toml/issues/2#issuecomment-140029...
That's actually not valid JSON -- should use double quotes { "because": { "80": "percent" }, {"of": "JSON", "is": "brackets" } }
{ "because": [{ "80": "percent" }, {"of": "JSON", "is": "brackets" }] }
Would this be considered legal? [ [1,2], ["a", "b"] ]
It seems to me that YAML does this better already (with parsers which are already high-quality). If we want simplicity, then why not make sure it is a subset of YAML?
Earlier quoted context omitted.
That's actually not valid JSON -- should use double quotes { "because": { "80": "percent" }, {"of": "JSON", "is": "brackets" } }
That's not valid JSON either! (The second value has no key). Needs to be: { "because": [{ "80": "percent" }, {"of": "JSON", "is": "brackets" }] }
Would this be considered legal? [ [1,2], ["a", "b"] ]
This has now been clarified - it is legal
I note that, like many erstwhile specs, TOML does not document the escape sequences accepted in strings. Nor does it exhaustively specify integer formats and float formats - rather ironic for a spec that advertises "TOML is designed to be unambiguous and as simple as possible." The limitation on array types seemed fairly arbitrary at first glance, but after thinking it over I realized it aided compatibility with lang…
Don't you mean languages that only support homogeneous arrays (or languages that do not support non-homogeneous)?
As the spec says that the array elements must all be of the same type, thus homogeneous.
If I a mistaken, can you please explain why?