Many of the tools that are using XML were likely written several years ago when XML was more popular and there were no standard alternatives. Rewriting their configuration to use an alternative format might seem like a waste of time that might be better spent of the tool's core.
Why XML is all the rage now?
Author
Yes, that does makes sense. I guess that in a few years we'll see more tools with current markup (or similar) languages.
Anyway, thanks for the answers! At least I know I'm not the only one who doesn't likes to look at XML :D
I hold the firm belief that given time, the open-source world will achieve its ultimate goal of reducing every piece of software in the world down to operations on a key/value store (see the rise of plist, JSON, Lua, and NoSQL).
Then we can resurrect the INI file, and be done with it.
XML is falling out of favor, but its still used in a lot of commercial software, particularly .net/java software, where ease of serialization make it very accessible. YAML and JSON are saner options for simpler structured data files, and are typically good enough for simpler use cases like configuration files. Importantly, both of those formats are a lot less verbose, and the support libraries are much smaller than for XML.
On the other hand, YAML and JSON are no substitute for XML is many applications, where more robust data formatting is needed, or where, you know... you're actually doing markup. There are a lot more tools available XML -- XSLT for one, XSL for another, and being able to verify the document structure with DTDs for a third.
XML is far from a bad technology, its just the sledgehammer everyone seems to use to hang pictures on their walls.
I've been working with YAML lately and have come to the conclusion that it needs to die screaming. I have not found a single library (other than libyaml in C) which follows the spec correctly (I need a library for .Net - several are available but none of them work). The spec itself is incredibly difficult to read, making it hard to write your own library. YAML written out by existing tools is often incompatible with other tools (indicating that one or the other isn't following the spec).
JSON is widely supported. Libraries usually just work or are easy to fix if they don't work. It's easy to write a library from scratch due to the extremely simple rules.
XML is extremely well supported and it's hard to find libraries that have show-stopping bugs in them. Writing an XML library is much harder than JSON but you usually don't need to.
I don't LIKE any of these formats, but XML and JSON at least are fairly easy to work with if you need to.
JSON is widely supported. Libraries usually just work or are easy to fix if they don't work. It's easy to write a library from scratch due to the extremely simple rules.
XML is extremely well supported and it's hard to find libraries that have show-stopping bugs in them. Writing an XML library is much harder than JSON but you usually don't need to.
I don't LIKE any of these formats, but XML and JSON at least are fairly easy to work with if you need to.
Points about JSON > XML aside...
As a game developer, the big deal to me is that it's a flexible standardized text format which means:
- I don't have to create my own libraries to read, write, or navigate it.
- At least for the purposes of developing and debugging tools that use, generate, or convert it, it's human readable.
- It's diff-able and potentially merge-able, which to me makes it first-class revisionable.
The open source engine I use came with solid XML support that is open source and works well. I know how to use it to print out valid properly formatted XML. Thus XML works extremely well for any purpose in the engine since it can read it and write it.
I agree that the verbosity is somewhat annoying. But its widely supported, easy to use and understand, free libraries.
Its just so convenient. Maybe its slow or bad for large documents or w/e. But its worth it.
FWIW, some of my stuff uses S-Expressions... (mostly for structured data: ASTs, world delta-messages, ...)
I had considered a few ideas a few times for other concise syntax designs partly combining S-Expressions and XML, but haven't done much with it.
some of my stuff also uses a binary serialized (and Huffman coded) variation of S-Expressions.
a few other things use a binary serialized XML variant.
there are tradeoffs either way, the main advantage S-Expressions having is that their in-memory form can be a lot easier and more efficient to work with. it takes a bit of work to get good-performance from a DOM-like system (and generally involves "tricks"), whereas S-Expressions can be handled straightforwardly and moderately efficiently by straightforwardly implementing Lisp-like APIs.
sometimes, they key/value nature of XML attributes is useful, and doing similar using S-Expressions is less efficient than with explicit key/value pairs.
this is one area XML (and JSON) have an advantage.
one option is to extend S-Expressions, potentially ending up with a format like EDN.
another option is mostly to strip down and streamline the XML notation, and constrain/tweak it in a few ways to permit a more efficient implementation.
...
a lot depends on use-case though.
generally, I was using things more for structured data, such as world-delta messages and compiler ASTs.
OTOH, for configuration files I have most often used line-oriented command-driven text formats (the analogy being using batch-files or shell-scripts as config files).
I think XML was all the rage around 8 - 10 years ago. Most new tools I see are using Json.
I'm still using XML because it works, because I'm used to the library (TinyXML) that I'm using it with, because I have existing code that makes use of it, and because it doesn't make any real difference.
XML is ugly? Sure, but who told you that you're entitled to look at the files? People always seem to imply that every file must be inspected in a hex or text editor, everything must be human readable, and everything that remotely looks like one might be able to edit by hand must be edited by hand. Why?
XML is overly complicated, redundant, bloated, etc...? Read again the last paragraph. You need not look at it if you don't like it. You need not edit it, The Program will read/write its data just fine without you interfering.
XML takes way too much storage space? Wait, did you hear that? That's the world's saddest song playing on the world's smallest violin. Seriously, you have an office package installed that takes half a gigabyte of disk space only for a text editor and a spreadsheet, you have 2 TiB of MP3s on your harddisk, and you worry whether a puny XML file is 4 kiB or 8 kiB? Tell you what, there is WinZIP if you need to worry about 4KiB. Right, the XML files in your content pipeline aren't precisely 4 kiB, they're more like 40 MiB. Good grief, I'm shocked.
Sure, there are other formats that are more comprehensible and more space-efficient. And sure, I'd rather use msgpack or protocol buffers when data has to go over a wire. If I was starting from zero, I'd probably choose something different for on-disk storage, too.
But as it is, for most things, XML works just good enough by all means. It isn't pretty, but who cares.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
