I got a Palm Z22 for Christmas, to replace my old monochrome Palm Vx. I know that most people have moved beyond Palm, but I like a PDA that’s very small and simple. I make heavy use of Laurie Davis’s outstanding free CoPilot app, especially when I’m in the pilot lounge at some distant airport and need to figure out a new route or recalculate time and fuel for a new upper wind forecast.
I love a lot about the Z22, but its one huge, ugly wart is Graffiti v.2, which I had never encountered before now (I’m not sure when it first came in). I have known Graffiti v.1 for years, and can enter it as easily as I touch type. Now, a handful of letters have changed rather arbitrarily, and I keep having to bring up the little virtual keyboard. I’m working on learning the new shapes, and I acknowledge that they would have been better choices for v.1 all those years ago, but what real benefit came from fixing them after the fact? A few engineers might have satisfied their perfectionist aesthetic sense, but thousands of existing, experienced Graffiti users were no doubt gratuitously annoyed, just as I am now.
Let’s not do the same thing with XML and other specifications — sure, we made mistakes writing them, but unless the mistakes are huge, why annoy millions of users with tiny, backwards-incompatible changes? We were forced to create SAX 2.* to support the XML Namespaces specification, though we did our best to maintain backwards-compability, even where we could have made SAX more elegant with a little tweak here and there — the same thing happened with the DOM people. For XML itself, I agree with Tim Bray that it would be convenient to write a specification that combines XML 1.*, XML Namespaces, and the XML Infoset into a single document (as long as nothing else changed — I wouldn’t follow Tim in removing DOCTYPE, as annoying as it is), but otherwise, my motto for specifications is long live v.1!