Hi Martin, On 3/5/13 2:44 AM, "Martin Desruisseaux" <[email protected]> wrote:
>Hello all > >Le 03/03/13 22:08, Mattmann, Chris A (388J) a écrit : >> 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. >Right, I think that omitting synchronization is something to consider >seriously. +1 > >Right now the Geotk code has the Java "synchronized" keyword in it. The >proposed path is to first commit the code as it stands regarding >synchronization, then eventually remove the "synchronized" keyword. That >way, we would have a commit to revert if we want to restore back >synchronization. Yeah that's no problem -- I wouldn't consider it a revert just an update :) > > >> 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. >In the "Instrument versus Platform" that I gave, it was a relatively >straightforward "parent - child" relationship. But other ISO 19115 >elements may have more convolved relationship. For example in the >org.opengis.metadata.identification.Identification interface (derived >from ISO 19115 "MD_Identification"), is the "pointOfContacts" property a >subset of the "citation.citedResponsiblyParties" property including only >the instances having their "role" property set to "pointOfContact"? Yep that's harder lol. > >I realize that what I just said above sound obscure... I will come back >on those question on a case-by-case basis when the classes will be there. Makes sense to me, I get it! Cheers, Chris > > Martin >
