My Fascination With XML – Coming To An End?

My first exposure to XML was when I began using JUMP to work with geospatial data encoded in GML 2.0. I was fascinated by this way of storing information. It was readable by both humans and computers, and it imposed a hierarchy on the document that encapsulated the data. Now that I’ve been programming for a few years I can look back on this fascination and identify the root causes.

[1] I had a terrifying fear of binary data. Binary data was shrouded in mystery and confusion.

[2] I liked the idea of an “open” file format that could be interpreted and used by so many different programs. This idea wasn’t as common at the time then as it is now, and I had hit the wall of “secret” file formats in my programming aspirations several times. Autodesk’s DXF format was the closest thing I had seen to an open file format, at least in the geospatial realm, and anyone who has worked with DXF files knows that there not that “human-readable”.

My interest in GML inspired me to learn about XML and my fascination began. I started to view XML as the solution to every programming problem. Data storage, object serialization, configuration files, data transfer formats…

How far did this fascination go? I came up with a simple subset of XML called 2SimpleXML and I’ve written a complete Pull-Parser for the sub-set from the ground up, using only the standard Java libraries. The parser is functionally complete, and only needs some more bug squishing and unit tests.

That’s a pretty serious fascination.

I questioned this fascination for the first time when I started dabbling with Python and posted some questions on a Python users list. I was quickly chastised for my Java habits, one of which was trying to incorporate XML into everything. (Python isn’t a compiled language like Java, so you can actually write and store code in text files. This means you can accomplish a lot by storing Python code in text files, instead of XML.)

I’ve begun to question that fascination some more. I've overcome my fear of binary data, for one thing. This due in large part to this book:

http://www.amazon.com/Code-Language-Computer-Hardware-Software/dp/0735611319

It explains binary data in terms most common people can understand, and I highly recommend it for new programmers, even if they're using a high-level language like Java.

I’ve also seen alternative means of text-based data storage in Linux. (The configuration file for the X-Windows system is one example.) I’m also looking for something that would allow for the construction of simpler parsers. (Now that I’ve seen how complex an XML parser is.) I’m really looking for a way to streamline the process from text file to Java object.

I’m not the only one who’s questioned the validity of XML as a “solve-all” programming solution. A Google search for “XML Alternatives” turned up a link to a list of XML alternatives:

http://www.pault.com/xmlalternatives.html

I’m going to experiment with some “flat file” text based storage. This will give me a chance to see if it fits my programming needs better than XML. I’m going to start by designing a system to store Feature and Geometry objects in OpenJUMP in text files. This will be the foundation for a data-caching system I need to implement in the new PostGIS Plug-In for OpenJUMP. (This data-caching system will store features retrieved from a database or other remote data source to allow manipulation of the data from these sources in the event of a connection loss.) If this system works, I’ll use it in my RAM-Independent Feature DataSource for OpenJUMP, and I may take a look at improving OpenJUMP’s project file.

I’m not totally abandoning XML, I’m just thinking about alternatives. In the end what I really want is what I had in GML 2.0. An easy to read, easy to interpret, and simple way to store Geospatial Data. Perhaps I’ll have to change the name of LocusXML to LocusText or something like that. :] We’ll just have to see.

I am beginning to realize, XML may not be that fascinating after all.

The Sunburned Surveyor