A great deal of noise has been made over the past year or two about the importance of profiles. In some cases it is to try and control some domain. In others it is to get a low entry bar to encourage specification adoption. In some cases it is an organization's attempt to put a particular spin on a specification or technology.
As readers will be aware, Profiles exist for GML and have been discussed here previously. Profiles which are strict subsets of GML have a definite use – they can limit the vocabulary required to only what is necessary to support a given range of applications. They can adapt a specification to the requirements of a narrow application. In some cases they can lay the foundation for a lowest common denominator – a reduced version of a standard that can get others on the bandwagon. The profile of GML for JPEG 2000 (part of the recently announced GMLJP2 Specification) fits the former, while GML for Simple Features fits the latter. All of this is well and good. At the same time it is interesting to see the arguments put forward in support of GML profiles – some of which are not so clearly founded.
For example – "GML Profiling – Why it is important ".
The article begins simply enough – outlining a more or less accurate versio of ESRI participation in the OGC and then stating a summary of the "rules" of GML. It notes that the root tag is always FeatureCollection. While this was more or less true in GML 2 (the root tag had to have a content model that derived from AbstractFeatureCollectionType) – this is not true in GML 3, since GML 3 "documents" are NOT restricted to being geographic features.
It further notes that a FeatureCollection need not be homogeneous and can mix features of different types and those features can have mixed geometry models. This is indeed the case – not only for GML but for real world thngs. A City, for example can be seen as a feature collection – and its features will be of many different types (roads, buildings, parks etc.) with quite varying geometric descriptions. The GML is intended to represent reality.
The author then goes on to note "Although these rules can allow great richness in feature model descriptions, this richness doesn't necessarily help achieve other goals such as interoperability and wide implementation."
This seems a strange comment – since it is the richness that is essential for interoperability. I am reminded of a presentaton often used by SAFE software to explain their FME format translator. They noted that one could have a whole bunch of x to y translators ( a sort of n^2 problem) or they could have their rich geometric/semantic model – I think they called it a "Thick" pipe – their analogy for the richness of their internal proprietary representation – and that was essential to adapt to the systems at each end of the pipe and by extension to achieve interoperability. It is thus GML's "thick expressive pipe" that is essential to interoperability. At the same time it is clear that this presents developer's with implementation challenges, but hardly ones that are insurmountable. Moreover, profiles can play a role as can standardized application schemas for a particular domain (e.g. geoRSS  or AIXM GML).
It is interesting to note another of the author's complaints – namely:
"Although these rules can allow great richness in feature model descriptions, this richness doesn't necessarily help achieve other goals such as interoperability and wide implementation. From a GIS point of view, a FeatureCollection corresponds to a Layer. If a FeatureCollection contains endlessly nested levels of other FeatureCollections, this translates into one layer with endless sublayersâ€”not very good practice from a GIS point of view."
"Also, nonhomogeneous features inside a FeatureCollection do not correspond to the structure of a layer with homogeneous features"
We should note that layers are really a visualization or presentation construct (layers related to layers in the printing process). Early computer aided mapping and GIS systems directly bound layers in presentation to "layers in the data? – and this gradually migrated into the database architecture. Mapping to the world of GML a "GIS layer" is more the presentation of specific feature types as in the transport layer consisting of road, rail and ferry route feature types – and this is clearly enshrined as such in the OGC Styled Layer Descriptor (SLD).
The author appeals to a particular technology implementation when he invokes the terms GIS, rather than thinking about the nature of the real world. Do geographic entities not often have a hierarchical structure? Do they not often have multiple geometric characteristics? Why would the ability to express reality more adequately be a failing of GML. One might more correctly argue that existing "GIS" fail to capture important aspects of the geographic world. This is similar to the arguments made about object technology in the early 90's that it did not easily match existing flat data structures.
None of this is to say that profile are not important – we would argue that they are – but to recall T.S. Elliot's Murder in the Cathedral:
- "The last temptation is the greatest treason,
- To do the right thing for the wrong reason."