A Feature ID in a GML document is required to be unique. However in the OGC Feature model a Feature ID is supposed to always to refer to the same physical construct in the real world. The "effiel tower" is unique and there is only one actual thing refered to by that ID. For different applications various sets of attribtues may be used to model the "effiel tower".

It seems disirabe that these IDs are stable across Application Models as well as GML docuemnts. A tall order.

(star) The concept of an ID that is generated external to the attribute model matches our understanding of the problem.

Generating the ID from a KEY column in your database seems to be an implementaiton detail, as long as the column is not part of the published schema of attribtues nobody needs (or can) know). This is the same conceptual model as the use of ID above.

Using more then one key in this opqaue fashion does not change matters.

By using a key attribute column to generate our ID while making that value available as an attribute is scary. The worst case senario is that the ID may be modified.

Same drawbacks as the use of a single key attribute column.

It is worth pointing out that in a real world system any of the differnt "Identiy" Analysis Patterns are subject to pros and cons. For example the same physical object could be registered in two different remote users applications. When these users sync with the server applicaton the concept of identity will need to be resolved, further more is a system with archival needs (for lawsuites) these changes of identity will need to be tracked, and traceable.

For now all we can do is build the model for other subsystems to work against, a system that requries management of identity as outlined above will need to take responsibility for the generation of Identity and the management there of.

In GML, in order to allow a Feature to appear inside another Feature, or in more then one collection referneces may be used. XML also allows validation constraints based on unique and id (that is unique and required) - I suspect these XMLSchema facilities may have muddied the waters of understanding.

Design Decisions:

interface Feature {
  String getID();
}

(warning) Genreation of IDs is considered to be implementation, or application specific. At worst we will need a FIDSequence interface to generate new IDs as required. Currently GeoAPI leaves generation of ID up to the feature source (as such IDs are not available until after a commit). GeoTools fakes it with QA rather then as an explicit part of the workflow.

(warning) It has come to our attention that the concept of ID is also used by GML Geometry to allow for either externaly defined Geoemtry, or shared Geometries.