Hello all
One of the last new classes that we hit in the upgrade to ISO 19115:2014
is "SV_Parameter" ("SV_" is the prefix used in the ISO standards, but
omitted in our Java API). The problem is that such parameter classes are
reinvented by many standards. I'm aware of 3 standards which define some
kind of parameters:
* ISO 19115 (metadata), for describing the input/output of a web service.
* ISO 19111 (coordinate be referencing), for describing the map
projection parameters.
* WPS (Web Processing Service), for describing in input/output of
processes.
* Probably more duplication exist in other standards.
I'm trying to merge the parameters API of those 3 standards in a single
API. The advantage would be that Java developers would hopefully have a
smother experience when dealing with parameters in a Java program. An
inconvenient is that developers who are more familiar with the XML
structure than the Java API may be confused.
There is a table summarizing the main properties of the 3 above-cited
standards and the proposed mapping between them:
http://www.geoapi.org/snapshot/javadoc/org/opengis/parameter/GeneralParameterDescriptor.html
The main difficulty is that we need to map Java class names to
"TypeName" structure that we are going to write in XML documents. OGC
defines something called "Definition identifiers in OGC namespace", but
the list of identifiers that I found is a little bit short and does not
cover exactly the Java types. For example they have "nonNegativeInteger"
and "positiveInteger", but I found no plain "integer". The solution that
I propose is to use the type names as they appear in OGC/ISO UML schema
(e.g. "Integer", "Real", "CharacterString", etc.). The following table
gives some examples. The most standard name (in my understanding) would
be the last column, but I think that the column in the middle would work
better for us:
https://builds.apache.org/job/sis-dev/javadoc/org/apache/sis/util/iso/DefaultTypeName.html
Is there any comment? To summarize, the choice is between:
1) No attempt to provide a unified parameters API: match exactly the
ISO/OGC classes without regards for duplication, so we do not have to
handle the mapping between the different standards (users may have to
handle the mapping themselves).
or
2) Attempts to provide a unified parameter API, at the risk that users
looking for an exact match for ISO/OGC standards may be a little bit
confused by the differences between ISO/OGC and our Java API.
The approach that I started to experiment is 2, so I can see that its
look possible. But it still possible to revert to 1 if peoples thinks
that it is preferable.
Martin
