One of the aspects of GML that often receives comment is that of GML application schemas. For some reason many people in GIS and Cartography find this notion either complex or strange or both. This is so, in spite of the fact that the same persons are already aware of relational schemas or at least withe concept of a table in a relational database. If I say I want to create a table containing persons and that table has the attributes (Name(string), Age(integer), Address(string) no one gets excited. This means I have created (somewhere) a schema that looks like:
Person(Name:String, Age:Integer, Address:string)
Great – right. For some reason the idea of a GML application schema seems more foreign – like saying in GML that I want to create a Person object with a shema (GML Application Schema) that defines a Person Object with the properties Name, Age and Address. Not really so difficult is it?
Note that in both cases we define a KIND OF THING (in this case a PERSON) and we DESCRIBE that KIND OF THING by specifying its attributes (relational schema) or properties (GML Schema), the specification of the properties including the property NAME (e.g. Age) and the property TYPE (e.g. Integer). Of course GML provides a whole set of special types for both KINDS OF THINGS (e.g. geometric, topological objects) and for PROPERTIES. In fact MOST of GML is simply a catalogue of these KINDS OF THINGS.
So there is no need to be afraid of GML application schemas.
How come other geographic encodings don't use schemas? Well some do (e.g. KML) and some do not. The ones that do not typically do NOT provide a means to create a new kinds of objects, somethings which is critical to GML and to geographic information in general. Note that when you pass DBF files around you ARE passing in effect schema information.
Why does GML use XML Schema to write application schemas? Well we could have created YET ANOTHER SCHEMA LANGUAGE. This is the solution adopted by KML, SAIF and others, and which was initially used in GML v1.1. The problem with this approach is that you then need to create ALL of the tools to work with these schemas – schema design, translation, and validation – AND the tools to ensure that data instances are in fact consistent with the developed schemas. In GML we felt that it was better to use an existing, developed schema language.