KML is an XML language focused on geographic visualization, including annotation of maps and images. Geographic visualization includes not only the presentation of graphical data on the globe, but also the control of the user’s navigation in the sense of where to go and where to look.
OGC seems like thriving ecosystem, under their OpenGIS® brand. OGC has a strong liaison with ISO TC 211 Geographic. information/Geomatics) and having been transposing their standards across when stable. OGC has a strong government and specialty-vendor influence. (Geomatics is not a word I had come across until today.) The OpenGIS® Reference Model (PDF) seems a good place to start figuring the GIS standards out. I liked the statement in their FAQ answering Q: How do you compare the action of the OGC with that of the ISO and other standards organizations?:
A: The standards tracks of OGC and ISO are fully coordinated through shared personnel and through various resolutions of ISO TC211 and OGC. They are often complementary and where they overlap, there is no competition, but common action (e.g. in the geometry model). OGC provides fast-paced specification development and promotion of standards adoption, similar to other industry standards consortia such as W3C, IETF, and OMG. ISO is the dominant de jure international standards development organization (SDO), providing international government authority important to institutions and stockholders. Through OGC’s cooperative relationship with ISO, many of OGC’s OpenGIS Specifications either have become ISO standards or are on track to become ISO standards.
The OGC process includes a 30-day window for public comment. (The ISO process has at least 6 months period for National Body comment, and sometimes much more.)
What I found interesting about the KML spec was that it represents a connecting point between two different standards ecosystem: in particular with the Khronos Group which is
a member-funded industry consortium focused on the creation of open standard, royalty-free APIs to enable the authoring and accelerated playback of dynamic media on a wide variety of platforms and devices.
The Khronos group is that now maintains Silicon Graphics’ OpenGL graphic system, and is strongly influenced by the mobile device industry. For my own research, I made a little diagram to try to express the Khronos ecosystem (and to experiment whether there was much point in using UML for this kind of thing.)
To summarize the diagram: lets concentrate on three kinds of standards: XML file formats, Rendering APIs for 2D or 3D graphics, and Delivery or Codec APIs which provide session or lower-level services.
From the bottom left, we see that OGC KML uses Khronos Collada Digital Asset and FX Exchange Schema. This is a Sony-derived technology for transporting 3D assets between applications. It used by 3D modeling software. In turn, Collada can be considered to some extent to be a serialization of OpenGL data. Of particular interest to XML-ers is OpenVG which has as a design goal of supporting SVG Tiny 1.2 :
OpenVG™ is a royalty-free, cross-platform API that provides a low-level hardware acceleration interface for vector graphics libraries such as Flash and SVG. OpenVG is targeted primarily at handheld devices
The diagram has a cluster of various vector-related XML (or soon to be XML) formats: the SVG family of SVG and its two profiles SVG Basic and SVG Tiny, and SVG’s near relative the ODF drawing language. What struck me is that the ease of implementation of a standard is really related to the function points (and tooling up, etc) of a complete implementation, and this in turn is directly related to how close the underlying libraries are to the markup language.
I would call OpenVG a glue standard, which is where you have one or more existing underlying standard API which has grown under its own steam, and one or more standard formats, and to ease implementation you make an intermediate API based on abstracting the various standard’s features. In industries where there are multiple entrenched document formats which have a lot of similarity, these kinds of glue standards are one practical way forward.
It is often the case that where you have a problem with obstinate multiplicity of standards, the way forward is not by insisting on a single standard, but in aggressively supporting plurality in such a way as to neutralize the problem. I’d see the XML encoding header (and, indeed, Unicode itself and perhaps SGML/XML too) as an example of exactly the same strategy.
I don’t expect to see it, but it is interesting to consider whether the same approach would make sense for ODF/OOXML harmonization. To what extent is “harmonization” an assumption about how to achieve a particular desired result (in particular, more guaranteed interoperability or less gratuitous non-interoperability) rather than being an outcome in its own right? If the outcome desired is interoperability, then that could also be addressed by having everyone support everything (to reduce my point to the absurd): and that tactic can only be prosecuted by making implementation as easy as possible (by having APIs that are as close as possible to the various file formats.)