pdowler
commented
5 years ago Quick analysis:
- In the code, the members are specified and stored using a list of observation URIs so the composite and members are already loosely coupled. Tools would have to navigate from the composite to the members and this would simple mean one or more navigation steps instead of a single step.
- in a database (TAP) query, one can join composites to simples via a join table that stores composite.id (UUID) and simple.uri (ObservationURI) and all persistence is managed when persisting the composite and composites can be persisted before the members (intentional: no foreign key). The only change here would be that a single join might yield a member that is a composite so an arbitrary number of joins or queries (navigation) would be needed to get from a composite to the simple.
So, this would not break any known/existing code at CADC. It could make output from user TAP queries behave differently (once content took advantage of this flexibility) but it seems unlikely anyone is doing such queries and relying on the fact that members are always simple now.
I think the actual change is just to the model so everyone knows this is allowed.
The current UML diagram indicates that the members of a CompositeObservation are always SImpleObservation(s).
Allowing other CompositeObservation(s) to be members would more clearly describe the intended aggregation of observations.