Atom’s back

Someone was working over the weekend – RSS functionality has returned to Blogger, and the feed definitions are being updated correctly.  Or at least as correctly as the Blogger style sheet will allow.  One monolithic line of code makes it difficult to be absolute about things like this.

I may be old-fashioned (OK, there’s no doubt – I am old-fashioned) and I certainly prefer human-readable text.  What does it cost to put a few line breaks and tab characters into a text file?  In this particular case, about a 2% increase in file size, which should not be a deal breaker.  For that, you get a text file that can be understood, and even parsed by the human eye

Perhaps you might argue that these things are not intended to be read by humans: their function is simply to define a set of data for a computer to work with.  But I would respond that we should not lose sight of the need for people to understand what computers are doing.  OK, there are some time and space-constrained operations where maximum efficiency is needed, but XML code is not amongst these: by its very nature, it’s a form of text, and doesn’t aspire to terribly efficient operation.  There’s a tremendous amount of repetition, unnecessary descriptive strings, and sheer bloat in even the most tightly structured XML file.  So why not add that extra 2% and make it readable?

If you want that space back, do something like parameterise the contents.  For instance, my atom.xml file contains my name repeated many times over – why not reduce it to a simple variable defined at the start of the list? 

If the standard insists on fully expanded strings, then go all the way and just add those two or three extra characters per line and make them proper lines.  Apart from anything else, this ensures that mistakes can be picked up more easily – but I must admit, the original mistake with the generating code that caused empty XML files to be created wasn’t going to be found very quickly from a blank output file.