Table of Contents:
- Aspects of a Feature Model
- Letter of Support
This document represents the ongoing design discussion centered around moving the GeoAPI and GeoTools feature model forward.
The goal is to support GML3, and provide a complete model for the definition generation of XPath expressions (allowing Filter, Expression and SLD to work).
For more details please see:
Aspects of the Feature Model
At a glance:
It seems disirabe that these IDs are stable across Application Models as well as GML docuemnts. A tall order.
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.
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.
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.
Name breaks down in the presents of super types, we require super types and thus cannot expect name to work in all situtations. However it is so direct we should include it in our API as a convience method.
Index based IDs do not work when used with super types, we require super types and thus cannot support them in the general case.
However: many applications call for a flat feature model, we may be able to prove those with simple data with a simple API to access it.
I recommend support indexed based access at the GeoTools level in order to ease migration pain. This can be accomplished by declariing a "FlatFeatureType" and "FlatFeature" model, so we can explictly model simple data.
XPath support at the model level is desirable from a client code point of view, however no implementations to date have managed to produce. Further more if we expect XPath to work our "chain" becomes only as strong as the weakest implementation. We would do better to have a strong Feature Model and construct our XPath support at arms length (using JXPath from Jackarta is the reccomended course of action).
There are downsides to this practice of making values typed by qualified anme, in GeoServer a lot of trouble is spent munging FeatureType/AttributeType information for writing - by strongly typing the players involved we are making the process more difficult (but more specific). We hope the trade off is worthwhile.
and support for is recommended for a simplified FlatFeature.
Nobody was interested in supporting multiple supertypes at this time. It should be kept in mind as a possible avuene for future growth (we should not for example support index based attribute access which would limit our support for this construct).
In GML their is a separation between subsitution type and Extention. It may also be useful to provide for super AttributeType as a way of capturing the use of Atomic types defined by XMLSchema.
The issue of super type may also be needed for handling complex, and even simple content. Gabriel has expressed a wish to capture the XMLSchema Atomic types and be able to explicitly reuse their restrictions.
FeatureCollection FeatureType contains a reference to allowable child FeatureType
FeatureCollection FeatureType contains a reference to several allowable FeatureTypes
Children represented as a "normal" attribute (of type features) with multiplicity
There is an attraction to representing child featues as a normal attribute (called "featureMembers"). It allows us to capture all the uses cases, it gives XPath generation a consistent model to work from (all attributes all the time with no special case for featureMembers). It is however impossible to tell the difference between this required featureMembers attribute and any other attribute of type FeatureType with a multiplicity. That may or may not be a good thing?
For now lets go with explicit modeling power at the cost of making XPath a little bit harder.
It is unclear if we need to separately define FeatureCollectionType (that extends FeatureType).
The OGC overview document also defines the FeatureCollection as having references to its children.
Parent references to child features. Often this is done by way of an expression that can generate the references (such as a
Children contain a back pointer to their containing Feature. This limits the modeling ability of a the system, as it prevents a child from being in more then one collection. And begs the question of why attribtues that are features do not have a back reference to their containing Feature (even though it may not be a FeatureCollection).
It should be pointed out that all known implementations have the reference reversed (Features contain a reference to their Parent FeatureCollection). This is probably a convience, but it does limit out modeling power (we cannot model a Feature as being part of more then one collection). Even in GML this is possible by use of references.
I have included the ability to "close" iterators (in case they have OS resouces they need to return), the practice was taken from JDO and is used by GeoTools.
Note this represents GML "infecting" our modeling system, we are explicitly capturing featureMembers with the features() method. Any XPath system will have to try a search for featureMember/*,featureMembersAtomicTypes
We considered making a SimpleAttribtue with helper methods for dealing with Interger, String and so on. We will wait to see how Gabriels need for AtomicType support shakes out.
Argument For FeatureType as a ComplexType: Feature represents content that can be navigated by xpath in exactly the same manner as a complex content. Whatever problems we run into with Feature we will also run into with complex content.
Argument for AttributeType refering to a FeatureType: Some of the concerns of AttributeType are not applicable to FeatureType (such as multiplicity for example).
Design Ideas (No Decision reached yet):
It is very tempting to make SequenceType extend AttributeType and provide a sequence() method, I am caught between making client code explicit (so they know what they are doing), and having he class heirarchy explicit. On the whole I think the decision below is the correct one. The convience method could always be added to as required.
The decision to represent FeatureType directly in the AttributeType heirachy is apparently a bad idea, someone is going to search through the geotools email list and hunt down Ian Turton's message that tells us why. Until then ...
We have a conflict between our type system for XPath (ie what is turned into a Node in a GML docuemnt, or an Object in our system), and what is required for validation. We have captured this below using Type and Schema to distingish between the two.
The distinction I am going for is this; AttributeType referes to a real navigatable object, Schema refers to validation constraints.
Ongoing design discussion, as we attempt to address the above concerns:
Feature Model Proposal
The final Feature Model proposal will be submitted to GeoAPI pending directory:
- Feature Model Proposal
- Support of Complex Content - a (poor) example of how this may be adapted to GeoAPI baseline
The following letter is being drafted as feedback to Gabriel (and his Sponser) by the GeoTools PMC:
-Feature Model Letter of Support