While it might sound strange at first, GML does not require application objects (features) to have geometry properties. This means we can create GML objects that represent more or less any kind of entity, and possibly add geometry properties when or if these become important.
We can start a GML encoding with not much more than feature.xsd and gmlBase.xsd, and then create a suitable application schema. In such a case, most of the elements and attributes in the application schema will be defined in its target namespace, and very few attributes and elements from the GML namespaces will be utilized.
Note that to create a schema you do not need to do a lot. Essentially it is the same as creating an arbitrary XML Schema with the additional restrictions:
1. Declare a target namespace (e.g. http://www.myspace.org/stuff)
2. Import the GML feature.xsd schema with the associated namespace.
3. Derive your features (directly or indirectly) from gml:AbstractFeatureType
For the simple example above, assuming we want Vehicle to be a feature (application object type), the essence of the schema is then as follows:
<xs:schema targetNamespace="http://www.myspace.org/stuff" xmlns:xs="http://www.w3.org/2001/XMLSchema"
<xs:import namespace="http://www.opengis.net/gml" schemaLocation="gml\feature.xsd"/>
<xs:element name="Vehicle" type="abc:VehicleType"/>
<xs:element name="make" type="xs:string"/>
<xs:element name="model" type="xs:string"/>
<xs:element name="cylinders" type="xs:positiveInteger"/>
Note that the data in this instance might have started with a relational schema – e.g.
Vehicle(id identifier, make string, model string, cylinder integer)
Mapping this schema definition to GML is thus pretty straightforward as can be seen by just looking at the schema.
Of course more complex table models (relational schema) will not map quite so easily into GML.
It should be borne in mind that GML exposes a feature model and the construction of the mapping from relational to GML is pretty much the same as mapping from a relational schema to an extended E-R model. This later task is not well defined and requires human input to interpret which tables represent entities and which represent relationships. This same human input is required somewhere in the process for GML in order to say which tables represent features and which represent relationships among the feature types. This also means that the GML Schema encoding is somewhat semantically richer than just exposing the physical table model, and this additional richness is very useful in applications.