Programming Jabber

XML-Based

Arguments abound for and against XML in the arena of data representation. XML is suited extremely well to Jabber, which is suited extremely well to XML. There are many reasons for this.

The alternatives for representing data in Jabber are binary and ASCII text. Binary? Well, perhaps binary data is more space efficient, but where is that advantage in the general scheme of things these days? Near the bottom of my list, anyway, especially as it’s always at the cost of readability. ASCII? Well, yes, of course, ASCII is human readable, but since Jabber data flow consists of a series of conversationalchunks—independent constructions in their own right—we need some sort of boundary mechanism to separate these chunks. XML affords us a very nice way of packaging individual chunks of data and giving their content meaning and context. These individual chunks of information have structure too, and this structure doesn’t require any fixed-length madness either; XML allows the chunks, or fragments, to bend and stretch as required, while still retaining their meaning.

This flexibility also comes in the form of extensibility. It’s straightforward to add distinct “extensions” to a fragment in a way that does not compromise the integrity of that fragment and provides a structure to the extension added.

So why reinvent the wheel when there are tools that can be taken off the shelf to parse the data? There are many tried and tested XML libraries out there, and to be able to receive ...