Markup without the Markup
While my research has been anything but thorough, I’ve discovered two gems: YAML and OGDL. To get an idea of how these forms of anti-markup data representations, let’s take a simple example: a Maven project.xml file. You can find an example at:
http://cvs.sourceforge.net/viewcvs.py/jingdao/jingdao/project.xml?rev=1.7&view=markup
Here’s the equivalent using YAML:
pom version : 3
id : jing-dao
name : Jing DAO Framework
current version : 0.6.5
organization : { name: JadeTower,
url : http://jadetower.org,
logo: /images/jadetower-logo.png }
inception year : 2003
package : org.jadetower
logo : /images/jing-logo.png
description : Java Based DAO Framework
url : http://jingdao.sourceforge.net
issue tracking url :
http://sourceforge.net/tracker/?group_id=75092\&atid=542902
site address : jingdao.sf.net
distribution directory : /home/groups/j/ji/jindao/htdocs/dist
mailing lists :
- name : JingDAO Developer List
subscribe : http://lists.sourceforge.net/lists/listinfo/jingdao-devel
unsubscribe : http://lists.sourceforge.net/lists/listinfo/jingdao-devel
archive : http://sourceforge.net/mailarchive/forum.php?forum_id=35345
developers :
- name : J Aaron Farr
id : farra
email : farra@apache.org
organization : JadeTower
roles : [ Java Developer ]
dependencies :
- group id : avalon-framework
artifact id : avalon-framework
version : 4.1.4
url : http://avalon.apache.org/framework
properties : { jar.include: true }
- group id : excalibur-configuration
artifact id : excalibur-configuration
version : 1.0
url : http://avalon.apache.org/excalibur
properties : { jar.include: true }
- group id : commons-beanutils
artifact id : commons-beanutils
version : 1.6.1
url : http://jakarta.apache.org/commons/beantutils
properties : { jar.include: true }
- group id : commons-logging
artifact id : commons-logging
version : 1.0.3
url : http://jakarta.apache.org/commons/logging/
properties : { jar.include: true }
- group id : commons-collections
artifact id : commons-collections
version : 2.1
url : http://jakarta.apache.org/commons/collections
properties : { jar.include: true }
- group id : picocontainer
artifact id : picocontainer
version : 1.0-beta-3
url : http://picocontainer.org
properties : { jar.include: true }
- group id : bsh
artifact id : bsh
version : 1.3.0
url : http://www.beanshell.org
properties : { jar.include: true }
- group id : sun
artifact id : jndi
version : 1.2.1
build :
source directory : ${basedir}/src/java
unit test source directory : ${basedir}/src/test
unit test :
includes : [ **/*TestCase.java ]
excludes : [ **/Abstract* ]
resources :
- directory : ${basedir}/src/conf
target path : BLOCK-INF
includes : [ block.xml ]
Now you tell me, which is easier to read? And if they can both be easily, predicable, and accurately parsed by a computer, then why shouldn’t we use the easier one?
You might also want to check out some interesting examples of OGDL (Ordered Graph Data Language).
Alternatives to XML exist. Perhaps they will never become buzzwords, but perhaps we shouldn’t be so anxious to use XML whenever possible. I feel I’ve been guilty of that in the past and I’m beginning to learn from the mistake. That’s not to say that XML isn’t useful, but it has it’s time and place.
Now all I need to do is put together YAML and OGDL implementations of Avalon’s configuration API. :)
Thanks to Rolf Veen for pointing out it’s OGDL not ODGL :)
§Commentary