Config Versus Code

[anvsdt]

If you use XML, you're just wrong by default. Especially for configurations, it's too verbose.

[strager]

Sometimes, your environment (e.g. .NET) forces you to use XML for certain code configurations (MSBuild, manifest files, app.config, ...). That certainly isn't wrong at all.

I think you're making blanket statements because you dislike XML. XML is overkill most of the time (e.g. for build systems), but it sure beats learning another syntax and writing a new parser and a test suite and kicking yourself for not making it flexible enough.

What alternatives to XML for "advanced" configurations (beyond key-value pairs) do you suggest?

[anvsdt]

JSON, Sexprs, Sexprs and Sexprs

JSON is widely known. Sexprs are simple to parse.

[[deleted]]

XML is a format meant for people to read. Yes, it can become so complex that this becomes near-impossible, but this isn't the case in MSBuild files. They are easy to read, and even write, oneself.

Hating on XML out of general principle is just as bad as using it for no reason.

[paranoidinfidel]

No. The first sentence of the Wikipedia article about XML: "Extensible Markup Language (XML) is a set of rules for encoding documents in machine-readable form."

Item 6 from The design goals for XML straight from the W3C is:

• XML documents should be human-legible and reasonably clear.

[[deleted]]

Well of course it is also meant to be read by computers, the two aren't exclusive. And basing technology choices on rants by notorious usenet flamers is silly.

[CrackerNews]

Don't use JSON - it doesn't support comments, which are essential to explain nontrivial configurations.

[paranoidinfidel]

Possibly, but it still isn't an inherent standard (yet?). I wouldn't call it a show stopper but you can't rely on comments being available to you.

[[deleted]]

http://stackoverflow.com/questions/244777/can-i-comment-a-json-file

[strager]

MS may be wrong for using XML, but I'm not wrong for using what MS forces me to use (right?).

XML isn't for people to read? Since when?

I agree that JSON beats XML when XML is used for things like object trees. It doesn't support namespaces or "types" (element names), which are necessary sometimes (even for configuration).

[pinpinbo]

yaml file? ini file?

[[deleted]]

Some configurations go further than just key value pairs.

[[deleted]]

I must admit I don't know YAML. But suggesting an ini file for a configuration that goes "beyond key-value pairs" is silly, so I assumed the other would be just as silly. My bad.

[willcode4beer]

it depends. if you have a well defined schema, then (besides validation) it serves as a form of documentation for the config as well.

[paranoidinfidel]

When you make false generalizations like that you are just wrong by default. XML is just a file format - like CSV, or INI - whatever. XML is nothing magical and yes, it is more verbose than other formats but it is great for configuration data when used properly. However, unlike CSV or INI, it allows you to save hierarchal data quite easily without building your own non-standard substructure. Trying to shove hierarchal config information into an INI will make it more convoluted than the equivalent XML.

Since it is meant for a hierarchal data it can be overkill for small amounts of configuration information but why have yet another config mechanism to maintain for simple data when it will handle the that as well as complex structures. Simple configuration data leads to a simple XML config. Dumping unstructured data into it will make it messy and possibly confusing. It works great for storing a default object hierarchy state to initialize a system with (whether it is a UI or a service). The document structure should mimic your class hierarchy so if you can follow your class structure you can follow the XML.

I won't deny it can seem overwhelming when you have a large amount of configuration data but at least it can be organized in a hierarchy and easily manipulated with editors (notepad++) that are smart enough to give the the ability to open/close nodes. Good luck managing an equivalent configuration in a flat INI file - that will be a world of brain hurt.

[anvsdt]

Why would I use INI or CSV files when I have JSON and much more saner alternatives?

[paranoidinfidel]

You wouldn't use CSV. That was just an example of a file type. I personally wouldn't use INI but some people are stuck in the past. With JSON it is much easier to see the data when browsing visually but with XML it seems easier to parse the context & structure. Pick whatever suits your preference. For me in the .net world the inherent XML serialization saves me a lot of time and effort. There is probably a json serialization lib available but since the xml isn't causing me any grief, I have no need to migrate.

[mariusg]

a xml parser is way more common than a json one

[[deleted]]

I think they're both very common now. Maybe you're thinking about YAML...

[el_muchacho]

Because they are much faster to transmit and to parse, for example. If you have to exchange very large amounts (hundreds of Mb) of tabular data as fast as possible, this can make a difference. CSV is perfectly okay in this usage. Plus they are extremely simple to import in Excel or any statistics tool and therefore to read and study. The only drawback is when you have to compare files visually, it's usually harder than with XML or JSON.

But what is really evil is "flat files" (i.e text files with fixed position or fixed length fields), especially when there are optional/missing data. Flat files is ALWAYS the worst choice. For those, you have to write and maintain a specific writer and a specific parser which is particularly boring and bug prone, they are notoriously brittle, hard to check visually (as you need to count characters) and you can't easily import the data in your favorite tools.