Especially editor integration works great as opposed to YAML which is so ambiguous that it IntelliJ IDEA constantly breaks indentation during copy and paste.
I lost you there. Not that I'm criticizing you since I've gone the same route and built a complex UI tool to manage said config (complete with XSD schema validation and config schema migration using XSLT for version upgrades).
But now I realize that modern developers don't want a GUI to manage their config. We want to store it git, review changes and perhaps even write our own automation and templating around it.
YAML is certainly a flawed format for most of these purposes, but so is XML. It is unnecessarily verbose and it carries a lot of complexity which was designed for a highly-extensible generic document format, but not for configuration files. XSD, Namespaces, Entities, Embedded DTD, CDATA blocks... You can't just ignore all of these, and there are very few parsers out there which work on a well-defined subset of XML. And even there, the whole attribute-vs-child-element choice is a giant distraction and constant source for unnecessary bikeshedding.
YAML has serious ambiguity issues, but there are better alternatives that have great library support like TOML. We don't have to go back to the excesses of the early 2000s and use XML as a configuration format.
XML is just to verbose, making it harder to parse in my brain.
YAML is whitespace sensitive which I hate in general.
I think at some point 24 out of 28 Gradle projects I had access to at a certain customer had variations in either kotlin/Groovy style or the way they did or didn't use variables, how they did or didn't do loops or maps and what not.
With Maven you (or someone who know Maven) can immediately look at a rather small, very standardized file and start making educated guesses and so can an IDE.
With Gradle you sometimes have to run it to actually know what it will do.
On the other side I fell in the trap of trying to overcome the limitations of purely declarative config formats by using jinja templates, which also ended up being a very bad idea and a maintenance nightmare.
For most projects, my approach is now to try to be as standard as possible compared to the particular community in the tech at end, and resist the urge to be smart or cute (hard!). Configuration always sucks, and I now prefer to just suck it up and get done with the config part, rather than loosing time reinventing the wheel, ending with a config that still sucks _and_ no one understands.
(More seriously: with Maven shorter and more boring is a sign that everything is correctly configured. Maven works by the convention over configuration principle so if you don't configure something it means it follows the standard. Which again means if you see someone has configured for example a folder or something that usually isn't configured it means they have put something in a non standard location.)
yaml's feature set is also too broad, forcing safe loaders
> yaml's feature set is also too broad, forcing safe loaders
Could you elaborate?
I think you can also make circular references in yaml effectively making a zip bomb
This is why you have yaml.safe_load in Python and SafeConstructor in Java's snakeyaml package
The end result is that you should not use yaml to handle untrusted data unless you are also explicitly handling it safely
It's possible someone could come along and write a json library that would support this, but somehow we have made it this far without it and that's a good thing
The point is that yaml and xml both have side effects in the form of require and eval that json won't, and frequently people are unaware of this
https://owasp.org/search/?searchString=json
Perhaps yaml and xml have _more_ ways to inject behavior into an application, but I would still not consider JSON safe in any way. Why would JSON.parse() even exist if `require()` and `eval()` were safe to use?
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.
The problem is that XML is ill-suited for configuration files.
Why?
I don't understand your comment.
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.
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.
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.
“YAML ain't markup language” is kinda the whole point.
First draft: https://yaml.org/spec/history/2001-03-30.html
Last draft calling it that: https://yaml.org/spec/history/2001-12-10.html
First draft with the new acronym: https://yaml.org/spec/history/2002-04-07.html
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.
<foo>
<bar>1</bar>
<bar>2</bar>
<baz>3</baz>
<baz>4</baz>
</foo>Ill tell ya hwhat... I made some simple functions; one to load any yaml/toml/json from file, by just looking at the extension (and providing an override for not normal file extensions). Another to output any data as yaml/toml/json.
I defaulted to using toml for my project, but have provided ways for everyone to be happy, with zero mucking around.
Aaaaaand for the not so subtle promotion, https://pypi.org/project/atckit
Located in the UtilFuncs class.
In any case, the library i linked has the functionality to load any of the three configuration types, so while i prefer toml, if you grabbed my (under development) project, and hate toml, you can use yaml or json, if you wish.
not all configurations are maintained by developers, or at least theoretically they shouldn't be.
I think, like almost all software, it depends on personality and other factors like how frequently someone has worked with a language/tool/etc.
If someone has the traditional Unix "read all the man pages in their entirety" kind of brain, they'll probably never use a GUI.
If someone has more of a "learn by example, then refer to the docs to cover cases the examples didn't handle" brain, a GUI can be a much easier way to clearly expose all the potential functionality of a tool. It's much easier to understand (IMO) than e.g. a template configuration file with every possible option present but commented out.
No. You need to define what configuration files are valid or not, but a subset of XML on the basis of syntactic and structural alternatives is lame and nonstandard.
Get a library that parses actual XML, allow anything reasonable as input (for example, no external entities, DTDs, PSVI etc. to keep the file self contained) and "flatten" CDATA sections, entities, namespace prefixes, idrefs etc.
I don't feel the same ease with JSON or YAML though.
I imagine the same is true for people that don’t like XML. There’s just many more people that find it easy to read JSON, even though there are a few that find it easy to read XML.
It looks like you're experience is mainly with XML as an underlying format, with human only dealing with it either at the coding level or through a tool generating the needed confs. In that kind of scenario I'd wager any coherent file format would probably work, even if the configs where encoded in brainfuck in the final step.
XML gets hated because we also had to read it and hand edit it as humans, when dealing with system configuration files (the source that will generate the rest of the configuration) and other upstream documents that are the base input for the system to read downstream when the GUI aren't available for that.
I've worked with a Symphony code base that used XML for all the routes and DI declarations, and yes it was an utter pain to write an edit tags for such simple and repetitive configurations when even an ini file would have been good enough. And god have mercy of the guys that put CDATA sections in the middle of that just to be sure CJK chars wouldn't accidentaly trip the syntax.
The nice thing about JSON, TOML, and YAML is they have implicit structures for arrays and key/values encoded within them.
XML has a lot of different ways of representing data that way, which is what makes it a challenging configuration file format.
That's as unambiguous as you could possibly make it IMO.
i think you're mixing representation of xml data vs the representation of them in a programming language.
XML does have arrays. They care called child elements.
["string1", "string2"]
<list>
<e>string1</e>
<e>string2</e>
</list>
However, the issue is that you have to write a custom parser. There is no direct mapping between your data structure and the XML file. This developer ergonomics is a big win for JSON and consequently YAML.
i think that's by design tbh.
it's only a big win for JSON (and YAML) because the default case works OK - but every time someone has a problem parsing numbers in JSON (because the value is bigger than Integer.MAX in the host language), this is the cause.
Take any random REST API for example. If it returns JSON, you can integrate it more easily than if it returned XML. If you need special cases like large numbers (or date-times), you handle only those.
With JSON, you can mostly do the same. Such that I don't necessarily see this as a huge advantage of XML, mind. Having a schema does have some advantages, though.
<foo>hello</foo>
<foo>world</foo>
"hello",
"world"
And you don’t even need a comma to separate the values! ;)
XML claims to solve the problem of attributes vs children but then falls short at the first hurdle by not discerning between a single complex object as an attribute and an array of complex objects as children.
JSON and YAML do not have this problem as they are explicit in their representation.
YAML example:
parent:
child: name
parent:
- child: name
You're either providing complex objects as properties or you're providing a list of complex objects. Worse, you can have a combination of both. Without a schema it is not possible to infer whether either or both is happening.
This seems like an absurd thing to say. XML went through an extreme bout of popularity. Maybe you could plausibly say that people have been soured on XML by ill-conceived uses for it that don't demonstrate its strengths... but you think most people have never worked with it? Come on.
https://truelist.co/blog/software-development-statistics/
So, according to the link - The average software developer age is between 25 and 34 years.
I think we should also define - are we talking about people who have worked with XML because they made a google site settings xml file OR people who have done serious work with XML and know what they're talking about?
First type - pretty much everyone.
Second type - not very many. I'm pretty much the only person who knows anything about XML wherever I go.
if you are 25 you have probably not done anything with XML or at least not anything important.
If you are 34 you might have, but I mean the last time I did anything really important with XML was 2013, I did a few other things since then because I knew XML was the best solution but that was me or because there was a very niche thing I was doing and the company was providing an XML api.
I bet most of the age 34s have not done anything meaningful with XML either, even though if you are 34 I suppose you probably had some ticket at some point that took you a week and you thought wow, my extensive experience with XML now gives me the right to grouse about how bad it is! If only everybody knew as much as I the world would be a better place!
on edit: my example of google site settings file is an example of some trivial usage, not meaning that pretty much everyone has done that exact trivial usage.
How was it more readable or richer than JSON? There's more stuff in XML, but in my experience that stuff doesn't actually help you any. The schema validation has a lot of detail, but since it can't access your actual system you can't really validate in that detail (like, maybe you can validate that an ID is between 6 and 8 digits long, but really you just want to validate that it's an ID for something that's present in your database). The distinction between attributes and nested tags feels like it should let you express more, but in practice it usually just gives you two equally reasonable ways to write the same thing and causes more confusion. Comments and non-tag text nodes feel nice, but complicate your parsing more than they're worth.
> Sure, XML has been used in SOAP like systems, and it rightfully gets a bad rap, but that is more on the user than the technology.
If one person uses the technology wrong, it's a problem with that person, but if most people use the technology wrong, it's a problem with the technology.
But yaml has the exact same problem. People use it where they shouldn't.
This is just an example.
Besides Microsoft frameworks that use XML as configuration, and Java frameworks and servers using XML for configuration (Tomcat comes to mind), no one else uses it. Maybe traditional software whose programmers don't know any better.
So yeah, I think the world doesn't like XML for really good reasons.
So pretty much all enterprises use it. Not bad for tech not in fashion.
There is a subset of XML that a decent language for some use cases. In particular it is good for documents whete you want a _markup_ language.
But I've seen it used for a lot of things where it wasn't a great fit.
And xml has too many features, which leads to implementations that are inconsistent with each, often slow, and have security problems such as xxe.
I wish that there was a standardized simplified xml format, that would avoid many of xmls problems and meet the needs of 90% of applications where xml is a good fit.
this plus, like GP said, java ee xml bloat culture made it too much of a pain
And I haven't changed my opinion since then, having worked extensively with XML: it is a plague that was brought on into the world and it needs to be killed with fire. I understand that when it was released there were no other alternatives so "it was better than nothing", but it should have died right after JSON was invented. But no, why have cleanly formatted file when you can have an XML one...
https://rimworldwiki.com/wiki/Modding_Tutorials/PatchOperati...
I designed a complex data acquisition system and after a lot of research, I settled on XML as the only viable option for complex user configuration, that is both readable and rich in content.
I then built a UI system that works with the XML and generates cofig docs with ease.
Sure, XML has been used in SOAP like systems, and it rightfully gets a bad rap, but that is more on the user than the technology.
A hierarchical document with values and attributes and custom tags? That is an almost DSL in itself.