XML ≤ JSON ≤ Yaml ≤ Blue


Software developers have been fiddling with configuration files for far too long: INI files, XML, Plists, JSON, Yaml, TOML, ...
have we missed any?

Creating a good configuration file for your software shouldn't be an afterthought, because it's one of the first things your customer will need to use.

A Brief History

INI files were a good idea and caught on because they used simple a keyword=value paradigm, but the [section-name] grouping feature was never really that useful.

XML files were a good idea because you could structure your parameters into a meaningful hierarchy, but all those opening and closing tags were a real pain!

Plist files took the XML approach even further, by standardizing the semantics, but did nothing for readability.

JSON files became an industry darling because it was so darn easy for the developer to read and write, but that simply shifted the burden to the customer, who had to deal with all those quotation marks and commas, without any way to add instructional comments.

Yaml files put the emphasis on readability and are a superset of JSON, so things are looking brighter here for the customer, and its use of indentation, colons, and dashes is easy, but it takes a bit of head-scratching to use anything more than that.

TOML files go full circle, deriving inspiration from the INI paradigm, and adding hierarchy to its sectioning, but it doesn't support attributes or "includes".


And now there's BLUEPHRASE, which seems to be a pretty good contender in this space because it has: keyword values, attributes, hierarchical structure, comments, include pragmas, and best of all — simple readability.

With BLUEPHRASE these features are notable:

  • Keyword-value (KV) pairs do not need colons : or quotation-marks " ... ", so there's less clutter.
  • Attributes can be add to any KV pair with asterisk * shorthand notation.
  • Filenames and paths are delimited with grave-accent ` ... ` shorthand notation.
  • Hierarchical structure is created with curly-brace { ... } notation.
  • Comments can be either C-style /* ... */ or C++ style // ...
  • !include pragmas allow you to split parts of your configuration into separate files.

Here's a sample taken directly from an RWSERVE configuration file:

host {
hostname example.com
alias www.example.com
document-root `/srv/example.com/public`
server {
modules {
cache-control on
content-encoding on
etag on
information-headers off
ip-access off
forbidden off
request {
accept-types {
mime-type text/html
mime-type text/css
mime-type text/blue
mime-type application/xml
mime-type application/json
mime-type image/gif
mime-type image/jpeg
mime-type image/png
cross-origin {
`/restricted-api/*` *origin="signin.example.com"
`*` *origin="trusted.example.com"
response {
charset {
text/html UTF-8
text/css UTF-8
text/blue UTF-8
application/xml UTF-8
application/json UTF-8
content-encoding {
text/html gzip
text/css gzip
application/xml gzip
application/json gzip
image/gif none
image/jpeg none
image/png none
logging {
message-type {
request on
staging off
information off
response on

XML ≤ JSON ≤ Yaml ≤ Blue

🔗 🔎