There are definitely arguments about why HTML has problems – but it’s obviously been incredibly successful, and particularly for the reason that you and I agree on – common tools.

It was also flexible enough, open enough (view source) and discussed openly to evolve as necessary.

Thanks for the excellent overview.

I like your idea of modules. It is practical and follows the approach many GIS manufacturer’s have pursued – namely the basic platform with modules added dependent upon complexity of user needs. It is a flexible approach and avoids all-in-one confusion.

I guess if there was a GeoBrowser then spatial would be ’special’ hmm?

Keep up the good work.

Andrew: How would you rate either the Poly9 3d or Ptolemy 3d browser globes & their APIs as candidates for widespread browser globe enablement? Poly9 would get a big ding for not being free/open, but aside from that…

That was actually why I wanted to do modules, so everyone could do “KML basic” and maybe KML styling, but leave off on more complicated, solution specific extensions (kind of like or tags in HTML).

Mojo – I agree there are going to be GeoBrowsers, and Browsers with Geo. MiniMap sidebar, a Firefox extension, is one of the better examples of this. I also wrote some GreaseMonkey scripts (GreaseRoute) to pull up Adr markup and show MapQuest directions embedded in the page. You see the same thing happening even in things like Apple Mail or iCal that detect addresses and show a map.

I think there’s a tension between trying to get format X to do everything and bolting on a technology that is specialized for doing it. It certainly has come up, this idea of allowing JS in KML. I think at this point there are two drags on that:

1) The lack of “geo browsers” which, as Mojo points out, today consists of only thick clients. Although much of that thickness comes from the imagery downloads, of course. Better integration with browsers would help (Google Earth Plugin maybe?)

2) The lack of standardization among geo browsers. Right now, Google Earth is the gold standard of how KML is rendered. Ideally, like a standard web browser, all browsers would support all tags, even if there’s some variation among how they implement. Bolting on an additional technology would slow that standardization down even more, and if you think the discussions on how IE and FF differ in JS engines, just wait for the geo browser wars.

The Google Earth API can be seen as an alternative. It is essentially a JS implementation of KML. But it doesn’t get at your point.

So what is the common tool that resides in the browser that could link to a MIME type to open any of the current standards or the mythical middle standard. So when the browser detects a KML, GeoRSS etc. file what would it enable? Seems it would be a big map provider cage match – proprietary Google, Bing, Yahoo, ESRI – open source OpenLayers, ModestMaps, MapGuide. It is the KML MIME type issues multiplied.

I download Google Earth and my KML opens there. Then I download ESRI’s AGX and it changes the MIME type so my KML opens there. Except now I’m not downloading anything, the app is resident in the browser. So is it Google cutting a deal with Firefox and making it default in Chrome. IE* would obviously be Bing and I guess Safari would be up for grabs till Apple cut a deal or did their own. All this seems to move away from the idea of open standards and towards vendor lock-in. Maybe I’m misinterpreting the common tool concept entirely but to play devil’s advocate there appear to be dragons in yonder ocean.

I did a quick test of point data in Finder: http://finder.geocommons.com/overlays/14326 and KML was 4.8MB compared to 1.1 MB in JSON. I guess all those brackets take up space when you are doing complex geometries though.

and Mano – I agree that HTML has been interesting. HTML is very simple – but Javascript gives it a varying complexity that was missing. I can add behaviors and complex relationships between DOM elements using JS. And then you add CSS for styling, embeddable Flash/Silverlight/Canvas, and you actually have a very wide-ranging set of ’standards’ that let developers do everything from a simple “My Homepage!”, to blogs, to web applications that all render in browsers.

What really made these all work was the browser – a common tool that most users didn’t have to care about what format/technology was using, yet developers settled on common standards to get broad browser support (goodbye ActiveX!)

The processing concept is particularly interesting – Javascript having been the quiet giant for many years, but not HTML5 actually offering workers and other processing pieces. Do GeoWeb formats need something similar?

One thing I keep coming back to is the example of the HTML Web. There was no middle ground in the HTML Web. XML was supposed to be that but HTML + JavaScript remain the mainstays of web pages. Complexity was added gradually, not in a single file format.

Now, it remains to be seen if the HTML experience is one that is a useful model, or if we can actually learn from those mistakes.