8 ms·
In XML's defense, the attribute-vs-child-element choice is always obvious and straightforward when you're using it as a markup language. It's only when you use
by mumblemumble 3y ago
In XML's defense, the attribute-vs-child-element choice is always obvious and straightforward when you're using it as a markup language. It's only when you use it as object notation that it becomes wonky, because there the choice simply doesn't map to any straightforward characteristic of the problem domain. I'm not sure I want to hold XML responsible for not being good at being something it isn't.
And, on that note, I think that if I could pick as single thing that irritates me the most about YAML, it's that it isn't actually a ML.
- unscaled 3y agoI'm not criticizing having attributes-vs-child-elements. The problem with XML is not that it exists or that it is a particularly badly designed markup language. The problem is that XML is ill-suited for configuration files.
- baq 3y agoYeah JSX and especially TSX would be quite nice. YAML though can’t die soon enough.
- moritzwarhier 3y agoYou think that JSX would be suited for configuration files? Why? I don't understand your comment.
- baq 3y agoBecause people reinvent half of it, different half every time in each project, and call it 'configuration' which somehow gives them licencia poetica for whatever crazy dung they come up with. Compare ansible vs helm vs github actions vs literally anything with nontrivial config. Note that if you asked me for real, I'd be a dhall proponent, but most normal people look at me funny the first time they hear it and then the second time they see the syntax.
- moritzwarhier 3y agodhall looks nice actually! Thanks for elaborating :)
- wokkel 3y agoWhy? I can store it in version control. I can validate if the file has syntax errors or schema errors etc. etc. With a proper platform it's easy to generate or parse. It allows for both hierarchical structures (looking at you .ini). The only downside might be that you need a larger library to parse it. But i probably encounter xml somewhere along the line anyway due to interactions with a 3rd party system, so that point is moot.
- dvdkon 3y agoYou have a low bar for config languages. I'd also like one to not be overly verbose, not be clearly intended for markup instead of object storage and not have security issues until you configure the parser just right (though that's often not an issue with configs). XML fails all of these, and YAML isn't much better. If we're limiting ourselves to just JSON, INI, XML and YAML as potential choices, I get why people cling onto one of these suboptimal choices and then fiercely defend it, but there are other options. There's libconfig, JSON5, Dhall, various interpreted languages... Sadly these alternatives are far from mainstream and have no support in standard libraries, so I think most developers will continue to pick whichever common option's issues they can deal with.
- PH95VuimJjqBqy 3y agoI'd like my config files to have two words in it "do it" and for it to just know what I want. But at the end of the day that's not possible because reality intrudes. You give up a lot for that lack of verbosity, not everyone will agree that it's a worthy tradeoff.
- GoblinSlayer 3y agoIt's a noble goal to want a simple configuration format, toml is far from the simplest, line separated options format is simpler. The fact that it needs a parser indicates that it creates a bigger parsing problem than necessary.
- dragonwriter 3y ago> And, on that note, I think that if I could pick as single thing that irritates me the most about YAML, it's that it isn't actually a ML. “YAML ain't markup language” is kinda the whole point.
- LukeShu 3y agoFor a full year it stood for "Yet Another Markup Language". First draft: https://yaml.org/spec/history/2001-03-30.html https://yaml.org/spec/history/2001-03-30.html Last draft calling it that: https://yaml.org/spec/history/2001-12-10.html https://yaml.org/spec/history/2001-12-10.html First draft with the new acronym: https://yaml.org/spec/history/2002-04-07.html https://yaml.org/spec/history/2002-04-07.html
- xorcist 3y agoIt's also funny that the file extension YML is the successor of XML, so the rest is probably a backronym from that.
- thaumasiotes 3y agoWouldn't the successor of XML be XMM?
- mumblemumble 3y agoNext you'll be telling me Beyonce's sisters should be named Beyoncd and Beyoncf instead of Aeyonce and Ceyonce.
- mvandermeulen 3y agoFeyonce can’t get anyone to believe she’s married and Vakira’s has astonishingly honest hips
- dragonwriter 3y agoJudging from BCPL, the successor should just be Y.
- throwawaymaths 3y agoThe thing is if you're using it as configuration language, object notation is correct, not markup.
- taeric 3y agoI'm curious why you think that is? Especially since you are likely to want to style the configuration for display to the user in many cases, having it be a document makes a lot of sense. That is, if the value is something you would expect to be able to show to a user, then it probably shouldn't be at attribute. If it is a value that changes how you would show it, then attribute makes a lot more sense. I also think a strong adherence to any preference between attribute and markup is a touch too dogmatic. The only real distinction at the language level is if you allow children, or not. If it can have children, it pretty much has to be a child and not an attribute.
- throwawaymaths 3y agoOk forget the difference between attribute and markup. What is the "right" way to think of this: <foo> <bar>1</bar> <bar>2</bar> <baz>3</baz> <baz>4</baz> </foo>
- taeric 3y agoWhy do you think there is a "right" way?