KML 3 Kick-off, Module: Core
The KML Core module includes the minimal subset of KML that would be expected for any implementation. Currently the elements of KML that would exist in Core include:
kml, Document, atom, Folder, Placemark, Link (and NetworkLink?), ScreenOverlay, TimeStamp, Geometry (see below)
This list was derived from the current KML 2.1 tags and signifies the general concepts we’re hoping to have in KML Core - allow a user to express location, time, and possibly link to another KML document or service. In addition, providing the current Atom support allows for attribution and other interesting things for linking to HTML and GeoRSS.
Geometry Markup
A couple of nearly given plans were laid out for for revisions to KML. The first is the markup of the geometry. OGC is well known for GML, and there are many tools that publish and consume GML. Having yet another geometry markup seems to be redundant and confusing. Therefore, KML 3 will use a minimal version of GML, GML Simple Features Profile. You can follow that link to the specification - but good luck finding an actual simple example or description of what it is.
To summarize, here is an example of a KML 2.2 point, and a GML Simple point:
<Point><coordinates>lon, lat[, alt]</coordinates></Point> <gml:Point><gml:pos>lat lon [alt]</gml:pos></gml:Point>
It’s mostly a simple markup difference. There is also the possibility that the gml: namespace prefix would be dropped and just be part of KML. GML provides for specifying the coordinate reference system (CRS), but for KML it is currently assumed to be EPSG4326 - that is to say, what you probably normally use for your map applications and off of your GPS receiver. Later I’ll put up a full comparison between all the current KML geometry markup and its comparable markup in GML.
Being a fan of simple markups myself (see GeoRSS Simple), as a developer I also understand that having a single (and simple) markup makes implementation and maintenance easier. KML already had embedded tags for locations and used a GML 2 like markup - so switching to GML 3 is fairly straight-forward.
My name is 
August 7th, 2007 at 12:26 pm (#)
[...] This is especially important using the concept of modules that allow KML implementations to only include pertinent areas of functionality. If a mobile phone client want to display markers, but isn’t going to use Metadata it shouldn’t be required to implement the complex Schema parsing just to get at the markers. [...]
August 9th, 2007 at 6:47 pm (#)
Does this mean a future kml document can be “subscribed to” by current Atom-feed readers? Or would the feed readers need to be updated?
August 9th, 2007 at 7:31 pm (#)
@Charlie - see my post about GeoRSS and KML. KML itself wouldn’t be “subscribable” - as KML is just a document format. However, KML would prescribe a way to designate a “feed” that included updates to the source of the KML document. That way, you could download a KML document that included the current data, and then subscribe to the GeoRSS (Atom) feed that would publish updates to add onto the collection of geographies in the KML.
Feed Readers could decide to implement KML parsing if they wanted to, but more useful would be if they supported GeoRSS parsing and display.
August 14th, 2007 at 10:07 am (#)
[...] So far I’ve covered the modules: Core, Styling, and Metadata. Another important one is the Services module. This defines how KML can link to external resources like OpenSearch, WFS, WMS, or others. [...]