4 ms·
Cause it's very verbose. A lot more syntax to break. I personally think the best is one of the humanized json ones like https://maml.dev/ https://maml.dev/
by Bolwin 5mo ago
Cause it's very verbose. A lot more syntax to break.
I personally think the best is one of the humanized json ones like https://maml.dev/ https://maml.dev/
- ThunderSizzle 5mo agoIt wouldn't need to be if closing tags were allowed to be unnamed. For most cases, we can tell the closing tags easily enough for simpler files: <project>MAML</> <tags> <item>minimal</> <item>readable</> </> <!-- A simple nested object --> <spec> <version>1</> <author>Anton Medvedev</> </> <!-- Array of objects --> <examples> <item> <name>JSON</> <born>2001</> </> <item> <name>MAML</> <born>2025</> </> </> <notes> This is a multiline raw strings. Keeps formatting as-is. </>
- eviks 5mo agoThis is still noisy, wasting 3 symbols to end where an invisible line end would suffice
- ThunderSizzle 5mo agoFine. Then auto-closing tags? If you have a schema doc, you could do that. If you are writing free-form, then I'd definitely be complicated...? I still see that better than YAML's indentation problem. Relying solely on indentation is a nightmare.
- tremon 5mo agoBut if closing tags are allowed to be unnamed, you are still one misplaced </> away from unrecognizably maiming the entire hierarchical structure, just like one incorrect indent can do in YAML. Ultimately, what matters is the editing mode and not the data format. Good syntax highlighting and autocompletion goes a long way towards safely editing structured text, regardless of on-disk format.
- procaryote 5mo agoYou need to misplace a </> in a way that still produces a valid xml document. Just forgetting one or adding an extra one will throw an error.
- SoftTalker 5mo agoWatch out, next thing you know you'll have reinvented S-expressions. Which is really all we ever needed.