5 GML Application Schemas

5.1 Introduction

The base schemas (Geometry, Feature, XLink) can be viewed as the components of an application framework for developing schemas or sets of schemas that pertain to a particular domain (e.g. Forestry), jurisdiction (e.g. France), or information community. Furthermore, such application schemas may be developed in a more horizontal fashion to support many information communities.

There are some basic conformance requirements that every application schema must satisfy. Specifically, a conforming GML application schema must heed the following general requirements:

A set of logically-related GML schemas, which we term the GML Framework, is depicted in Figure 5.1. The GML schemas provide basic constructs for handling geospatial data in a modular manner. A more specialized application framework containing component application schemas would typically be created for a particular theme or domain, but may also be quite horizontal in nature.

5.2 Rules for constructing application schemas (normative)

The following rules must be adhered to when constructing GML application schemas.

5.2.1 Defining new feature types

Developers of application schemas can create their own feature or feature collection types, but they must ensure that these concrete feature and feature collection types are subtyped (either directly or indirectly) from the corresponding GML types: gml:AbstractFeatureType or gml:AbstractFeatureCollectionType.

<complexType name="MyFeature1Type">
  <complexContent>
    <extension base="gml:AbstractFeatureType">
      <sequence>
        <!-- additional child elements inserted here -->
      </sequence>
    </extension>
  </complexContent>
</complexType>

<complexType name="MyFeature2Type">
  <complexContent>
    <extension base="foo:MyFeature1Type">
      <sequence>
        <!-- additional child elements inserted here -->
      </sequence>
    </extension>
  </complexContent>
</complexType>

5.2.2 Defining new geometry types

Authors may create their own geometry types if GML lacks the desired construct. To do this, authors must ensure that these concrete geometry and geometry collection types are subtyped (either directly or indirectly) from the corresponding GML types: AbstractGeometryType or GeometryCollectionType:

<complexType name="MyGeometry1Type">
  <complexContent>
    <extension base="gml:AbstractGeometryType">
      <sequence>
        <!-- additional child elements inserted here -->
      </sequence>
    </extension>
  </complexContent>
</complexType>

Any user-defined geometry subtypes shall inherit the elements and attributes of the base GML geometry types without restriction, but may extend these base types to meet application requirements, such as providing a finer degree of interoperability with legacy systems and data sets.

5.2.3 Defining new geometry properties

Authors may create their own geometry properties that encapsulate geometry types they have defined according to subsection 5.2.2; they must ensure that these properties are subtyped (either directly or indirectly) from gml:GeometryPropertyType and that they do not change the cardinality of the target instance, which must be a bonafide geometry construct:

<complexType name="MyGeometry1PropertyType">
  <complexContent>
    <restriction base="gml:GeometryPropertyType">
      <sequence minOccurs="0">
        <element ref="foo:MyGeometry1Type" />
      </sequence>
      <attributeGroup ref="gml:AssociationAttributeGroup"/>
    </restriction>
  </complexContent>
</complexType>

5.2.4 Declaring a target namespace

Authors must declare a target namespace for their schemas. All elements declared in the schema, along with their type definitions, will reside in this namespace. Validation will not succeed if the instance document does not reside in the schema's target namespace. Note that it is not a requirement that URIs actually point to anything concrete, such as a schema document; namespaces are basically just a mechanism to keep element names distinct, thereby preventing namespace 'collisions'.

To use namespaces, elements are given qualified names (QName) that consist of two parts: the prefix is mapped to a URI reference and signifies the namespace to which the element belongs; the local part conforms to the usual NCName production rules from the W3C Namespaces Recommendation:

NCName ::=  (Letter | '_') (NCNameChar)*
NCNameChar ::=  Letter | Digit | '.' | '-' | '_' | CombiningChar |
  Extender

In each worked example the namespace for all elements is explicitly indicated in order to show how vocabularies from different namespaces can intermingle in a single instance document. The use of fully qualified names is specified by setting the value of the elementFormDefault attribute of <schema> to "qualified":

<schema  targetNamespace="http://www.bar.net/foo"
         xmlns="http://www.w3.org/2000/10/XMLSchema"
         xmlns:gml="http://www.opengis.net/gml"
         xmlns:foo="http://www.bar.net/foo"
         elementFormDefault="qualified"
         version="0.1">

  <!-- import constructs from the GML Feature and Geometry schemas -->
  <import namespace="http://www.opengis.net/gml"
    schemaLocation="feature.xsd"/>
 . . .
</schema>

5.2.5 Importing schemas

A conforming instance document can employ constructs from multiple namespaces, as indicated in Figure 5.2. Schema-A in the 'foo' namespace plugs into the GML framework via the Feature schema (which also brings along the geometry constructs). The Feature schema resides in the 'gml' namespace along with the Geometry schema, so it uses the include mechanism. However, since Schema-A targets a different namespace, it must employ the import mechanism to use the core GML constructs.

Authors must bear in mind that the 'import' mechanism is the only means whereby an application schema can bring in GML constructs and make use of them. Since a conforming application schema cannot target the core GML namespace ("http://www.opengis.net/gml"), other mechanisms such as 'include' and 'redefine' cannot be employed.

5.2.6 Using substitution groups

Global elements that define substitution groups shall be used for both class (e.g. feature, geometry etc.) and properties that are defined in GML application schemas, and can substitute for the corresponding GML elements wherever these are expected. Declare an element globally and specify a suitable substitution group if the element is required to substitute for another (possibly abstract) element; substitution groups thus enable type promotion (i.e. treating a specific type as a more general supertype). The following global declaration ensures that if foo:CircleType is a defined geometry type, then a <Circle> element can appear wherever the (abstract) gml:_Geometry element is expected:

<schema . . .>
  <element name="Circle" type="foo:CircleType"
    substitutionGroup="gml:_Geometry" />
  . . .
</schema>

Identical elements declared in more than one complex type definition in a schema should reference a global element. If the <Circle> element is declared globally in the 'foo' namespace (as shown above), it is referenced from within a type definition as follows:

<complexType name="MyHubPropertyType">
  <complexContent>
    <restriction base="gml:GeometryPropertyType">
      <sequence minOccurs="0">
        <element ref="foo:Circle" />
      </sequence>
      <attributeGroup ref="gml:AssociationAttributeGroup"/>
    </restriction>
  </complexContent>
</complexType>

5.2.7 Declaring additional properties

Schema authors can use the built-in geometric properties or derive their own when necessary as shown in subsection 5.2.3. GML provides a number of predefined geometric properties: location, centerLineOf, extentOf, and so on. Authors can also apply a different name to a base type and use it instead:

<element name="crashSite" type="gml:PointPropertyType"
  substitutionGroup="gml:pointProperty" />

A feature may also have properties that possess a more complex content model (like geometry properties or feature members). It's important to keep in mind that complex properties represent binary relationships, and that property elements carry the role name of that association. In general, the value of a property element must be one or more instances (either local or remote) of some defined simple or complex type.

As an example, consider the inspectedBy property of a waste handling facility that associates a <WasteFacility> instance with an <Inspector> instance:

<complexType name="WasteFacilityType">
  <complexContent>
    <extension base="gml:AbstractFeatureType">
      <sequence>
        <!-- other properties -->
        <element name="inspectedBy" type="foo:InspectedByType" />
      </sequence>
    </extension>
  </complexContent>
</complexType>

<complexType name="InspectedByType">
  <sequence minOccurs="0">
    <element ref="foo:Inspector"/>
  </sequence>
  <attributeGroup ref="gml:AssociationAttributeGroup" />
</complexType>

The above fragment indicates that foo:InspectionType includes the simple-type XLink attributes (that are bundled up in gml:AssociationAttributeGroup) to take advantage of the optional pointer functionality; this can be useful if the same inspector assesses multiple facilities and is the target of multiple references:

<WasteFacility>
  . . .
  <inspectedBy xlink:type="simple" xlink:href="inspectors.xml#n124" />
</WasteFacility>

The definition of the Inspector type is not shown here, but it must appear in some application schema. Furthermore, an inspector need not be a feature instance?perhaps an inspector is a Person that possesses properties such as an 'oid' identifier. Without the href and other XLink attributes a valid instance might then look like the following:

<WasteFacility>
  . . .
  <inspectedBy>
    <Inspector oid="n124">. . .</Inspector>
  </inspectedBy>
</WasteFacility>

5.2.8 Defining new feature association types

Developers of application schemas can create their own feature association types that must derive from gml:FeatureAssociationType. The target instance must be a bonafide GML feature, and it may appear once (explicitly minOccurs="0", implicitly maxOccurs="1"):

<complexType name="MyFeatureAssociationType">
  <complexContent>
    <restriction base="gml:FeatureAssociationType">
      <sequence minOccurs="0">
        <element ref="foo:MyFeature1Type" />
      </sequence>
      <attributeGroup ref="gml:AssociationAttributeGroup"/>
    </restriction>
  </complexContent>
</complexType>

In many cases it may be desirable to allow instances of only certain feature types as members of a feature collection. A Feature Filter as described below shall be applied to ensure that only properly labeled features are valid members.