4.16. ISO Standard IDL
Many of the ISO and CORBA standard Interface Definition Language IDL data types and structures are summarized in Table 4-5. Most of these data types are common to the C++
programming language. IDL Name
Meaning short
16 bit signed integer long
32 bit signed integer unsigned short
16 bit unsigned integer unsigned long
32 bit unsigned integer float
32 bit floating point number double
64 bit floating point number char
one 8 bit text character string
sequence of 8 bit text characters, usually of unlimited length boolean
one bit data type enum
enumeration of all possible values union discriminated
union, containing different data types depending on a specified enum data type
sequence ordered list of data items or data structures, usually of
unlimited length struct
structure or record, containing specified list of data items, sequences, or lower level structures
any any data type, including any object identifier or any user
defined data type e.g., a name value list
Table 4-5. ISO IDL Data Types and Structures
Table 4-6 lists some other IDL terms with the terms used elsewhere for the same concepts.
IDL Term Other Terms for Same Thing
interface class, object
type operation
method, function, subroutine attribute member,
visible data
parameter argument, input, output
readonly attribute value can be read but not changed
in input argument or parameter
out output argument or parameter
raises defines which special exceptions can be raised by operation
when normal execution is not possible const
constant data value typedef
custom type definition comment delimiter, start of comment at end of line
Table 4-6. Other ISO IDL Terms
The Open GIS Abstract Specification Page 54
Volume 15: Image Exploitation Services 00-115 corrigendum
The Open GIS Abstract Specification Page 55
Volume 15: Image Exploitation Services 00-115 corrigendum
5. Future Work
5.1. Software Frameworks
The interfaces to each image exploitation service or category could be defined independently. If defined independently, the interfaces to each service or category would tend to use different
formats and contents for the same or similar data, used as inputs andor outputs of different services. However, it would be better if multiple service categories use interfaces that are defined to
use the same data formats and contents for the same or similar data, used as inputs andor outputs of different services.
Such use of the same interface formats and contents by multiple service categories means developing what is often called a software framework. A software framework defines standardized
interface aspects across multiple software components, where these components often provide different user services. Use of a software framework facilitates using multiple complementary
services together, including using different services in mix-and-match fashion.
A key issue is: How can the Open GIS Consortium OGC obtain multiple implementation specifications that fit into one or more software frameworks, to the maximum useful extent? More
detailed questions include: 1. Should the OGC request that vendors propose a software framework, or just trust that vendors
will propose a framework when appropriate? 2. If the OGC requests that vendors propose a software framework, should this request be in a
separate RFP, or in an RFP that also requests implementation specifications for interfaces to specific services?
3. If the OGC requests a software framework in an RFP for specific service interfaces, in which specific RFPs should a software framework be requested?
4. How should selected image exploitation services be combined into one RFP or separated into different RFPs to improve the probability and quality of proposed software frameworks?
Note that the taxonomy of image exploitation services groups these services into categories with similar interfaces. We hope that such a grouping of services will improve the probability and
quality of proposed software frameworks. For example, item 3 in Section 1 Image Modification Services includes many lower level services because they need somewhat similar interfaces.
Specifically, these Image Modification Services include many Change pixel values services item 3.1, many Change pixel positions services item 3.2, and many other services items 3.3 and 3.4.
Similarly, item 1 in Section 1 Ground Coordinate Transformation Services includes many services that should have largely identical interfaces. Also, Section 2 Image Coordinate
Transformation Services includes many services that should have largely identical interfaces. Furthermore, both ground and image coordinate transformation services should have largely
identical interfaces.