OGC® 08-125r1

Open Geospatial Consortium Inc.
Date: 2009-02-04
Reference number of this OGC® project document: OGC® 08-125r1
Version: 0.6
Category: OGC® Best Practices Document
Editors: Tim Wilson, David Burggraf

OGC® KML Standard Development Best Practices

Copyright notice
Copyright © 2009 Open Geospatial Consortium, Inc. All Rights Reserved.
To obtain additional rights of use, visit http://www.opengeospatial.org/legal/.
Warning
This is an OGC® Best Practices Document. It is not an OGC® Standard and may
not be referred to as an OGC® Standard. It is subject to change without notice.
However, this document is an official position of the OGC® membership on thisparticular technology topic.

Document type:Best Practices Document

Document subtype:Best Practice

Document stage:

Approved

Document language:

EnglishLicense Agreement
Permission is hereby granted by the Open Geospatial Consortium, ("Licensor"), free of charge and subject to the terms set forth below,
to any person obtaining a copy of this Intellectual Property and any associated documentation, to deal in the Intellectual Property
without restriction (except as set forth below), including without limitation the rights to implement, use, copy, modify, merge, publish,
distribute, and/or sublicense copies of the Intellectual Property, and to permit persons to whom the Intellectual Property is furnished to
do so, provided that all copyright notices on the intellectual property are retained intact and that each person to whom the Intellectual
Property is furnished agrees to the terms of this Agreement.
If you modify the Intellectual Property, all copies of the modified Intellectual Property must include, in addition to the above
copyright notice, a notice that the Intellectual Property includes modifications that have not been approved or adopted by LICENSOR.
THIS LICENSE IS A COPYRIGHT LICENSE ONLY, AND DOES NOT CONVEY ANY RIGHTS UNDER ANY PATENTSTHAT MAY BE IN FORCE ANYWHERE IN THE WORLD.
THE INTELLECTUAL PROPERTY IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED,INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULARPURPOSE, AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. THE COPYRIGHT HOLDER OR HOLDERS INCLUDEDIN THIS NOTICE DO NOT WARRANT THAT THE FUNCTIONS CONTAINED IN THE INTELLECTUAL PROPERTY WILLMEET YOUR REQUIREMENTS OR THAT THE OPERATION OF THE INTELLECTUAL PROPERTY WILL BE
UNINTERRUPTED OR ERROR FREE. ANY USE OF THE INTELLECTUAL PROPERTY SHALL BE MADE ENTIRELY AT
THE USER’S OWN RISK. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR ANY CONTRIBUTOR OFINTELLECTUAL PROPERTY RIGHTS TO THE INTELLECTUAL PROPERTY BE LIABLE FOR ANY CLAIM, OR ANY
DIRECT, SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTINGFROM ANY ALLEGED INFRINGEMENT OR ANY LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF
CONTRACT, NEGLIGENCE OR UNDER ANY OTHER LEGAL THEORY, ARISING OUT OF OR IN CONNECTION WITH
THE IMPLEMENTATION, USE, COMMERCIALIZATION OR PERFORMANCE OF THIS INTELLECTUAL PROPERTY.
This license is effective until terminated. You may terminate it at any time by destroying the Intellectual Property together with all
copies in any form. The license will also terminate if you fail to comply with any term or condition of this Agreement. Except asprovided in the following sentence, no such termination of this license shall require the termination of any third party end-user
sublicense to the Intellectual Property which is in force as of the date of notice of such termination. In addition, should the Intellectual
Property, or the operation of the Intellectual Property, infringe, or in LICENSOR’s sole opinion be likely to infringe, any patent,
copyright, trademark or other right of a third party, you agree that LICENSOR, in its sole discretion, may terminate this license
without any compensation or liability to you, your licensees or any other party. You agree upon termination of any kind to destroy orcause to be destroyed the Intellectual Property together with all copies in any form, whether held by you or by any third party.
Except as contained in this notice, the name of LICENSOR or of any other holder of a copyright in all or part of the Intellectual
Property shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Intellectual Property without
prior written authorization of LICENSOR or such copyright holder. LICENSOR is and shall at all times be the sole entity that may
authorize you or any third party to use certification marks, trademarks or other special designations to indicate compliance with any
LICENSOR standards or specifications.
This Agreement is governed by the laws of the Commonwealth of Massachusetts. The application to this Agreement of the United
Nations Convention on Contracts for the International Sale of Goods is hereby expressly excluded. In the event any provision of thisAgreement shall be deemed unenforceable, void or invalid, such provision shall be modified so as to make it valid and enforceable,
and as so modified the entire Agreement shall remain in full force and effect. No decision, action or inaction by LICENSOR shall be
construed to be a waiver of any rights or remedies available to it.
None of the Intellectual Property or underlying information or technology may be downloaded or otherwise exported or reexported inviolation of U.S. export laws and regulations. In addition, you are responsible for complying with any local laws in your jurisdiction
which may impact your right to import, export or use the Intellectual Property, and you represent that you have complied with any
regulations or registration procedures required by applicable law to make this license enforceableii

Copyright © 2012 Open Geospatial Consortium

OGC® 08-125r1

Contentsi.

Background .......................................................................................................... iii

ii.

Preface................................................................................................................... iv

iii.

Submitting organizations .................................................................................... iv

iv.

Submission contact points .....................................................................................vv.

Revision history ......................................................................................................v

vi.

Changes to the OGC® Abstract Specification ....................................................v

Foreword ........................................................................................................................... vi
Introduction ..................................................................................................................... vii
OGC® KML Standard Development Best Practices......................................................1
1

Scope........................................................................................................................1

2

Conformance ..........................................................................................................1

3

Normative references .............................................................................................1

4
4.1
4.2

Terms and symbols ................................................................................................1
Terms and definitions ............................................................................................1
Acronyms (and abbreviated terms) ......................................................................2

5
5.1
5.2

Conventions ............................................................................................................3
UML Notation ........................................................................................................3
XML Namespaces ..................................................................................................3

6
6.1
6.2
6.2.1
6.2.2
6.2.3
6.2.4
6.2.5
6.2.6
6.2.7

KML development process....................................................................................4
overview ..................................................................................................................4
development phases ...............................................................................................6
respond ....................................................................................................................6
build.........................................................................................................................6
assure.......................................................................................................................6
specify ......................................................................................................................6
release ......................................................................................................................7
measure ...................................................................................................................7
formalize .................................................................................................................8ii

Copyright © 2009 Open Geospatial Consortium, Inc. All Rights Reserved.

OGC® 08-125r1

7
7.1
7.2
7.3
7.3.1
7.3.2
7.3.3
7.3.4
7.4
7.4.1
7.4.2
7.4.3
7.4.4
7.4.5
7.4.6

i.

OGC KML standardization ..................................................................................9
overview ..................................................................................................................9
KML progression ...................................................................................................9
roles .......................................................................................................................11
KML users ............................................................................................................11
KML application providers ................................................................................11
OGC MMWG .......................................................................................................11
OGC KML SWG..................................................................................................11
KML SWG process guidelines ............................................................................12
charter ...................................................................................................................12
timeline ..................................................................................................................12standardization criteria .......................................................................................12
KML enhancement ..............................................................................................13
public comment ....................................................................................................13
KML revision .......................................................................................................13

BackgroundIn early 2007, Google proposed to the OGC that KML be submitted to the OGC to
become an OGC standard. In June 2007, KML 2.1 was approved as an OGC bestpractice. The preamble to the document stated the reasons for KML becoming an OGC
standard :1. That there be one international standard language for expressing geographic
annotation and visualization on existing or future web-based online maps (2d) andearth browsers (3d).
2. That KML be aligned with international best practices and standards, thereby
enabling greater uptake and interoperability of earth browser implementations.
3. That the OGC and Google will work collaboratively to insure that the KML
implementer community is properly engaged in the process and that the KML
community is kept informed of progress and issues.
4. That the OGC process will be used to insure proper life-cycle management of theKML candidate specification, including such issues as backwards compatibility.
In April 2008, KML 2.2 became an official OGC standard. In order to meet objective 4,
the OGC and the Google KML community needed to define a procedure for life cycle
management of the OGC KML standard.

Copyright © 2009 Open Geospatial Consortium, Inc. All Rights Reserved.

iii

OGC® 08-125r1

ii.

PrefaceThis Best Practices Document provides guidance on the revision process for OGC KML.
The intended audience is the OGC Mass Market Working Group (MMWG), current or
future KML Standard Working Groups (SWG), and Technical Committee (TC) members
as well as KML application developers and users with regards to progressing the OGC
KML standard such that KML:•

Remains true to its purpose: encoding the visualization and navigation of information
within a geographic context for earth browser systems;•

Is enhanced on the basis of proven extensions requested by the mass market;•

Provides general solutions that meet end user performance expectations withincurrent software and hardware limitations, with due consideration for legacy
software/hardware;•

Progresses on a regular and consistent revision cycle that assures the timely
development of new applications required by the rapidly growing and changing mass
market environment.

The guidance is based on a well-received presentation given by OGC Member Google to
the MMWG on past KML and earth browser development practices which proved
successful to the growth and adoption of KML within the mass market community.
Agreeing with the general process and principles described therein, the MMWG elected
to summarize recommendations for continuing the successful evolution of the KML
standard within a combined mass market and OGC framework. The policies andprocedures documented herein are the result of those discussions.

iii.

Submitting organizations

The following organizations as members of the OGC Mass Market Working Group havesubmitted this Best Practices Paper to the Open Geospatial Consortium Inc.:a) Google, Inc.
b) Galdos Systems Inc.
c) European Union Satellite Centre (EUSC)

ii

Copyright © 2009 Open Geospatial Consortium, Inc. All Rights Reserved.

OGC® 08-125r1

iv.

Submission contact points

All questions regarding this submission should be directed to the editor or submitters:
CONTACTv.

EMAILDavid Burggraf

Galdos Systems Inc.

dburggraf at galdosinc.com

Bent Hagemark

Google, Inc.

bent at google.com

Michael Ashbridge

Google, Inc.

mashbridge at google.com

Michael Weiss-Malik

Google, Inc.

michaelwm at google.com

Revision history
Date

ReleaseAuthorParagraphmodified

Description

24-06-08

0.1

Tim Wilson, Bent All
Hagemark

Initial version.

26-06-08

0.2

Michael Ashbridge 5.2; 6.1; 6.2

Terminology edits.

30-06-08

0.3

Tim Wilson

Revision and completion of first draft.

02-07-08

0.4

Tim Wilson, Bent Preamble;
Hagemark, Michael Introduction
Ashbridge

Reference to MMWG presentation; listof KML clients referenced.

7/7/080.5Carl Reed

VariousPrepare for posting to Pending formember review.

David Burggraf

i-v, Intro, 4, 5, 6, Further edits in preparation for posting to
7
Pending on the OGC Portal

20-08-2008 0.6

vi.

COMPANY

All

Changes to the OGC® Abstract Specification

The OGC® Abstract Specification does not require changes to accommodate this OGC®
Best Practices Document.

Copyright © 2009 Open Geospatial Consortium, Inc. All Rights Reserved.

v

OGC® 08-125r1

Foreword
Attention is drawn to the possibility that some of the elements of this document may be
the subject of patent rights. The Open Geospatial Consortium Inc. shall not be held
responsible for identifying any or all such patent rights.
Recipients of this document are requested to submit, with their comments, notification of
any relevant patent claims or other intellectual property rights of which they may beaware that might be infringed by any implementation of the standard set forth in thisdocument, and to provide supporting documentation.

ii

Copyright © 2009 Open Geospatial Consortium, Inc. All Rights Reserved.

OGC® 08-125r1

Introduction
The Free Dictionary defines mass market as, "of, relating to, or produced for
consumption in large numbers …". In this regard, KML is a mass market standard thatfacilitates the visualization and navigation of information within a geographic context.
The current geo-mass market operating environment has the following characteristics:•

Consists of millions of users, most of whom are non-experts with respect to thegeospatial domain;•

Using tens of millions of existing and indexed KML files and resources;•

Within a large and growing list of earth browser applications;•

On fairly average and diverse equipment, including the expanding use of mobile
devices;•

All of which is growing rapidly.

To support this environment, KML has been developed to date according to a process andprinciples whereby the language:•

Allows for unexpected and unintended uses;•

Supports multi-purpose constructs and mechanisms;•

Provides a core API that can be extended according to a well-defined model;•

Is extended incrementally to support new mass market applications;•

Changes formally only for those extensions that are proven through mass market
adoption.

The rapid and widespread uptake of KML by the mass market attests to the benefits ofthis approach and advocates for its continuation within OGC KML standardization
processes. As such, this document provides guidance on assuring similar success in the
progression of the OGC KML standard.

Copyright © 2009 Open Geospatial Consortium, Inc. All Rights Reserved.

vii

OGC® Best Practices Document

OGC® 08-125r1

OGC® KML Standard Development Best Practices
1

Scope

This OGC® Best Practices Document provides guidelines for developing the OGC KML
standard in a manner that best serves and supports the KML application developer and user
communities. It applies to the extension of KML by application developers and thesubsequent enhancement of the KML standard by the OGC.
2

Conformance

There are no conformance clauses for this Best Practices Document.
3

Normative references

The following normative documents contain provisions that, through reference in this text,
constitute provisions of this part of OGC® 08-125r1. For dated references, subsequent
amendments to, or revisions of, any of these publications do not apply; however, parties toagreements based on this part of OGC® 08-125r1 are encouraged to investigate thepossibility of applying the most recent editions of the normative documents indicated below.
For undated references, the latest edition of the normative document referred to applies.
OGC 07-147r2, OGC KML
OGC 07-134r2, OGC KML 2.2 - Abstract Test Suite
4

Terms and symbols

4.1

Terms and definitions

For the purposes of this document, the following terms and definitions apply.

Copyright © 2009 Open Geospatial Consortium, Inc. All Rights Reserved.

1

OGC® 08-125r1

4.1.1
KML extension
An extension of the core KML language, using the normative KML extension model andpolicies, to support new mass market applications.
4.1.2
KML enhancement
A standardized KML extension integrated into the core KML language.
4.2

Acronyms (and abbreviated terms)

Some frequently used abbreviated terms:
ATS

Abstract Test Suite

DWG

Domain Working GroupGIS

Geographic Information System

HTTP

Hyper Text Transfer Protocol

IETF

Internet Engineering Task Force

KML

Keyhole Markup Language

MMWG

Mass Market Working Group

OGC

Open Geospatial Consortium

RFC

Request for Comments

SWG

Standards Working Group

UML

Unified Modeling Language

XML

Extensible Markup Language

XSD

XML Schema Definition

2

Copyright © 2009 Open Geospatial Consortium, Inc. All Rights Reserved.

OGC® 08-125r1

5

Conventions

5.1

UML Notation

There is no UML associated with this Best Practices Document.
5.2

XML Namespaces

All components of the KML schema are defined in the namespace with the identifier"http://www.opengis.net/kml/2.2", for which the prefix kml or the default (noprefix) namespace is used within this Best Practice Document.

Copyright © 2009 Open Geospatial Consortium, Inc. All Rights Reserved.

3

OGC® 08-125r1

6

KML development process

6.1

overview

KML was historically developed by cycling through the following development phases:•

respond to the wisdom of the masses as to what new functionality KML should support;•

build the new functionality as running code;•

assure its compatibility and performance;•

specify the KML language extension to support it;•

release the KML extension API and application(s) built upon it;•measure its utility via usage statistics, performance metrics, and user feedback;•formalize it within the core language only if proven to be of general, popular, andeffective use.

4

Copyright © 2009 Open Geospatial Consortium, Inc. All Rights Reserved.

OGC® 08-125r1

build

We really need this new
capability

assurerespondLet’s formalize it foreveryone’s benefit

specifymass
marketCool, this is really
usefulformalize

releasemeasureFigure 1 ·· KML development phases

Copyright © 2009 Open Geospatial Consortium, Inc. All Rights Reserved.

5

OGC® 08-125r1

6.2

development phases

6.2.1

respond

As with any successful social or commercial enterprise, KML has evolved according to theneeds of its user base. The mass market geo community continues to express its wants andneeds via bulletin boards, blogs, forums, community projects, and the OGC Mass Market
Working Group, amongst other feedback mechanisms. Developing KML in response tocurrent and predominant mass market application requirements will continue to assure its
value and relevancy.
6.2.2

build

An overriding principle for any KML development is that the proof is in its application.
Coding ideas early in the revision process helps to determine whether new concepts andextensions can be effectively built and integrated into existing applications while still
meeting new requirements.
6.2.3

assure

The following questions should be addressed when designing and implementing any KML
extension:•

Are old implementations well behaved (e.g. stable) when faced with new KML extension
data? There is an assumption that a significant percentage of existing KML
implementations may never be upgraded.

•

Are new implementations friendly to existing data? Assume old data exists forever andcan never be changed.

In this regard, backward compatibility of any new KML data with respect to existing andlimited clients is a paramount goal. In practice this means KML development should focus
on incremental enhancements, rather than refactoring or redesign.
KML enhancements should also consider forward compatibility in their design by facilitating
the graceful handling of new components by old clients.
6.2.4

specify

To support adoption and 3rd party usage, a KML extension should be well defined within an
API specification document, and include sample files that demonstrate:•normal or intended uses;•

any known edge cases and their recommended handling;•

integration with existing core KML;

6

Copyright © 2009 Open Geospatial Consortium, Inc. All Rights Reserved.

OGC® 08-125r1•

integration with the KML update mechanism (see kml:Update in OGC KML Standard).

Such documentation should be understandable to the average, non-expert user.
6.2.5

release

Release the KML extension API, samples, and application(s) built upon it. Promote
experimentation and seek feedback.
6.2.6

measureRecord user feedback and usage statistics to help determine adoption rate and performance
results. Pay attention to the handling of ‘edge cases’ i.e. combinations of extreme or omitted
element values (e.g. geometry near poles or antemeridian) and revisit design, if necessary, tomitigate any unforeseen negative results.
6.2.6.1

adoption

As mass market usage is an overriding indicator of the significance and utility of a KML
extension, adoption rates should be measured and made accessible for verification.
6.2.6.2

performance

Application performance is a predominant goal. In practice, this means KML evolution
should focus on solutions that meet end user performance expectations within current
software and hardware limitations.
Performance requirements should not exceed common hardware devices of non-expert users.
Such devices increasingly include mobile clients.
Important considerations affecting the design, implementation, and/or standardization of any
KML enhancement include:•

How does the enhancement behave on weak, limited, and/or mobile devices?

•

How much texture memory does the enhancement require? How many clients rightnow have this much? What happens to those that still have old gear?

Performance statistics should be accessible for those exemplar applications using the new
KML extension.
6.2.6.3

edge cases

KML enhancements should minimize the possibility of encoding any ambiguous, extreme, ormeaningless values. Where this is not possible, facilitating graceful degradation within
encodings and clients is encouraged.

Copyright © 2009 Open Geospatial Consortium, Inc. All Rights Reserved.

7

OGC® 08-125r1

Exemplar applications using the KML extension should test any and all known edge cases
using representative sample files.
6.2.7

formalize

Formalization of a new KML extension can occur as a last step when and where it:•

adheres to the requirements of the existing OGC KML standard;•adheres to the best practices outlined in this document as much as possible;•

provides a satisfactory and general solution for the new functionality it provides;•

has proven itself useful through adoption within the mass market;•

would enhance the core KML language;•is formally offered to the OGC for standardization by the owning party or parties. This
includes a commitment to assign any existing intellectual property associated with theextension to the OGC.

The OGC KML standard follows a certain architecture that should persist within KML
extensions and enhancements in order to maintain stable application development, facilitate
the reuse of existing client code, and ease the understanding of new components.

8

Copyright © 2009 Open Geospatial Consortium, Inc. All Rights Reserved.

OGC® 08-125r1

7

OGC KML standardization

7.1

overview

While the OGC is now the owner and forum for enhancing the KML standard, the mass
market itself remains the de facto place for KML application development and therefore
those KML extensions that support them.
Natural stages and roles exist within the overall progression of KML, as shown in thefollowing diagram.

Figure 2 ·· KML evolution

7.2

KML progression

For simplicity of discussion, the KML development phases are summarized into three
general progression stages as follows:

Copyright © 2009 Open Geospatial Consortium, Inc. All Rights Reserved.

9OGC® 08-125r1•

extension ·· This includes the respond, build, assure, specify, and release activities.
The outcome is a KML extension API and application(s) built upon it. Suchdevelopment is expected to be performed by individual vendors or organizations,although discussion amongst groups during such development is encouraged.

•

adoption ·· Uptake within and by the mass market of a KML extension API andoriginating and 3rd party applications built upon it. Performance and most criticallyadoption rates should be measured to support assessment of the extension within thestandardization process.

•standardization ·· Formalize proven KML extensions as enhancements to the core KML
language. The OGC MMWG should provide guidance on priority enhancements, while
the KML SWG conducts the technical evaluation and integration of such enhancements
into the KML standard, ATS, and schema.

•

A key requirement of the standardization process is that the developers of theenhancement and/or extension submit an official OGC Change request into the OGC
process. These change requests are public and may be submitted into the OGC processusing the public CR submission form at <new url>. The developer may also submit a
Change Request via the work done in the MMWG. However, CR submitted as part ofnormal OGC activities will also be publicly available.

•

PLEASE NOTE: No new extension or enhancement to KML will be considered for arevision to the OGC KML standard unless a CR is submitted!

10

Copyright © 2009 Open Geospatial Consortium, Inc. All Rights Reserved.

OGC® 08-125r1

7.3

roles

7.3.1

KML users

The KML user community serves as the hub of mass market geo ideation, experimentation,
and adoption. It includes your average Geo, not your average Geo, non-profits, academic
institutions, corporations, and public agencies who are creating and/or using KML. In short,
almost anyone anywhere involved with the visualization of information within a geographic
context.
7.3.2

KML application providers

KML application providers include the larger earth browser providers, 3rd party application
developers, GIS software vendors, mobile providers, and others. As they develop andprovide earth browser functionality to KML users they are best able to extend KML to meet
new user requirements for earth browser technologies.
7.3.3

OGC MMWG

The MMWG, as a representative body for the mass market community, is best able tooversee the long-term development of the OGC KML standard. It represents a valuable
forum for discussing feature requests and KML extensions that could satisfy them. There is
likely also a role for the MMWG to advise on the prioritization of KML enhancements forstandardization, and to arbitrate between any similar proposed enhancements.
7.3.4

OGC KML SWG

An OGC KML SWG best able to:•establish a discrete charter with specific standardization objectives;•

assure a regular, timely and responsive KML development schedule;•

evaluate official OGC change requests and integrate proven KML extensions according
to established standardization criteria;•

document any and all changes within a new KML standard revision (Revision notes).

To better perform these tasks, KML SWG members should preferably have mass market geo
presence; participate actively in the MMWG; have technical expertise in KML applications
and extensions; and remain actively involved in the KML SWG process.

Copyright © 2009 Open Geospatial Consortium, Inc. All Rights Reserved.

11

OGC® 08-125r1

7.4

KML SWG process guidelines

All revisions to the OGC KML standard shall use the same revision policies and procedures
as detailed in the OGC Technical Committee Policies and Procedures. The following is asynopsis of additional guidance for the processing of the OGC KML standard for formal
approval as an official OGC revision.
7.4.1

charter

A KML SWG should assure that KML remains true to its purpose: encoding the presentationand navigation of information within a geographic context.
The charter for KML SWGs should respect the KML development best practices outlined inthis document.
A KML SWG should focus on incrementally enhancing the KML standard by evaluating andintegrating KML extensions that have already been proven in the mass marketplace.
Only if there is sufficiently valuable and well-defined mass market needs for an applicationthat cannot be accommodated by the current language primitives, shall a backwardsincompatible revision be contemplated. It is expected that the MMWG will advise on boththe need and timing for any such major revision.
7.4.2

timeline

KML should evolve in a manner that satisfies the mass market need for regular andincremental enhancements of functionality. In practice this means a KML SWG should limit
its scope of work to that which can be achieved within at most an annual release cycle.
A regular and consistent KML revision cycle will help to assure commercial development ofearth browser technologies and applications within the rapidly changing mass market geo
environment.
7.4.3

standardization criteria

A KML extension should be evaluated on the basis of how well it:•

is consistent with the purpose, architecture, and requirements of KML;•

is consistent with the KML standard development best practices;•

enables new mass market application(s) that are otherwise not supported by the existing
KML core primitives;•is proven through significant and verifiable adoption within the mass market;•

provides a general solution that meets end user performance expectations within current
software and hardware limitations;

12

Copyright © 2009 Open Geospatial Consortium, Inc. All Rights Reserved.

OGC® 08-125r1•

is backwards compatible with previous minor KML revisions;•

includes a change request document meeting OGC requirements, as well as a set of test
files for normal, edge, and update cases.

A KML SWG should assure backwards compatibility by testing against a normative set of
KML test files. The normative set should include instances for all previous KML versions,starting with KML 2.1. The test coverage will naturally expand over time as a result of
ongoing KML revisions. The KML SWG may additionally elect to test the compatibility
using a reference KML parser such as the open-source libkml library.
7.4.4

KML enhancement

When enhancing the core KML language, a KML SWG should integrate an acceptable KML
extension with as little disruption as possible to existing users and applications of KML aswell as the extension itself. In practice this means using the same KML extension element
and attribute names and structures as much as possible.
A new KML standard revision should address necessary changes to the KML standard,
abstract test suite, and XML schema to incorporate the enhancement.
7.4.4.1

versioning

An incremental enhancement shall result in a minor revision of the KML Standard, i.e.
X.Y+1; everything that validates against x.y shall validate against X.Y+n
A small, immediate and necessary fix to the KML Standard or XML schema shall result in a
bug fix revision of the Standard, i.e. X.Y.Z+1; everything that validates against X.Y.Z
shall validate against X.Y.Z+n, excepting those instances that are invalid with respect to thefixes themselves. X.Y.Z+n shall not introduce any new functionality from X.Y.Z
A backwards-incompatible revision shall result in a major revision of the KML Standard, i.e.
X+1.0.0 Major revisions are expected to rarely occur.
7.4.5

public comment

Draft KML enhancements must be posted for a 30 day public comment as per OGC SWG
requirements. Feedback should be evaluated within the context of the standardization
criteria.
7.4.6

KML revision

A KML revision, encompassing a new KML standard document, abstract test suite, andXML schema, must receive approval by the OGC Technical Committee (TC) before it isreleased as the next KML standard.

Copyright © 2009 Open Geospatial Consortium, Inc. All Rights Reserved.

13

OGC® 08-125r1

14

Copyright © 2009 Open Geospatial Consortium, Inc. All Rights Reserved.