ISO/OGC standards have the concept of "code list". Code lists are
similar to java.lang.Enum, except that they are extensible (users can
define new elements). ISO 19115 code lists and Enums are classes defined
in GeoAPI. Implementations like Apache SIS only use them.
Some new properties added by ISO 19115:2014 are new code lists. For
example there is a new property saying whether a Web Service (for
instance) is tightly or loosely coupled with its data, defined in GeoAPI
3.1/4.0-SNAPSHOT as below:
interface ServiceIdentification {
/**
* Type of coupling between service and associated data (if exist).
*/
CouplingType getCouplingType();
}
Problem is: the CouplingType code list is not yet available to the SIS
trunk (it is used by SIS development branches however). What should we
do on SIS trunk? Alternatives are:
1. Defines a copy of GeoAPI new code lists in Apache SIS,
2. or return java.lang.Object for now with a warning that the return
type will change in a future SIS version,
3. or omit completely for now all properties using not-yet-available
code lists.
I'm reluctant to go with alternative 1, because users would start to use
classes that are targeted for removal once GeoAPI 3.1 or 4.0 would be
published. Alternative 3 would be the safest, but users would not have
all ISO 19115:2014 information. Alternative 2 is a compromise (users can
use Strings or their own Enum for now), but admittedly an ugly one.
Below is an example of what looks like alternative 2:
https://builds.apache.org/job/sis-trunk/javadoc/org/apache/sis/metadata/iso/identification/DefaultServiceIdentification.html#getCouplingType%28%29
I wonder if we should go with alternative 3 for trunk (the properties
would continue to exist on the development branches). What do peoples think?
Martin
