Re: [COAS-List] Proposed ObservationData IDL

[Tim Brinson <TBrinson@mindspring.com>]

David Forslund wrote:

> Just two comments for people to note:
>
> This change results in no ObservationData object when the IDL is mapped to
> the language since it is an Any.

The CompositeObservationData and AtomicObservationData replace the need for the
old ObservationData type.  If you still want that struct just create it and call
it something like SiameseObservationData (since it has two heads :-).

The structs in the proposal I made are for discussion purposes.  If you want the
old do everything struct you can still have it.  The reason it was needed before
is because it was bound to the operations and structs don't have inheritance.
When the return type is an Any it allows you to use a more natural mapping of
composite and atomic observations to their own types (as they are in the
information model).  This is good!

Notice the ObservationQualifier type is still a typedef of ObservationData.  In
the structs that type is spelled out explicitly for the qualifier fields (since
we get out of the self referential limitations of the struct).

My main concern is the return type on the operations should be an Any.  I am
very flexible on the set of observation data structs to be defined for COAS
1.0.  The ones I sent before were just a proposal to get some discussion.  There
were a minimal number that provided full flexibility but also efficiency for
simple atomic observations.  It also gave flexibility to define special
observations in localized environements that can be much more efficient and the
flexibility to use other ORB defined types in the future (such as ValueTypes,
a.k.a. Objects By Value).

Do you have any suggested observations structs for COAS 1.0?  Are you suggesting
to add a SiameseObservationData (or call it what you will) to the ones I
proposed?  Or to replace them?  Something like:

    struct SiameseObservationData {
        QualifiedCodeStr code;
        sequence<SiameseObservationData> composite;
        sequence<SiameseObservationData> qualifiers;
        sequence<any,1> value;
    };

> Second, I thought the submitters were concerned about the performance of
> Any which is why they only used it
> for the ObservationValue so that all navigation could be done with the
> struct.  With this proposal, everything is coming across the wire as an Any.

Has anyone done a comparison?  In one case you are describing the structure with
a TypeCode and the other you are describing the structure using
SiameseObservationData.  I can find examples where one is more efficient than
the other and vice versa.

> These are just issues to think about.

Thanks for bringing them up.


Tim





> >         typedef any ObservationData;
> >         // This is the type bound to the operations.
> >         // COAS 1.0 ObservationData can only be one of the 3 structs
> >defined below.
> >
> >
> >         struct CompositeObservationData {
> >                 QualifiedCodeStr code;
> >                 sequence<ObservationData> composite;
> >                 sequence<ObservationQualifier> qualifiers;
> >         };
> >
> >         struct AtomicObservationData {
> >                 QualifiedCodeStr code;
> >                 any value;
> >                 sequence<ObservationQualifier> qualifiers;
> >         };
> >
> >         struct SimpleObservationData {
> >                 QualifiedCodeStr code;
> >                 any value;
> >                 ObservedSubjectId observed_subject;
> >                 TimeSpan time_span;
> >         };
> >