Hello all
There is some notes about the ongoing work in the
org.apache.sis.metadata package [1]. There is some aspects inherited
from Geotk, and others than I'm reconsidering. The main points inherited
from Geotk are:
* MetadataStandard represents a standard (mostly ISO 19115 for now)
defined by a set of interfaces.
* AbstractMetadata provides default implementation of equals(Object),
hashCode() and toString() using Java reflection. ISO 19115 alone
will about 100 classes, some of them with lot of properties, so
defining the above methods manually for each of them is quite
tedious. Using reflection also allow others things like providing
java.util.Map views over the metadata (not yet committed).
* ModifiableMetadata is an AbstractMetadata subclass with some utility
methods for the subclasses which are going to provide setter methods
in addition to getter methods. The utility methods is mostly about
copying the content of another metadata, getting an unmodifiable
copy of a metadata, and instantiating collections only when first
needed. The later could be seen as mechanic for subclasses only.
* The KeyNamePolicy, NullValuePolicy and TypeValuePolicy enumerations
control the behaviour of java.util.Map views (not yet committed).
The only "real metadata" example available at this time is
DefaultCitation. However the ~100 other metadata classes would be
similar to DefaultCitation, after the MetadataStandard /
AbstractMetadata / ModifiableMetadata foundation are sound enough. If
there is any thing to revisit, please let me know (the above classes are
not final, and tests are not yet committed).
Some aspects that I'm considering to revisit are:
* Synchronization strategy: if one looks at DefaultCitation, we can
see that all all getter and setter methods are synchronized. I'm not
sure that it is the more appropriate choice... Alternatives are no
synchronization (not necessarily a bad idea, it really depends how
we use metadata), or synchronization using
java.util.concurrent.lock.ReadWriteLock. The later approach is more
costly, so it could be selected only if the metadata are used in a
way that justify it. I don't have a clear answer to this question
yet. I'm trying to investigate how metadata are actually used in the
projects I'm aware of, in the hope to figure out what could be the
most appropriate synchronization strategy.
* "Intelligence" in metadata: right now, the metadata implementations
are just containers. However relationship exists between some ISO
19115 elements. For example the ISO 19115-2 MI_Platform.instrument
property [2] is a collection of instruments mounted on the platform,
and each instrument has a MI_Instrument.mountedOn property [3] which
point back to the platform on which the instrument is mounted.
Obviously setting the MI_Platform.instrument property has
implication on MI_Instrument.mountedOn, and conversely. There is
many other places in ISO 19115 metadata where one property could be
inferred from other properties. But Geotk does not have any
"intelligence" like that. I'm thinking about, possibly, putting such
"intelligence" in SIS. However sometime trying to be too clever is
counter-productive, the risk being that some rules may be too arbitrary.
I'm not really looking for an immediate answer to the above. They are
questions that may be explored progressively. But though are always welcome.
Martin
[1]
https://builds.apache.org/job/sis-jdk7/site/apidocs/org/apache/sis/metadata/package-summary.html
[2]
http://www.geoapi.org/3.0/javadoc/org/opengis/metadata/acquisition/Platform.html#getInstruments%28%29
[3]
http://www.geoapi.org/3.0/javadoc/org/opengis/metadata/acquisition/Instrument.html#getMountedOn%28%29