Captures the generic feature model from ISO 19109 with allowances for usability.

This feature model has been produced after review of the ISO 19109 specification, and a review of several java implementations. The goal of this package is to capture the type information for the "general feature model".

The following goals have been set:

- support reflection on application schema
- encourage the use of access via a Query lanaguage (provided by the Filter specification)
- capture enough information to permit the seamless handling models taken from XML specifications, in particular the use of sequence, choice and XPath access have proven a challenge.
- permit the definition of a SimpleFeatureType similar in spirit to the previous GeoAPI feature model in which accessor methods may be used directly and are based around simple Strings.
- use naming consistent with the ISO 19109 specification
- be consistent with common java usage conventions

## Type System

The following ideas are central to the functioning of this package as a feature model:

- Schema holds AttributeTypes by TypeName, these names are also available in a Namespace
- AttributeType is the base "Type" in the system, it is bound against a java Class and may be reused.
- AttributeType may indicate available operations using "OperationDescriptors", these descriptors have an OperationType describing their required parameters as list of AttributeTypes
- AttributeType contains set of Filters that are used to "constrain" the permissible value
- AttributeType is allowed to be an extention of a super type. This presents one known issue: the bound java classes may not be compatible even if in terms of modeling a subset is properly represented (An example is Integer representing a subset of BigInteger).
- ComplexType contains additional PropertyDescriptors describing attributes and associations with their multiplicity.
- FeatureType explicitly represents a spatial type, with additional information such as CRS and default geometry
- FeatureCollectionType indicates its associated member FeatureTypes with an AssociationDescriptor that is bound to a FeatureType.

There are some open questions:

- Should we make a structured property descriptor that holds is extended for attribute and association? This information should include the cardinality information, and would allow for an useful list to be returned for ComplexType getStructuredProperties(). This was in Bryce's proposal, however it has not yet been needed for implementation.
- Can an association type work against an non identified AttributeType?
  Since our current use is limited to FeatureCollection members we will not be able to answer at this time. If this proves true we will need to explicitly make an interface for IdentifiedType, right now it was only viewed as of interest to those doing persistence to XML or a database.

## Differences from ISO 19103 with respect to Naming

We have explicilty made the following break with ISO 19103:

- Name - we have adopted a simple definition of Name based on QName. The ISO implementation combined the responsibilities of naming with the implementation of a chained linked list of names. The result was heavy weight, and strange and has not proved intuitive.
- Namespace - implemented as Set, this is also a taged with its own Namespace. The ISO implementation combined the responsibilities of lookup with those of maintaining a namespace scope for a provided name (ie bidirectional link between Namespace and Name). The required backpointer prevented Name from being lightweight and has been removed.

As indicated above we have removed the "back pointers" required to navigate from Name to its "context", instead we have provided a URI which should be used with your lookup system of choice. This choice may in fact be Namespace (and is when working with TypeNames in a Schema), however the actual implementation should be provided by the hosting language in many cases.

There is room for improvement - If possible we would prefer to use the javax.naming.Name API and keep even less API around for these concerns. As it is we offer this as a recommendation.

For more details of this change please review the Name and Namespace interfaces which covers this in more detail.

## Differences from ISO 19109 with respect to General Feature Model

We have explicitly made the following break with ISO 19109:

- TypeName - we have separated out the concerns of TypeDefinition from TypeName, in ISO 19109 these were combined and caused great confusion when implementing.
- AttributeName - also seperated from AttributeType in a similar manner.

Numerous other changes have been made to leverage Java collection API where appropriate. These represent a direct mapping onto the language constructs and may or may not prove significant to those arriving from an ISO 19109 background.

## Relationship to ISO 19109 Primer

This work is greatly informed from a proposal included in the ISO 19109 primer - written by Bryce. In particular the requirement for operations, associations and detailed review of ISO19109, and EMF was a great asset. This primer also served as the only public documentation of the ISO 19109 material available for open development.

Differences from Bryce's proposal:

- Name, TypeName and Namespace as above
- Schema - we once again do not combine implementation with identification (the proposal for Package extended ScopedName). We have implemened a Schema class as a Map this works out nicely as the keySet ends up being the Namespace for the Schema.
- Factory and Type separation, we have explicitly not extended our type Schema class in order to make a FeatureFactory. A requirement of the type system is to allow for application supplied FeatureType creation, this is a seperate concern then modeling and grouping feature types.

The definition of Record and Name were unresolved at the time of this work and has not been integrated. In particular the definition of Name was taken as "too complicated".

We also disagreed with one of the goals of the proposal: convention that the creation of objects inside an application schema is the responsibility of the schema author. This goal is in conflict with our need to allow applications to create instances of their own devising. This need is particulary apparent when an application needs to ensure the use of a specific base class (for example to work with a persistence system Jaxtor, or modeling system like EMF).