Hey Martin, On 3/3/13 12:46 PM, "Martin Desruisseaux" <[email protected]> wrote:
>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). +1 sounds good to me. > >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. I would be in favor of no synchronization yet. Let's let concrete use cases drive the implementation of potentially complex and possibly costly behavior. Until we have one, let's just keep it simple for now. > * "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. Yep we have relationships like this in the Tika Metadata object (creating a new Metadata object creates an internal object, which in turn needs to be mapped back to the parent metadata object). These reflexive relationships make sense to add intelligence to set the appropriate hooks. +1 to that. Cheers, Chris > > >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/metadat >a/package-summary.html >[2] >http://www.geoapi.org/3.0/javadoc/org/opengis/metadata/acquisition/Platfor >m.html#getInstruments%28%29 >[3] >http://www.geoapi.org/3.0/javadoc/org/opengis/metadata/acquisition/Instrum >ent.html#getMountedOn%28%29 >
