GeoAPI 2.0 release content

This is an umbrella issue for discussion about GeoAPI 1.1 release content. Proposal is to include the following:

• org.opengis.util
• org.opengis.referencing
• org.opengis.spatialschema (even if incomplete)
• org.opengis.go

and exclude the following (for now):

• org.opengis.coverage
• org.opengis.catalog
• org.opengis.feature
• org.opengis.filter
• org.opengis.sld
• org.opengis.metadata

Note that some of those package will still present in snapshot. They would just be excluded from GeoAPI 1.1 release in order to avoid commitment about an API not yet fully reviewed.

Rational for ommission:

• Coverage API should be remplaced by ISO 19123 extended by Stephane's
  Fellah work (if peoples agree).

• Coverage API need to be revisited in light of latest specification (2.0).

• Feature, filter and SLD are currently under revision by their authors.

• Collection type in metadata may be changed. Furthremore, it has been
  reported that the ISO 19115 specification evolved since the metadata
  API has been initially created.

Some peoples reported that we should ommit geometries as well, because ISO 19107 is too complex and a simplier API should be selected for GeoAPI (namely "Simple Features" as implemented in JTS). I let geometries as part of release content for now, because I feel that ISO 19107 is the most "official" standard we have, that some peoples will actually need the extra ISO 19107 features, and changing the geometry model is likely to hurt GeoAPI (it would break its goal of standard compliance, replace an ISO model by a legacy OGC model with less capabilities, and would be a major compatibility break - we can do small incompatible changes, but this one is about replacing the whole geometry package). I would like to try to handle ISO 19107 complexity though documentation, convenience factory methods, and annotation for different compliance level. However, if peoples feels that we really need a simplier API, please open a JIRA task for discussion. We could push back GeoAPI 1.1 release if we realize that this topic need discussion.

Some peoples reported that they would like to experiment independant implementations of org.opengis.go before it become a specification. The org.opengis.go package still a particular case since its is not backed by an independent specification, but is defining a specification in itself. We are still gaining experience with GO-1. We can use this JIRA task in order to discuss about GO-1 roadmap, if peoples wish to share opinions. An important concern is the degree of freedom allowed for API changes after GO-1 become a specification. The same concern applies to the rest of GeoAPI after a 1.1 release.