RealityPrime

Frank Taylor of the fine Google Earth Blog writes (first link goes back to my previous post):

Changes to KML – to enable some of the new features in GE 5, Google had to make extensions to the standard KML. However, some have expressed concerns that Google has done this, saying it will be harder for other companies to adopt the standard if Google changes it. Google has heavily documented the changes, they say they’ve used provisions provided by the KML standard to make changes. And, they’ve updated libkml for the new features. I would expect they would like to see these new extensions become a part of the standard in a future update.

My concerns are not about extending the standard — standards are made to be improved over time. I’ve also not accused Google of violating protocol by adding extensions or using namspaces or of providing insufficient documentation after the fact. I hope I was amply clear about those points, and that it needs no further clarification.

I should also add that my only aim here is to see more companies, including Microsoft, more readily adopt KML, not just for import into silo’d apps, but to build a living breathing geoweb. I went through a lot of pain to write KML’s crappy unnamed predecessor at a time when it was not a very safe or popular thing to do. The code and schemas may be new, my power to affect things is greatly diminished, but the goal remains the same, and I’d imagine that all of Google shares it by now.

However, here’s my concern with some of the more defensive comments I’ve read. As I understand it, Google proposed this new OGC MMWC fast-path last fall and the body accepted, including Microsoft, btw. Perhaps it’s the best path, given how hard it is for OpenGL, for example, to advance collaboratively. I’m sure it’s at least logical and can be defended on the merits. But implying it’s the only possible path or one the mysterious OGC dictated against Google’s wishes just seems wrong to me, and not a very effective way to meet criticism. Own the decision and convince people, if you want to convince people.

The kind of path that I would personally recommend, not that anyone asked, is one in which companies seeking to improve standards (in general) might first put out their ideas, as public requests for comment, have a review period for changes before they’re launched, and unless it violates some vital corporate security interest, just be more open about the process, which will hopefully put their collaboratios/competitors more at ease. The other downside of the current approach is that there’ll be lots of new KML that will need to get tossed, partially deprecated, or somehow converted whether or not the new features get debated and adopted. Worse yet, if three or four companies want to add new features. The secrecy doesn’t seem necessary, given that lots of people are already on the same page and happy to help.

I’d love to hear an argument as to why RFCs won’t work, or why this new KML documentation, for example, can’t be released before the new version of the app comes out even without asking for comments. I mean, I wrote about the new ocean data last spring, but yet it still made a big splash (pun intended) on official launch this week. Few people care about this stuff until it’s released.

Let’s just leave it at this deep ponderable thought: if you swapped ‘Microsoft’ for ‘Google’ in this scenario, what would the slashdot commentary have read?

Microsoft unilaterally alters ‘open’ geospatial standard to support proprietary new features, blames standards body for process.

Google should be greatful, in many ways, that it doesn’t have Microsoft’s baggage to carry around. But why start to collect?

Tags: Articles // Add Comment »