4 ms·
Why did you: - introduce the least idiomatic form of YAML as "depending on preference" - add an optional preamble to the XML example - add comments when ther
by BoorishBears 3y ago
Why did you:
- introduce the least idiomatic form of YAML as "depending on preference"
- add an optional preamble to the XML example
- add comments when there were none, but also not to all of them
If you didn't artificially stretch the different examples to match, there'd be a much clearer difference between them all, especially considering the fact one of your three examples is a superset of the other.
The odd one out can't even capture an integer vs a string without a schema.
- kelnos 3y agoI was puzzled by the GP's choice to write the first YAML example in a completely unidiomatic way. But I think the point of adding comments was just to show that comments are possible in some formats, and not others. Omitting possible comments from the XML example might have just been a sign of fatigue over this topic ;) At any rate, I find the (idiomatic) YAML example to be -- by far -- the most readable of all, including the GGP's TOML example.
- munksbeer 3y ago[dead]
- jeroenhd 3y ago- To showcase to the many people who aah JSON is more legible that you can use YAML as "legible" JSON - Most XML files I encounter come in this format. You can skip the preamble but it wouldn't match my real life experience. - All readable config files I encounter have comments. I forgot to add comments to the XML representation, but I can't edit my comment anymore. I think everyone who ever encountered XML knows how to add comments, though. JSON simply doesn't support comments unless you use a niche JSON derivative. As for the string versus integer problem: you always need a schema, or you'll run into very funny problems down the line. None of these formats intrinsically know what keys refer to an object and what keys refer to a string, that's all based on your schema anyway.
- BoorishBears 3y agoJSON and YAML intrinsically define that. "10" is a string. 10 is a number. [10] is a single number in an array. {"number":10} is an object. You're conflating advice for databases with advice for data serialization formats: XML captures less information about the data it contains intrinsically. _ Also please don't use YAML as "JSON with comments", you're just asking to run into some obscure bug/corner case If you're willing to do weird things there's always JSON5