Spare us humans from XML

XML appeared in 1996, was refined during 1997, and was standardised in 1998.

I remember a lot of excitement about it at the time, from managers who imagined it would solve all their data portability problems. I was conscious of some of this enthusiasm before I really looked at the format.

When I did, I thought


But it wasn’t as bad as all that. The idea of XML was to standardise the lexical layer for a file format, helping to cut down on the programmer’s natural tendency to just bodge something up when saving and worry about loading later.

It worked, and it made and still makes a tolerable format for all kinds of things—within limits. Of course it’s horribly verbose and slow to parse, but hey, it compresses well. And you still don’t get reliable interchange unless you have a known storage structure on both sides, something a series of increasingly complex helper standards evolved atop XML to help you with.

One thing XML never was, though, was nice for humans to read.

At the time this seemed OK, because it obviously wasn’t intended to be for humans. We humans would never be editing it. We’d only ever be looking at it through filters and lenses and programs that knew what it really meant. We’d never actually have to see the format.

Fifteen years later, here I am sitting looking at

        <isset property="tested.project.dir" />
        <property name="tested.project.absolute.dir" location="${tested.project.dir}" />
        <xpath input="${tested.project.absolute.dir}/AndroidManifest.xml"
            expression="/manifest/@package" output="tested.manifest.package" />
                <isset property="tested.manifest.package" />

Oof! Enough of that.  But that’s Android development: of course that’s for robots.

Windows Phone is for people, though. How about:

    <shell:ApplicationBar Opacity="0">
        <shell:ApplicationBarIconButton Text="previous" IsEnabled="False"
            IconUri="/Shared/Images/appbar.left.png" Click="PreviousButton_Click"/>
        <shell:ApplicationBarIconButton Text="page jump"
            IconUri="/Images/" Click="JumpButton_Click"/>
        <shell:ApplicationBarIconButton Text="settings" IconUri=


These aren’t pathological examples that I’m having to grub around the internals of some graphical environment in order to find. That last one, for example, is copied verbatim from a beginners’ programming book for Windows Phone 7.

I’d far, far rather see developers use XML than go back to rolling completely unique file formats for every application. But surely by now there are enough widely-supported data representation languages—formats that simplify the presentation by standardising object relationships as well as lexical details, such as JSON or RDF/Turtle—to cover the majority of situations in which humans may end up having to edit something?

Crap Things from Big Companies

No Refunds

Bogus Pokemon evolves into iTunes smash hit; 2012: The Year Scam Apps Killed the App Store — As someone who used the Android Market before either of Apple’s app stores, the thing I found most mind-boggling about Apple’s was the lack of any apparent way to get a refund if an application doesn’t work.

It fascinates me, although not in a good way, that the world’s most successful software store should be one in which normal consumer rights are effectively suspended. (It is possible to get a refund, from Apple rather than from the individual app developer, but by all accounts it isn’t easy.)

This really pains me as a developer, as well: if any of my customers are unhappy, I want them to get their money back immediately. It’s fair, and because it creates a better impression, it’s good business as well.

For developers, it’s both a logistical benefit and the curse of the App Store model that you generally have no contact with your customers. But not long ago I had an email from someone who had bought an app of mine from the Mac App Store and was disappointed with it—it didn’t do what they expected. What can I say? There’s nothing I can do to help you. That feels wrong: it is wrong.


Sad Lion

Mountain Lion may drop support for older Macs (The Verge)

It appears that OS/X 10.8 won’t work on many Macs more than about three years old.

Apparently this is a consequence of cleaning up its 64-bitness, and so losing support for 32-bit EFI bootloaders. (The 10.7 release already dropped support for 32-bit CPUs, such as the Core Duo used in the earliest Intel Macs.)

If this applies to the eventual release as well as the developer preview, that means it won’t run on any of the Macs available to me—not on either of the Mac Minis on my desk at work, nor the Mini I use for development at home, nor my wife’s MacBook Pro, nor indeed my mother’s MacBook.

(I’d better get ready to update this OS/X build compatibility page.)

Really though, this post is an excuse to include a picture of a Sad Lion drawn by my son.


Hard edges, small keys

Joanna Stern reviews the MacBook Air as a Windows laptop.

I enjoyed this—I’ve considered in the past whether the MacBook Air would be a suitable laptop for me even though most of the time I don’t run OS/X. (Conclusion: probably not any more, though it might have seemed that way once.)

She does highlight the thing I’ve always found most painful about the MacBook Air and MacBook Pro: that vicious sharp edge along the front. (sucks teeth in recollection of past pain)

But she likes the trackpad. I’m not keen on the Mac trackpad, finding it too easy to operate by accident and too hard to “click” reliably. Perhaps it’s just that the PC vendors’ attempts at the Crazy New-Era Big Trackpad are worse.

The review is of a machine with a US keyboard, so although there are some quibbles about keyboard layout, there’s nothing to compare to the difficulties presented to the UK programmer—most obviously the lack of a hash sign (#) anywhere on the keyboard, and the tiny, tiny Return key (right).

The Return key is hard to hit on every current Mac and MacBook UK keyboard, even where there’s plenty of room to spare in the chassis.

It just feels gratuitously punitive to me. And that’s surely the way it is, given that Apple did it perfectly well in their older keyboards. They do know how to make a big Return key. They have learned the technology. They just think it’s not quite appropriate to accommodate whims like that from us.