XML loosed a lot of its popularity since the emergence of other markup languages or data interchange formats like JSON or YAML.
Most newer software projects tend to use JSON or YAML, because XML has several drawbacks:
* Bloated syntax because of the opening and end tags. Therefore a document contains a lot of redundant data. This leads to larger file sizes than alternative formats would need.
* Hard for humans to read, especially when there are complex DOM structures.
* More complex parsers needed than for example for JSON or YAML.
* No defined data types like JSON supports, like booleans, strings, numbers and arrays.
In addition I noticed that not much package formats use XML for metadata. In fact, I only know nuget which uses it.
Debian packages for example use a “property: value” structure in the control file, for example:
Section: x11
Priority: optional
Maintainer: John Doe
This is somewhat comparable to YAML and a lot easier to read than XML documents. RPM packages also use a similar structure for its specfiles.
Packages for Arch Linux use a file named PKGBUILD, which is a bash script file. The metadata is specified as bash variables, which automatically allows data types like arrays. Example:
pkgname=audacious
pkgver=3.3.4
url='http://audacious-media-player.org/'
license=('custom:BSD')
arch=('i686' 'x86_64')
depends=('gtk3' 'dbus-glib' 'libguess' 'libsm' 'audacious-plugins' 'hicolor-icon-theme' 'desktop-file-utils')
Packages for [npm](https://npmjs.org/), the package manager for node.js, use JSON for package metadata. The same applies for [bower](http://bower.io/), a very popular package manager for the web.
Wouldn’t it be better to switch to JSON or YAML instead of insisting on XML, a format which loosed a lot of its popularity, and deservedly so?
Personally I’m more attracted to YAML, because it has an even simpler syntax than JSON and nobody can come to the idea to directly process it with JavaScript (which can be a security concern) instead of using a parser.
Comments: Thanks for your feedback. I accept your decision. The metadata format is something that should be decided during the package format design phase. After that it isn’t too late, just harder to accomplish.
Most newer software projects tend to use JSON or YAML, because XML has several drawbacks:
* Bloated syntax because of the opening and end tags. Therefore a document contains a lot of redundant data. This leads to larger file sizes than alternative formats would need.
* Hard for humans to read, especially when there are complex DOM structures.
* More complex parsers needed than for example for JSON or YAML.
* No defined data types like JSON supports, like booleans, strings, numbers and arrays.
In addition I noticed that not much package formats use XML for metadata. In fact, I only know nuget which uses it.
Debian packages for example use a “property: value” structure in the control file, for example:
Section: x11
Priority: optional
Maintainer: John Doe
This is somewhat comparable to YAML and a lot easier to read than XML documents. RPM packages also use a similar structure for its specfiles.
Packages for Arch Linux use a file named PKGBUILD, which is a bash script file. The metadata is specified as bash variables, which automatically allows data types like arrays. Example:
pkgname=audacious
pkgver=3.3.4
url='http://audacious-media-player.org/'
license=('custom:BSD')
arch=('i686' 'x86_64')
depends=('gtk3' 'dbus-glib' 'libguess' 'libsm' 'audacious-plugins' 'hicolor-icon-theme' 'desktop-file-utils')
Packages for [npm](https://npmjs.org/), the package manager for node.js, use JSON for package metadata. The same applies for [bower](http://bower.io/), a very popular package manager for the web.
Wouldn’t it be better to switch to JSON or YAML instead of insisting on XML, a format which loosed a lot of its popularity, and deservedly so?
Personally I’m more attracted to YAML, because it has an even simpler syntax than JSON and nobody can come to the idea to directly process it with JavaScript (which can be a security concern) instead of using a parser.
Comments: Thanks for your feedback. I accept your decision. The metadata format is something that should be decided during the package format design phase. After that it isn’t too late, just harder to accomplish.