31–40 of 173 posts
Earlier quoted context omitted.
Unrelated: why spaces inside the parentheses? It’s not the first time I see this, but this is incorrect!
JSON doesn't have parentheses, but it does have braces and brackets. The JSON spec specifically allows spaces. > Insignificant whitespace is allowed before or after any token.
Earlier quoted context omitted.
Yaml is the worst. Humans and LLMs alike get it wrong. I used to laugh at XML but Yaml made me look at XML wistfully. Yaml - just say Norway
The Norway issue is a bit blown out of proportion seeing as the country should really be a string `"no"` rather than the `no` value
Stuff that would have been structurally impossible in XML will happen in yaml. And I don't even like XML.
Nice. And BTW, thanks for supporting comments - the reason given for keeping comments out of standard Json is silly ( "they would be used for parsing directives" ).
It's a pretty sensible policy, really. Corollary to Hyrum's Law - do not permit your API to have any behaviours, useful or otherwise, which someone might depend on but which aren't part of your design goals. For programmers in particular, who are sodding munchkins and cannot be trusted not to do something clever but unintended just because it solves a problem for them, that means aggressively hamstringing everything.…
It looks like there are two maintained implementations of this at the moment - one in C# https://github.com/j-brooke/FracturedJson/wiki/.NET-Library and another in TypeScript/JavaScript https://github.com/j-brooke/FracturedJsonJs . They each have their own test suite. There's an older pure Python version but it's no longer maintained - the author of that recently replaced it with a Python library wrapping the C# code…
Earlier quoted context omitted.
We stopped having this problem over ten years ago when spec 1.1 was implemented. Why are people still harking on about it?
Now add brackets and end-tags, I'll reconsider. ;)
Roles: [editor, product_manager]
something:
setting: true
---
another:
thing: falseWhile I wish JSON formally supported comments, it seems more sensible (compatible) to just nest them inside of a keyed list or object as strings. { foo: "bar", ans: 42, comments: { ans: "Douglas Adams" } }
That way, the original JSON file stays clean and isn’t polluted with extra data.
Earlier quoted context omitted.
This is a reference to YAML parsing the two letter ISO country code for Norway: country: no As equivalent to a boolean falsy value: country: false It is a relatively common source of problems. One solution is to escape the value: country: “no” More context: https://www.bram.us/2022/01/11/yaml-the-norway-problem/
We stopped having this problem over ten years ago when spec 1.1 was implemented. Why are people still harking on about it?
I know that LLMs are very familiar with JSON, and choosing uncommon schemas just to reduce tokens hurts semantic performance. But a schema that is sufficiently JSON-like probably won't disrupt model path/patterns that much and prevent unintended bias.