XML is Not the Answer

January 10, 2005 8:08 AM

Found this entry of "things Java programmers should keep in mind moving to Python" via my increasingly spam-polluted referrer logs. (Give up, guys, it's blocked by robots.txt, so no legitimate search engine is going to pick it up.)

Anyway, by explaining how the other half lives, this quote sums up my philosophical objection to, but grudging acceptance of the proliferation of XML configuration files in Java.

XML is not the answer. It is not even the question... This is a different situation than in Java, because compared to Java code, XML is agile and flexible. Compared to Python code, XML is a boat anchor, a ball and chain. In Python, XML is something you use for interoperability, not your core functionality, because you simply don't need it for that. In Java, XML can be your savior because it lets you implement domain-specific languages and increase the flexibility of your application "without coding".... But in Python, more often than not, code is easier to write than XML.

13 Comments

mark·up n.

An amount added to a cost price in calculating a selling price, especially an amount that takes into account overhead and profit.

Perhaps I could interest you in some alternative to the dreaded tax:

http://alt.textdrive.com/pl/

this you dont need xml if you code in python or ruby meme is so much horseshit.

like everything xml has it place. as coding 'support' its place is as a declarative config data format. data that can be manipulated by a myriad of out of the box tools providing namespace support, data validation etc. etc.. does python code never have config data that could be usefully manipulated outside its coding context?

I agree wholeheartedly. XML is a clunky way to configure anything.

Pardon my ignorance... but why not use full Java for configuration?
When I want to configure something, I provide an interface to implement and then different configurations provide different implementations. You have the full flexibility of Java and can interact with the application in the same way as you are suggesting using LISP.

I am guessing it is something to do with the fact that Java has to be compiled?

This would indeed be a limitation if you are expecting non developers to alter the configuration. On the other hand, you could not expect nondevelopers to write LISP code either! If the configuration is being altered by IT, it seems possible to use Java classes for configuration. I'm not an enterprise Java programmer, so there may be technical problems in that environment I am unaware of.

"colt", my "Real Names, Please" policy is linked clearly from the comment form.

Andreas: The Scheme thing was mostly a thought experiment - it never made it into any production code.

The basic problem with Java code is not that it's compiled, but that it's clunky. Configuration files need a clean syntax for building data-structures, something that Java lacks. So we use XML, which is still overly verbose, but is at least clearer.

Spring (http://www.springframework.org) illustrates another advantage of XML over Java and - dare I say it - Python: XML lends itself to declarative configuration files, where earlier entries can refer to later entries and circular references are possible too.

I still agree that XML is overused. Groovy has some neat features for representing data structures.

People do tend to put too much and too complicated information in configuration files. Most config info will never be touched and most of it could be done with simpler property files. What is happening here is a antipattern I like to call "Coding in XML".

Charles:

I pity any programmer who considers Java too clunky for his configuration files yet uses it for the actual code of his application! Seems odd to me....

Perhaps an example I can relate to is configuring Swing components. Using Java can be quite verbose for this; a separate call is required for each attribute; colour, style, size etc. Putting this in an XML file is cleaner, although its also more complicated.

How would the equivalent work in Python or Scheme?

I find that when I write the config for a webapp, I generally stick each set of parameters (e.g: username, password, and host for datasource access) as a line-break delimited group of tab-separated values. If I want a list of parameters, I just use commas, and then split(","). I have methods with signatures like ServletUtils.getMapIP(Servlet s, String name) to make things easier.

My point here is that defining one init-param(param-name,param-value,description) per quanta of information in my config files would quickly become boring, whereas using the given format to define logical groups of values is much simpler.

Of course, there are arguments against pasting a (two-column) tab-separated table into a web application deployment descriptor, like (a) you can't edit it easily from a textarea, and (b) it's supposedly in defiance of the laws of nature, but it's easy and it works.

"How would the equivalent work in Python or Scheme?"

Like this:

[[[
a='foo.com'
b=a+'/wiki'
c=1000
tenSeconds=10*c
eightSeconds=8*c
# exception handler impl
def bar: sys.exit(-1)
# exception handler
crap_exception_handler=bar
config=[a,b,c,tenSeconds,eightSeconds,crap_exception_handler]
]]]

beats XML or properties files hands down.

je suis etudiat ; et cherche un déffinition égénérale pour unix/lunix , mait par détait MERCI

'Configuration files need a clean syntax for building data-structures, something that Java lacks' ... DING! You hit that nail on the head.

je suis etudier en 4anne en télécommunication et cherche un documentation pour theme "les imagerie satellitair " pour cette anne

MERCI

Previously: Harbour Bridge Light Show 2005

Next: Death by Email