Hacker News Reader

Comment by kumarvvr | Hacker News Reader

Most people who lambast XML probably have never used XML or never had to need XML.

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.

View on HN

> I then built a UI system that works with the XML and generates cofig docs with ease.

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.

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.

I'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.

Why? 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.

You 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.

I'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.

It'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.

Yeah JSX and especially TSX would be quite nice. YAML though can’t die soon enough.

You think that JSX would be suited for configuration files?

Why?

I don't understand your comment.

Because 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.

dhall looks nice actually! Thanks for elaborating :)

> 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.

For a full year it stood for "Yet Another Markup Language".

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

It's also funny that the file extension YML is the successor of XML, so the rest is probably a backronym from that.

The file extensions for yaml is .yaml, .yml is the alternative because of legacy 8.3 systems.

Wouldn't the successor of XML be XMM?

Next you'll be telling me Beyonce's sisters should be named Beyoncd and Beyoncf instead of Aeyonce and Ceyonce.

Feyonce can’t get anyone to believe she’s married and Vakira’s has astonishingly honest hips

Judging from BCPL, the successor should just be Y.

The thing is if you're using it as configuration language, object notation is correct, not markup.

I'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.

Ok 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>

Why do you think there is a "right" way?

I think I’d prefer JSON over both XML and YAML when dealing with config files.

XML is just to verbose, making it harder to parse in my brain.

YAML is whitespace sensitive which I hate in general.

I'm fine with JSON except it doesn't officially do comments, but that's a big deal IMO

Which is especially problematic for config files where you want helpful hints or a place to store the “old value” while you do something else with the app. I have an app where I change a specific config almost every time I use it. I usually just copy the entire darn node and rename it to something that doesn’t get deserialized. Closest I can get to holding the value in a comment.

Might be interesting to check out json5.

https://json5.org/

This is a great example why we should avoid writing custom DSLs and just use a proper programming language.

Then again, Gradle has come to show why that is a terrible idea.

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.

I had the same experience with Maven vs SBT (scala build system, config is scala). At first it is really cool to have access to a full programming language (in particular when it is the same as the one the project is in, which means that you do not need to "switch brains" when working on the config), but quickly people start trying to be smart or cute, and it becomes a big mess. In particular in Scala, where people _love_ defining new DSLs and favor cuteness over readability. After two years working with SBT I still do not really understand some of the DSLish constructs used in there (and I tried to read the docs).

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.

The good thing about Maven is it is XML so everyone wants to keep it as short as possible ;-)

(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.)

I think it's only popular in the scala ecosystem, but I find HOCON to be a pretty nice superset.

XML is whitespace sensitive, unless your particular schema just doesn't care about whitespace text nodes.

Much easier to have invalid JSON than invalid XML as jsonschema isn’t even close

You know that JSON is subset of yaml, right?

The commenter said they preferred json over yaml because yaml is whitespace sensitive; Json is not

yaml's feature set is also too broad, forcing safe loaders

I think the point is that if something accepts YAML, you can feed it JSON without issue.

> yaml's feature set is also too broad, forcing safe loaders

Could you elaborate?

Yaml tags allow for serialization of native types, and has been abused to run malicious code.

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

Any de-serialization should be done via safe loaders. Using `require()` or `eval()` isn't something I'd do outside of a very narrow set of scenarios.

The json modules in the same languages doesn't support the madness and doesn't necessitate a safe loader

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

I feel I must still be misunderstanding something. OWASP has pages of resources which talk about the lack of safety of JSON:

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?

Since most people’s (especially critics) understanding of YAML is stuck on YAML 1.1 where that wasn't quite true, probably not.

> But now I realize that modern developers don't want a GUI to manage their config.

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.

I recently started a new project, and just outright didnt want to use yaml to do it. Sadly, im not everyone, and if i plan to release this project, i need to account for that. Whats a guy to do?

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.

What is the point of substituting yaml for something even worse?

Worse is subjective.

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.

> a well-defined subset of XML

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.

>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.

not all configurations are maintained by developers, or at least theoretically they shouldn't be.

I built it to make it so that average users can make their own config. The main system works off on only XML files.

I have used XML a fair amount in past years, but now avoid it.

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.

The only objectionable feature of xml is dtd, everything else is easy to implement in 600 LoC.

I also think namespacing adds complexity that usually isn't needed.

Namespaces can be parsed as attributes, then you can add a namespace resolver as a third party algorithm.

> Most people who lambast XML probably have never used XML or never had to need XML.

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.

I've done my fair share of systems integrations and the number of teams that did not know xml or have never used it in a professional settings was around 20%. Of those who did use it a staggering amount of people never understood namespaces and started testing for equality on the element name and namespace prefix string instead of the namespace declaration. When somebody claims they "know" xml I initially treat it as a developer saying that he/she knows 'sql' while reviewing their code and seeing them do joins in the application logic.

That is the problem with XML, there is so much logic that is needed in the application so to be able to understand it. You just need so much knowledge.

> 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.

I am 34 and I feel like when I started at this job we were still going through the “everything must be XML” hangover. But hey there’s always a higher mountain.

It depends on what age you are and whether you work with documents. If you started working in the industry past 2010 and didn't have to work with generating/reading (X)HTML/OOXML/ODF than it's rather likely you've never had an experience with XML (fortunately SOAP was deprecated very quickly).

My issue with xml for configuration files is not understanding when to use elements vs attributes to describe data.

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 arrays point is such a weakness in XML that I rarely see addressed. Arrays and lists are such a common data structure in almost every programming language of the past 40 years that not having first class syntax for representing them is absurd and a huge weakness that makes XML a non-starter for me.

I wrote many configuration files and encountered maps and sets, but never arrays.

The qualities of sets that arrays don't have (and vice versa) are irrelevant to the point of neither being implicitly representable in XML.

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.

> not having first class syntax for representing them

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.

No you've misunderstood my point. This doesn't work for cases where one child is in fact a property that is a complex object.

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

Try converting each of these to JSON. The former will give you an object property called child, the latter will give you an array property called child with one element

I'm not sure about that - I think your second example will parse to "parent": [{"child": "name"}] in JSON

Yeah this was what I was going for, same point stands

Aren't XML child elements pretty much the most verbose way you can represent an array though?

I think the verbosity is not a problem. For example if you compare

    ["string1", "string2"]

    <list>
        <e>string1</e>
        <e>string2</e>
    </list>

then each element has about four bytes overhead (<e> instead of " and </e> instead of ",) plus some overhead for the list itself that may be offset by putting the name of the list itself into the element.

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.

> There is no direct mapping between your data structure and the XML file.

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.

Yes, I understand that (and I like XML as a format and XSLT 2.0 as a language). However, from the popularity of JSON, it seems that for most cases it's the easier choice.

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.

I'm confused? Integrating XML was fairly easy back in the day. If in a dynamic language, serialize into a DOM and then use xpath to get data out. If in a static language, parse into your objects.

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.

JSON maps only to javascript, but only because it was designed as a subset of javascript, for others you have to use DOM or serializers, then there's no difference between formats. For this matter, xml has generic serializers than can be used instead of writing custom one every time.

If you interpret the start and end tags of the child elements as syntax indicating the type of each value, then those tags are analogous to, say, the quotes that enclose a string literal. In other words, in

    <foo>hello</foo>
    <foo>world</foo>

the <foo> and </foo> serve the same purpose as the double quotes in

    "hello",
    "world"

with the added benefit that the type system can be much richer (i.e. not everything is just a nondescript string value).

And you don’t even need a comma to separate the values! ;)

The main reason i avoid any typeless language is dates... how do i represent a date/time including a time zone has been badly reinvented so many times. A string type is never the way to go there in my opinion.

One of the classic lessons of the Falsehoods Programmers Believe about Time is that in general you can't correctly do better than simply storing the user's input (and the instant and place they entered it from) verbatim, unless you know something more about what they were entering. It's usually fine to store times in the past as a timestamp since the epoch plus a location, but the meaning of "2025-01-28 15:00 in Europe/London, for the purpose of a meeting that's being hosted there but is accessible by video call" is much more subject to change when e.g. countries change time zone. It's also not necessarily the same as "the absolute point in time 2025-01-28 15:00 assuming London's time zones stay as predicted since I entered this on 2023-09-21" or "2025-01-28 15:00 in Europe/London, for the purposes of a meeting that's being hosted in Lisbon but which I'm accessing by video call from London" (because then the Lisbon local time is the source of truth, not the London one, if Lisbon changes time zone).

What’s the best representation you’ve seen for dates?

Hasn't https://en.wikipedia.org/wiki/ISO_8601 basically won, at this point?

UNIX timestamp. Plus timezone string, in separate field/column, if it's important for the use case (like calendar events, etc).

Epoch time + GPS coordinates.

That's as unambiguous as you could possibly make it IMO.

The problem is that xml just isn’t particularly human readable. I don’t think there’s more to it than that. The brackets just make it overly verbose and difficult to read at a glance.

I have heard this again and again. But to me, well formed XML is incredibly easy to read and skim.

I don't feel the same ease with JSON or YAML though.

> 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.

Yes! I find JSON so, so hard to read compared to XML. I thought I was the only one :-)

Your not alone: it's verboden requiring " around anything that is a string. Commas to separate array elements. It's a technical format without the technical foundation. It's the civil engineering equivalent of building the Golden Gate Bridge out of wooden beams as that is what you have, not what you need.

You are not alone.

I find it very easy to read. The additional structure only helps. Why does anyone have a problem reading XML?

This. It dances in front of the readers eyes, turning into unreadable gibberish. Json is how you would draw a datastructure on a chalkboard.

It's the same syntax shape as HTML and React's JSX, yet rarely do people complain about how "unreadable" they are?

HTML is not a configuration format. Tags are fine for text markup.

The game Rimworld uses XML for describing all of its game objects and it makes modding a fantastically wonderful system as you can modify/replace parts of the object using XPath. The end result is mods rarely conflict as they are able to target the specific mutations they want quite easily

https://rimworldwiki.com/wiki/Modding_Tutorials/PatchOperati...

> I then built a UI system that works with the XML and generates cofig docs with ease.

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.

I have delivered XML data products comprising terabytes of information in (when I last checked) more than 800 schemas to companies around the globe, and people who have a rosy view of XML are using missing how it usually works in practice. XML is extremely heavy and brings a lot of half-baked ideas, and consumers are almost never flexible in ingesting the XML. It means teams wind up supporting insanely convoluted schemas that customers will never migrate off of.

I can’t help but agree that if we had just built better tools, xml would have had better adoption.

I actually think that XML has some of the best tooling in the entire industry. The problem is: It's mostly commercial tooling, which costs money. Stuff like Oxygen or XMetaL is pretty neat, and I always found Visual Studio's "Create Web Client from SOAP" pretty useful (especially if the Web Service is written in .NET, since it auto-generates a proper WSDL file).

XML is all about tooling, but most FOSS folks insist in holding it wrong, editing XML files in vim/emacs.

I find XML tool in general feature complete and great.

Especially editor integration works great as opposed to YAML which is so ambiguous that it IntelliJ IDEA constantly breaks indentation during copy and paste.

And better conceptual docs because it's supposed to be that elements are complete deserializable objects. Having to resort to xpath as the default way of poking at XML where JSON has a good implicit default schema made XML feel so clunky.

At least xml has xpath ;-) the implicit Jason to object mapping has failed me on character encoding (no way to specify that in json). Stupid type errors (date/large numbers).

I have a deja vu over YAML and XML. There was a similar discussion about this a month or so ago, IIRC.

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...

JSON syntax is optimized for serialization and thus unsuitable for other purposes, and for serialization loses to binary formats except for one use case: it's a serialization format that can be nicely embedded in html.

too much energy wasted on endless xml schema debates while a bit of { a : [1,2,3] } was enough to do 80% of your job

this plus, like GP said, java ee xml bloat culture made it too much of a pain

Real XML has never been tried.

> I settled on XML as the only viable option for complex user configuration, that is both readable and rich in content.

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.

> 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.

Do a mental exercise and think about what would k8s with XML configuration would have looked like and if would have taken off like it did using XML for configuration instead of YAML.

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.

I would have very much preferred it. It would be a lot more readable and accessible. Nowadays there is tooling, but imagine having schemas and autocomplete for all the K8s files from day 1.

So pretty much all enterprises use it. Not bad for tech not in fashion.

K8S problem really isn't YAML, it's that the thing it's trying to configure is a naturally complicated space that really wants to be typed but can't commit to any one language either.

I'm not a big fan of YAML, but I think it has a better "hit rate" than XML.

Reply on news.ycombinator.com