GML is a fairly complex specification that is rich in functionality. In general an implementation need not exploit the entire specification, but may employ a subset of constructs corresponding to specific relevant requirements. A profile of GML could be defined to enhance interoperability and to curtail ambiguity by allowing only a specific subset of GML; different application schemas could conform to such a profile in order to take advantage of any interoperability or performance advantages that it offers in comparison with full-blown GML. Such profiles could be defined inside other OGC specifications.
There may be cases where reduced functionality is acceptable, or where processing requirements compel use of a logical subset of GML. For example, applications that don't need to handle XLink attributes in any form can adhere to a specific profile that excludes them; the constraint in this case would be to not use links. Other cases might include defining constraints on the level of nesting allowed inside tags (i.e. tree depth), or only allowing features with homogeneous properties as members of a feature collection. In many cases such constraints can be enforced via new schemas; others may be enforced through procedural agreements within an information community.
Here are the guidelines for developing a profile:
A profile of GML is a restriction of the basic descriptive capability of GML.
Any such profile must be fully compliant with the GML 2.0 specification.
GML abstract type definitions may be freely extended or restricted.
A profile must not change the name, definition, or data type of mandatory GML elements.
The schema or schemas that define a profile must be made available to any application schemas which will conform to the profile.
The relevant schema or schemas that define a profile must reside in a specified namespace that must not be http://www.opengis.net/gml (i.e. the core 'gml' namespace)