Issue 3042:  COAS operations that return ObservationData                                                                                                                                                            (coas-ftf)
Source: 2AB (Mr. Tim Brinson, tbrinson@2ab.com)
Nature: Uncategorized Issue
Severity: 
Summary: The COAS operations that return ObservationData are locked into using a
structuring mechanism that is defined as a stop gap solution due to the
lack of extensive support for the ValueTypes by ORBs today.  This
proposal addresses that problem by suggesting a simple change that
allows the same COAS operational interfaces to be used in the future
with ValueTypes (or additional types that may be created for IDL in the
future).

I propose that the current ObservationData type be renamed to
ObservationDataStruct.  Any data types that reference ObservationData
would then reference ObservationDataStruct (with the exception of
ObservationDataSeq).  A typedef for ObservationData being of the type
"any" would be created as such:

    typedef any ObservationData;

In this way observations are passed by value via the "any" type
(actually a typedef to the "any" type) in the operations which frees up
the possibility of using ValueType (and other type) definitions for
observations in the future or by local agreement in specialized
environments.

In addition a new Conformance class (e.g. "Structured COAS") should be
created that indicates a server uses the ObservationDataStruct as the
explicit type returned/passed in via the ObservationData in operations.
This allows future standardization using value types in which additional
conformance points can be made for other structuring used by servers.
Note these conformance classes are independent of the conformance
classes specifying which interfaces a server implements.

Resolution: resolved in COAS FTF
Revised Text: 
Actions taken:
November 17, 1999: received issue
November 7, 2000: closed issue
Discussion: 

End of Annotations:=====
Date: Wed, 17 Nov 1999 13:31:24 -0800
From: Tim Brinson <TBrinson@mindspring.com>
Reply-To: TBrinson@2ab.com
Organization: 2ab
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: issues@omg.org, coas-ftf@mindspring.com
Subject: COAS Issue
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
X-UIDL: ]3\!!$<K!!ILV!!^I\!!

The COAS operations that return ObservationData are locked into using
a
structuring mechanism that is defined as a stop gap solution due to
the
lack of extensive support for the ValueTypes by ORBs today.  This
proposal addresses that problem by suggesting a simple change that
allows the same COAS operational interfaces to be used in the future
with ValueTypes (or additional types that may be created for IDL in
the
future).

I propose that the current ObservationData type be renamed to
ObservationDataStruct.  Any data types that reference ObservationData
would then reference ObservationDataStruct (with the exception of
ObservationDataSeq).  A typedef for ObservationData being of the type
"any" would be created as such:

    typedef any ObservationData;

In this way observations are passed by value via the "any" type
(actually a typedef to the "any" type) in the operations which frees
up
the possibility of using ValueType (and other type) definitions for
observations in the future or by local agreement in specialized
environments.

In addition a new Conformance class (e.g. "Structured COAS") should be
created that indicates a server uses the ObservationDataStruct as the
explicit type returned/passed in via the ObservationData in
operations.
This allows future standardization using value types in which
additional
conformance points can be made for other structuring used by servers.
Note these conformance classes are independent of the conformance
classes specifying which interfaces a server implements.


Tim Brinson