No Subject

The primary problem we have with the struct definitions is that structs, in IDL, do not support inheritance.  Thus, we can not make our structs directly reflect the information model.  Thus, we must make design tradeoffs in defining one or more structs 
that carry the information AND defining one or more interfaces that provide the operations.
I think that defining multiple structs (a la Tim's suggestions) provides a more transparent mapping of the info model into the struct IDL.  It may (or may not) be more efficient (depending on the ORB vender's implementation of ANYs since we have ruled 
out the use of UNIONs for not allowing easy extensibility).
I am also uncomfortable (along Dave's line of argument) with operations returning ANYs containing structures of ANYs.  Not only is the final code (after applying all of the typedefs) not self-documenting, but there may be performance problems, and the 
Server and Client developers lose some control over their programs, as all ANYs are managed by the ORB (you have to ask the ORB for an ANY when you want a new one).

What is the real problem here?  We want to communicate complex hierarchies of structs without explicitly defining the struct at each level of the hierarchy, i.e. we want Composites to contain both Composites and Atomics.  What we have currently defined 
in the COAS IDL is a recursive struct that combines all the attributes in Observation, CompositeObservation, and AtomicObservation, except for the containment of references to ObservationReference.  This makes the struct heavier than either Composite or 
Atomic, and it loses the advantages that inheritance provides in the information model, separation of disjoint information and operations between the composite and atomic objects.
Tim's suggestion, enumerate various mixings of the Observation, CompositeObservation, and AtomicObservation, leaves the choice of the specific mix to be used up to the developer, and provides for more extensibility in the mix.  With this design style, it 
is possible to separate the information of the composite and atomic objects (as in Tim's three example structs).  This solves the encapsulation of information problem, but it does not address the struct naming and IDL readability issues.  We still end up 
with the Composite structs containing sequences of ANYs, both for Observations and for Qualifiers (and for References?!).

I suspect that we will always end up with either a recursive struct or structs containing sequences of ANYs (unless we go with Object-by-Value) because we can not solve the problem of either the structs not supporting inheritance, or the separation of 
operations between Composite and Atomic observations when using struct based interfaces.  Thus, I think we should decide which is the least objectionable design, and go with that for the time being.  So, proponents of each side, make out your lists of 
PROs and CONs, and let us share them, either at the next OMG meeting, or at a separate COAS FTF meeting (I am assuming that e-mail, while wonderful for distributing information, is not the best medium for reaching consensus on this issue).

I think we should also look closely at the definitions of the ObservationRemote related interfaces, and ask if we should add any/other attributes or operations that support the separation of Composite functionality from Remote functionality 
(particularily for Qualifiers and References, but also for Observations).

If anyone has a solution to this problem (e.g. throw away the struct based interfaces ;-), please speak up.

Chuck

P.S.  My new e-mail address is Charles.Carman@philips.com