GeoTools : Feature Model Multiplicity Design

Remember this is a description of schema, no chantes to Attribtues are required. The fact that none are needed is a verification we are on the right track.

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.

Design Decision:

class ComplexAttribtueType {
   List<Schema> getSchema();
class FeatureCollectionType {
   Schema getMemberSchema(); // based on featureMember/featureMembers
class Schema {
   int getMinOccurs();
   int getMaxOccurs();
   List<Filter> facets();
class SimpleSchema extends Schema {
   AttributeType getType();
class ChoiceSchema extends Schema {
   List<Schema> choices();
class SequenceSchema extends Schema {
   List<Schema> sequence();
class AllSchema extends Schema {
   List<Schema> all();

(warning) The distinction I am going for is this; AttributeType referes to a real navigatable object, Schema refers to validation constraints.