Description

The idea is to split the app-schema module in two:

• The first part would contain everything that helps with complex features in general: building them, evaluating filters against them (property accessor, x-path evaluation), building complex feature types from XSD. These classes do not rely on specific schemes like GML, etc... apart form XS.
• The second part will contain anything that is app-schema specific: the creating complex features through mapping files.

The second part would continue as the gt-app-schema module. The first part would split off and be merged with another module. This first part will more specifically, consist of the following classes that are now in the gt-app-schema module.

• org.geotools.util.ComplexAttributeConverterFactory
• org.geotools.filter.expression.FeatureProperty + complete org.geotools.feature.xpath package
• complete org.geotools.feature.type package
• complete org.geotools.feature package
• org.geotools.data.complex.filter.XPath (PARTLY)
• org.geotools.data.complex.FeatureTypeRegistry (PARTLY) + depending classes (for building types from xsd)

Considering the 'partly' ported classes.

• XPath - is just a class of different static methods that need to be split in two
• FeatureTypeRegistry will be made more generic using a helper interface 'FeatureTypeRegistryHelper, app-schema can have its specific implementation

This module relies on the module gt-app-schema-resolver (which also contains classes that are more general for complex features rather than app-schema specific).

There are four possible destinations suggestions:

• become part of gt-main
• become part of gt-data
• become new module gt-complex
• merge with gt-app-schema-resolver in to gt-complex

Note that the two options have as a side effect that gt-main/gt-data becomes dependent on gt-app-schema-resolver and everything it depends on, which might be undesired!

Status

This proposal is under construction.

Voting has not started yet:

• Andrea Aime
• Ben Caradoc-Davies
• Christian Mueller
• Ian Turton
• Justin Deoliveira
• Jody Garnett
• Simone Giannecchini

Tasks

This section is used to make sure your proposal is complete (did you remember documentation?) and has enough paid or volunteer time lined up to be a success

1. move all classes
2. refactor app-schema to use new featuretyperegistry
3. review documentation

API Changes

The API will not change because of this.

Documentation Changes