One of the biggest questions when designing or using an
application is the language for the configuration file such as admin login
details and database connection details.
The traditional and popular option for applications and
databases such as MongoDB and Nutch use the XML but since the introduction of
JSON and YAML has resulted in many developers suggesting the complexity of XML
However, it is far
from clear cut as from Stack Overflow http://stackoverflow.com/questions/791761/xml-for-configuration-files-why
The main advantage of YAML over xml is the readability and
the ease for non-programmers to change a configuration file.
Despite the simple appearance of YAML in contrast to XML and
JSON the syntax contains variations and has additional features which make it
more complex for developers to use initially without having an in depth
understanding of the standard.
There is debate as to whether or not JSON is a sub-type of
YAML with the suggestion made by some that all JSON meets YAML whereas others
suggest this is not the case.
Ultimately the benefits of YAML do not lie within
performance as despite claims the lack of punctuation leads to a smaller file
for parsing the reality is that the spaces included within the identation of a
YAML file outnumber the characters in a JSON file for the same purpose.
Therefore, YAML is not advised for the transfer of data and
should therefore only be used sparingly for configuration files. On the other
hand XML has been suggested to be too complex for configuration files unless
there is a purpose to use the language features of XML.
Finally, a more recent language developed called TOML (you’ve
guessed it, it was developed by Tom and he’s developed his Own Minimal Language!).
It is minimal in that it simplifies the hierarchy system in contrast to JSON
without bringing in the whitespace
issues of YAML. Similarly it avoids the introduction of the complexities of XML namespaces.
The key benefit is that the use of [foo.bar] retains a clear
and readable format for those who understand hierarchies.
Overall, the decision will depend upon the structure and purpose of your application. My interpretation is to keep it simple unless you need the added complexity.