Thanks Martin. I think the unified API approach sounds pretty good. Anything that can be done to help prevent complexity (or more complexity) is preferable.
Adam > On Sep 14, 2014, at 7:48 PM, Martin Desruisseaux > <[email protected]> wrote: > > 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 >
