More Musings on the HTML Model and the GeoWeb

In my last post, I mused about the state of GeoWeb standards and wandered off into a discussion mostly on findability and linking between different files. I've been thinking more about the HTML web and how we use it as a model for what we call the GeoWeb.

The HTML web famously starts with Tim Burners Lee, Robert Cailliau, and their famous 20 tags, 13 of which we still use today. HTML sprang out of SGML, the Standard General Markup Language, but was far simpler, and, well, usable. We all know that the web took off like a rocket, and now the Web is synonymous with the Internet in the eyes of many people. HTML is the vehicle, but as developers know, it is only a part of web. Granted, it's the part that the other parts all depend on, but here's a partial list of the technologies without which the Web as we know it would be fundamentally different:

1) HTML

2) HTTP

3) JavaScript

4) XML

5) JSON

6) Flash

7) CSS

OK, Flash is controversial, I'll give you that, but you have to agree, the Web would be really different without it. Some of you would say better, but very different. Of course, there are other technologies people could put in there, like ASP, PHP, Python, etc. My point isn't the specific technologies, though I'll talk about JavaScript in a minute, but the fact that any developer could come up with this list. I'd like to compare that to a list an enterprise apps developer might come up with:

1) Java

A much shorter list. Again, you could argue about the content of the list, but the fact is, for many other domains, a developer can learn one language, one piece of technology, or perhaps two, and that's it.

So the web is different. It is hard to imagine a serious web designer now who doesn't know JS and HTML and probably PHP or Python or some other server-side scripting language. Maybe Flash instead of JS, but you get the idea. I call it the HTML Web because without HTML the rest couldn't work. But, it's hard to imagine a serious web site without using these other technologies.

I was thinking about this because I am asked all the time, why doesn't Google add JavaScript or some other scripting capabilities to KML. Of course, we no longer own KML, we gave it to the OGC, so we can't just "add" something to KML, aside from our own language extensions. But the question shows that there is a fundamental desire on behalf of developers to have that functionality. Serious GeoWeb developers learn a variety of technologies too. For a basic Google Maps mashup (or Bing, or Yahoo! Maps too), you need at least HTML, CSS, and JavaScript. More complicated mashups will use KML, GeoRSS, or GeoJSON, maybe Flash instead of JS, and wait. Notice the first one of those technologies, HTML. Still fundamentally, the GeoWeb relies on HTML. Sure, with a GeoWeb browser like Google Earth, you don't need HTML, though you can use it in the description balloons. But most mashups require HTML as the carrier.

So for the GeoWeb, we've learned the lessons of the HTML web. The question I'm asking, I guess, is, is this the right thing? Is building on the HTML model, with it's confusing amalgam of technologies, many of which don't work easily together, really the best model for the GeoWeb. I don't have the definitive answer to that question, but I think it's worth asking. Would it be better if we had a single technology to create Maps and distribute them?

OK, I have a preliminary answer, yes it would be better to follow the HTML model, and have an amalgam of technologies than to be locked into a single one.