[via TechMeme]

Everybody loves to bash XML namespaces, but this essay is the most careful and dispassionate I have seen to date. You should read the whole thing if you deal with XML (or even if you just like to read the product of clear thinking).

Here’s a key quote:

I would claim that the aspect of XML Namespaces that causes pain is the URI/prefix duality: the thing that occurs in the document (the prefix + local name) is not the same as the thing that is semantically significant (the namespace URI + local name). As soon as you accept this duality, I believe you are doomed to a significant extra layer of complexity.

Nothing new here, but its being in the Times means my mom reads about it, and yours might too.

Recalling that my Android G1 phone has GPS, I installed MyTracks from the online Android apps store.

Yesterday I took both devices for a spin together, and they recorded the same paths (within a few feet), with more differences while walking or indoors than while driving. Today I tried a comparison bike ride, which the Android app flunked by only seeing satellites intermittently from the pocket where I was carrying it. I’ll have to try again with the phone away from my body.

Assuming that works, the real difference between the two devices is cultural.

The Garmin is a classic device from a hardware company. It’s marketed to runners, bicyclists, boaters, hikers, and other outdoorists. The battery compartment, display, and data ports are protected by rubber fittings: you can use it in the rain. On the other hand, the software sucks, and it’s hooked to a business model that makes maps from Garmin the only ones you can install.

The G1 is an open smartphone with a GPS receiver in it. The MyTracks software is pretty good, and the mapping comes from Google Maps on the device. This is the classic computer platform style: the platform vendor stands back and lets third-parties compete to make the best app in each niche. On the other hand, the hardware is Just a Phone: as suggested above, I have my doubts about the antenna, and there’s certainly no special provision for the elements.

Historical evidence from analogous market situations strongly suggests that the open platform model will win. Hardware-company culture will suck up energy by trying to segment the market with too many SKUs (have a look through Garmin’s web site to see what I mean), and software improvement will always be an afterthought as they try to move boxes through channels as diverse as Best Buy, Crutchfield, REI, and auto parts stores.

Android GPS software vendors, on the other hand, only have one channel to worry about: the app store. They only have to worry about being able to clearly state which devices their apps run on. This frees them to concentrate on acquiring and making interesting use of GPS data. They have no physical boxes to move (the hardware vendors take that risk).

On the hardware side, the niche for rain-resistance can be satisfied by accessory makers making rubber sleeves for entire devices or by hardware vendors wrapping rugged housings around electronics designed and built by another company that knows how. In neither case does the hardware outfit need to know that the customer wants to do GPS: it’s sufficient just to know that they anticipate getting rained on for whatever reason.

The same arguments apply to iPhone, of course, but I don’t have one of those to write about.

Brad Fitzpatrick says:

What does product liberation look like? Said simply, a liberated product is one which has built-in features that make it easy (and free) to remove your data from the product in the event that you’d like to take it elsewhere.

Note the emphasis on free and easy. Online services tend to stop at possible, which falls short of easy by the proverbial Simple Matter of Programming.

Facebook, for example, has a programming interface for each kind of information you store that lets a Facebook application extract it into a file. It’s possible for me to write an application that does so for everything I have on Facebook, but that isn’t the same as having a predefined procedure that archives my entire Facebook presence into a standard file format that most social networking sites can import from.

Good luck to Google in this effort! I myself would go further in asking that the entire behavior (as well as data) of my social-network presence be standardizable and portable, as Ramón Cáceres [disclosure: personal friend] and his collaborators are proposing with their work on virtual individual servers.