The instant Google Maps appeared, a lot of us knew right away that we’d never use MapQuest again. Google’s mapping and direction-finding service
is a stunning improvement.
The maps are gorgeously readable, and they fill as much of the screen (or the printed page) as you give them. Scrolling the
map works in the most natural way, by dragging the image. The mapping service dovetails with local.google.com, which finds
businesses by city or ZIP code. In direction-finding mode, each step along the route offers a link that, when clicked, pops
up an enlarged view of the intersection.
What rich and smart client technologies enable this magic? DHTML, JavaScript, CSS, XML, and XSLT.
As is the tradition when Google launches a new service, curious hackers immediately took Google Maps apart to see how the
magic was done. The best early analysis came from Joel Webber, who worked out the details of image tiling, dynamic updating,
and route plotting (infoworld.com/2533). Among other interesting discoveries, he found that the application uses the browser’s
built-in XSLT engine to transform packets of XML received from the server into search results, displayed as HTML.
This explains why Google Maps supports only Internet Explorer or Mozilla-based browsers. The others, notably Safari and Opera,
lack built-in XSLT processors.
Commenting on Webber’s post, one reader noted that no W3C standard defines this capability. As is the related XMLHttpRequest
object, which enables the browser to programmatically fetch XML from the server and parse it, the built-in XSLT processor
was a Microsoft innovation that was later copied by Mozilla. Safari and Opera do support XMLHttpRequest, by the way, which
is why they can run Google Suggest, the experimental version of Google’s search that dynamically expands partially typed queries
into lists of choices.
The W3C can bless this approach or not, but with Google Suggest and now Google Maps, Google has thrown down the gauntlet. The modern browser is an XML-aware client. Savvy Web developers
have known about these features for a while, but now Google has legitimized them and pushed them squarely into the mainstream.
My guess is that we’ll see an explosion of pent-up creativity as more Web developers discover, and begin to exploit, the full
power available to them.
But wait, there’s more. If you append the term “output=xml” to any Google Maps URL, the server will send back an XML packet.
APIs? We don’t need no stinking APIs. In 20 minutes I was able to build a proof-of-concept app -- made from snippets of HTML,
JavaScript, and XSLT -- that accepts city names or ZIP codes and displays information about local businesses. (Unfortunately,
the XML feature has since been disabled.)
I didn’t need to publish any new services to do that. Because the app uses the W3C’s hosted XSLT transformer in tandem with
Google Maps, I was able to “deploy” it in any browser simply by posting an HTML/JavaScript snippet to my Weblog.
Google Maps’ killer integration hook is the latitude/longitude data woven into its queries and responses, which can tie into
any geo-aware app. We don’t yet know how Google plans to control or monetize this capability, but it shows what can happen
when all the pieces of Web technology come together in the right way.