ISO Standard IDL Well Known Types and Structures

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.