The SAIF data model and the SAIF standard schema emphasize object structure. SAIF does not address explicitly the notion of methods or services, i.e., operations which can be performed on objects in a class, usually in response to some external message or request. Methods are considered as outside the purview of SAIF because of several reasons: (i) they are not required for data exchange, (ii) specification of the methods would be complex, (iii) those using SAIF, as a common data model for example, are free to add methods in the context of their programming language, database query language or interoperability specification. Nevertheless, a user may define a subclass because of behavioral or functional reasons.
Consider a method which determines whether an object is a member of a set, or another method which transforms the spatial data from one projection to another. A transmittal of data from one party to another should not be burdened with the overhead of moving these methods with the data. If a geographic information system is being built around SAIF, say in C++, the developer may have some very specific methods which he or she wishes to implement. This can be done as an extension to SAIF, but it would be of questionable value to transfer such methods with the data every time a data transfer occurs.
The ISO SQL/MM Spatial work is aimed at defining how spatial and spatiotemporal information will be addressed by databases. Expressed in SQL3, it borrows heavily from SAIF, but adds a number of functions to the type definitions. The Open Geodata Interoperability Specification (OGIS) is being designed to enable communications among geoprocessing applications. It includes a Virtual Geodata Model which is closely related to the SAIF - ISOSQL/MM Spatial model. Functions are an integral part of this work as well. Additionally, OGIS includes an Application Programming Model to specify a series of services which operate on the data.