As I mentioned in my previous post, the Agile Geography thread of OGC’s OWS-5 testbed is going to be more open. Therefore, I’ll summarize the two-day meeting we had earlier this week in Reston, VA, and where the current thoughts on KML 3 stand. However, keep in mind these are just the notes from the meeting and still in very active discussion (technical committees have telecons once per week, so we’ll be talking a lot).

Committee example documents will be posted on the OGC Network page in the “Mass Market” (now known as Agile Geography) section. The KML page lists current examples that we’re working on, so you can follow along there in addition to this blog.

First, the title of this post is “KML 3″, however, it’s not clear yet if this will be 3, or 2.x. Really, the point is moot, and probably in the end be more reflective of how much a change this first revision is. So don’t digress too much on my use of “KML 3″.

Breaking down to build up

One of the primary topics discussed, and nominally agreed upon, was how to define KML such that developers can build capabilities for certain parts of KML without having to implement support for the entire specification. This is important based on the OGC’s normal method of operation and use. By providing a spec, developers are expected to implement that entire spec and then get a stamp of approval that they meet the spec requirements. Then, users of the clients or libraries can feel confident that the features they expect are in fact implemented, and implemented correctly.

KML has a large number of features, from simple geometry markup, to 3-D models, image pyramids, lookAt, and so on. Expecting all KML clients to implement all parts is unreasonable. The simplest demonstration of that is comparing current KML clients: mobile, web map, 3D ’spinny globe’. There are certain aspects of KML that make sense on some of the clients, but not on others.

For other formats, such as GML, the OGC has first defined a full super-set of the spec, and then defined profiles, which are defined subsets of the full spec. From my (and the committees) perspective this can be confusing to developers and users because the first time they go and read up on GML, they get the 400+ page specifications document, balk, and walk-away (or have mild breakdowns).

Instead, for KML, we’re planning on defining a core minimal set for KML, and then put the other functionality into modules. Applications and clients can then use modules that are appropriate to their application.

To illustrate, a simple phone may just want locations and some simple metadata (or attributes) of that location. For example, nearby restaurants and their opening hours. As the client (or library) becomes richer then additional modules can be implemented. A Weblog extension may support styling (icons, line colors) for publishing KML from posts.

So, applications will be able to simply define what modules they support so that users can clearly understand the type of functionality they can expect. In addition, these libraries and applications can achieve OGC verification by implementing the defined feature set in the modules they use.

So what’s in each of these modules? I’ll discuss each of them in successive blog posts (to make them all more readable and keep any discussion grouped together).