- Galdos Systems Inc. - http://www.galdosinc.com -

GML Core and Extensions

There has been a great deal of discussion of late in the OGC respecting the so called “core-extension” model for specifications.  The intent is to have a relatively small core, and then a series of extensions. This note looks at what this might mean for GML, such as how might we restructure the GML specification so that there is clearly a core and a set of extensions.  Note that this is in effect a layered discussion, since the whole of GML (or any subset) can be considered a core with respect to the construction of application specific vocabularies (application schemas).  In this note, however, we will consider ONLY the components defined within the GML schemas themselves.

To determine how to apply the so called “core-extension” pattern it is useful to have a general idea of what that might mean in the context of GML.  There are a number of possibilities; however, the most attractive one to me is as follows.

  1. Core contains all of the key abstract types.
  2. If you support the core then you are asserting that you can consume ANY GML application schema, and correctly trace any content models to their origin in the GML core schema (i.e. do the type tracing).  This means that you can determine what things in the application schema are features (i.e. derive from gml:AbstractFeatureType), which are coverages (i.e. derive from gml:AbstractCoverageType) and so on,  and which things are the properties of these features, coverages, etc.  
  3. Note that if you ONLY support the core, you do not need to understand ANY of the types that appear in the application schemas, simply properly trace them.
  4. If you support say a geometry extension, (as well as core) then you are asserting that you understand the concrete types defined in that extension and that you can take specific semantic actions on encountering instances of those types.

With this approach the core of GML would then consist of:

With this as the core, we can then create various extensions to incorporate concrete types for geometry, topology, coverage etc.  This is illustrated by the following simple diagram:


With this approach, the core supports the construction of application schemas, but does not provide other than the most basic concrete types.  The application schema developer then selects the specific extensions (e.g. a particular concrete geometry schema) they require for their application domain.  This is represented by the following diagram:


With this approach, any GML aware application would need to support the core, and then elect to support one or more extensions that are needed for particular classes of application schema.  Note that this does not make any aspect of GML any more important than any other.  For example, time is just as important as space.

We believe this approach will help GML tool developers to design better software and will lower the cost of entry.