This section summarizes the design objectives for the Generic Frame Protocol, and how these objectives influenced the specification.
Simplicity: It is important to have a relatively simple specification that can be implemented quickly, even if that means sacrificing theoretical considerations or support for idiosyncrasies of a particular FRS.
Generality: The protocol should apply to many FRSs, and support all of the most common FRS features. For example, it should support all of the knowledge access and modification functionality that will be required by a graphical KB editor.
No legislation: The protocol should not require a large number of changes to an FRS for which the protocol is implemented. That is, the protocol should not legislate the behavior of an underlying FRS, but should serve as an interface between an existing FRS and an application.
Performance: Inserting the protocol between an application and an FRS should not introduce a significant performance cost.
Consistency: The protocol should exhibit consistent behavior across a set of back ends for different FRSs. That is, a given sequence of operations within the protocol should yield the same result over a range of FRSs.
Precision: The specification of the protocol should be as precise and unambiguous as possible.
Satisfying all of these objectives simultaneously is virtually impossible because many of them conflict, such as simplicity and precision, simplicity and generality, and generality and performance. The deepest conflicts, however, exist simultaneously between generality, no-legislation, performance, consistency, and precision, as the following example shows. To precisely specify the behavior of the function that retrieves the values of a slot, we must say exactly how the local values of a slot are combined with the inherited values of a slot (which may be inherited from multiple parent classes). That is, we must specify the exact inheritance mechanism that the protocol expects. Yet, different FRSs use a variety of different inheritance mechanisms []. For an FRS to conform to a precise specification of inheritance, it must either alter its inheritance mechanism (violating no-legislation), or emulate the desired inheritance mechanism within the implementation of the protocol (violating high-performance and generality, since the inheritance method used by that FRS is inaccessible through the protocol).
The preceding quandary is central throughout the protocol, and we know of no simple solution to the problem. We propose the following approach. Each knowledge base (KB) manipulated by the protocol is serviced by a single underlying FRS. The application must declare, at KB creation time, what set of FRS behaviors are to be associated with the KB for proper execution of the application. The application is stating what services it expects the FRS to provide for a KB for proper execution of the application. For example, the application might declare that it requires one of the two semantics for inheritance that we call incoherence and override, or that the application does not depend on either semantics. The Generic Frame protocol predefines a number of alternative FRS behaviors, based on the properties of existing FRSs. We expect that the set of behaviors defined within the protocol will grow over time.
At the time of declaration, the protocol determines whether the behaviors required by the application can be supplied. Those behaviors might already be present in the underlying FRS, or the protocol itself might emulate them on behalf of the FRS. In cases where one or more of the required behaviors cannot be supplied, the protocol issues warnings to this effect. It is important to note that we expect that every back end might not currently provide every possible behavior due to both the variability among FRSs, and the complexity of the Generic Frame Protocol. Chapter 4 describes behaviors in more detail.