Steps Toward a World Wide Digital Library of Formal Algorithmic Knowledge

ness: This means abstractness with respect to object identifiers (see Abstract Ids & Closed Maps (section 4.4.1) and Abstract Identifiers (how) (section 4.4.4)). When a closed map is uniformly renamed or is retrieved from the FDL, which is only guaranteed modulo renaming, there is no rechecking of certificates; they are treated like any other objects. Suppose, for example, that during a session, a person goes out or their way, and against advice, to store a program whose execution depends on the concrete values that happened to be used in that session for object ids, and has the system execute that program and certify a result. Then if that current closed map is saved and reloaded (modulo name change) in a later session, that certification object will cease to entail that the old connection between the program and result has been preserved. 104 CHAPTER 4. WORKING NOTES ON FDL DESIGN Monotonicity: Similarly, suppose one wrote a program whose execution involves a heuristic search of the whole current closed map, whatever it may be at execution time. Then executing the same program on a extension of the same closed map may well have different results, thus a certification of the result of executing in one closed map will not certify the result in an enlarged closed map. But, again, the system will not modify a certification object when the current closed map is enlarged. Locality: Locality of a claim based on a certificate is dependence of that claim only upon the certificate and objects referred to by the certificate. A localized claim will also be monotonic since extending the map doesn’t change what a localized claim about a certificate depends on. Suppose that one cuts down the current closed map to a submap by Contracting or Focusing (see Closed Map Operations (section 4.4.2)). For example, suppose one picks a certification object and Focuses on it, deleting every object that is irrelevant to it (ie, no reference path between them). The certificate will not be modified or checked. The problems are the same as for monotonicity above. See Conservation and Destruction (section 4.4.3) for a list of some closed map operations that leave certificates intact. 4.5.4 The Significance of Certificates The “internal” significance of Certificates (section 4.5.1) in a closed map is determined by the policies for how they are created, deleted and altered. Some policies for the effects upon certificates of various closed map operations are suggested in Certificate Bias and in Conservation and Destruction (section 4.4.3). Thus, the existence of a certificate in a current closed map directly indicates merely that at some time it was created in a current closed map according to a creation-policy implemented for that kind of certificate, and has not been deleted by various subsequent alterations of the current closed map, and that any alterations to the certificate’s content has been according to the policy implemented for certificates of its kind. As usual with formal and computational data, further significance is attached externally based upon understanding the “internal” significance. The only general policy for changing certificate content that we currently expect to adopt was alluded to in Certificate Bias (section 4.5.3); the system 4.5. RECORD KEEPING 105 can change the content of a certificate by marking it as “stale” and possibly deleting object references within it to no-longer extant objects. Such a vestigial certificate thus signifies merely the past existence of a certificate having certain content. These vestigial certificates will, therefore, tend to have little formal value, and are expected to serve as hints about previous situations, which may have some heuristic value. See Certificate Structure (section 4.5.6) and Stale Certificates (section 4.5.9.2) for detail on certification policy. A simple content alteration policy, one might deem it the default, is extreme sensitivity to the content and number of objects referred to by the certificate. It is this: if the content of any object the certificate refers to is changed, then the certificate must be deleted (or its content must be altered to mark it vestigial); its fate will be the same should multiple references within the certificate get “identified,” by Folding (section 4.4.2), say. For example, if a proof “goes bad” because of some alterations to underlying content, say a change of definition or deletion of an inference rule upon which it depended, or through forced identification of two “primitive” notions, then the objects certifying it as a well-formed proof (according to whatever standards) will be deleted or marked as stale. If they are altered to these vestigial forms rather than deleted, they may be useful in further attempts to attach new certificates to the proof. A more permanently useful vestigial certification would be a certificate of object creation. An object creation certificate might be implemented to indicate that an object it refers to was created at a certain time in a certain Session. Then, as we can infer from the general policies mentioned above, a vestigial certificate of this kind still signifies that the object was created at the specified time but may have undergone a change of content. So some vestigial certificates do retain their significance. One might also implement kinds of certificates that are insensitive to some alteration of content in referenced objects. For example, one might adopt a criterion for mere annotation of programs or formal data that does not affect correctness, and leave “annotation insensitive” certificates intact if objects they refer to are altered merely in their annotations. Returning to external significance of certificates, it is also possible for us to be mistaken or in disagreement about the external significance we have attributed to a kind of certificate. This lies beyond the responsibility of the closed map management system. For a scenario exploring this situation see Conflicts of Significance (section 4.5.5). The most important promise implementors can make with regard to cer106 CHAPTER 4. WORKING NOTES ON FDL DESIGN tification is that the policy for creation and update of each kind of certificate is permanent, once implemented. If a new policy is needed or desired, a new kind of certificate must be implemented. 4.5.5 Conflicts of Certificate Significance a Scenario Continuing the discussion of internal and external significance of certificates begun in Certificate Significance, it is possible for us to be mistaken or in disagreement about the external significance we have attributed to a kind of certificate. For example, suppose we have employed a kind of certificate for generating or verifying formal inference steps; the certificate policy might go something like this: invoke a specified inference engine, building it first (perhaps compiling its code) if need be, and apply it to an inference step object in the current closed map; if the inference engine says the step is “good,” create the certificate, whose content will refer to the inference step. This is the “internal” significance. External significance to some persons might comprise the conformance of the inference step to a certain independently understood class of inference rules. For a person who judges all these rules to be correct, the external significance may further comprise the validity of the certified inference step. Of course, maybe it will be later discovered or suspected that the inference engine is flawed and doesn’t simply implement the inference rules it was thought to implement. Then that external significance is lost. Let us continue with this example of the flawed proof engine, and consider a recovery scenario. Suppose that further study and improvement of the inference engine leads to the judgement that there is an easy bug fix, and that there is a simple test that detects at least the bad inferences that the older version of the engine erroneously okayed. Now we have fallen into doubt about already certified proofs. One simple fix is to employ a similar form of certificate, the difference being that it invokes the new engine rather than the old one, and simply try to certify all the old inferences with the new form of certificate. The old certificates need not be deleted, although perhaps they may be eventually. Consider now a more sophisticated scenario. Stipulate a form of certificate that is created this way: given an inference step, first look and see if there is a certification for it (pointing to it) of the old sort that uses the defective engine; if there is no old-engine certificate then use the new engine; if there is an old-engine certificate then apply the test for possibly-bad inferences 4.5. RECORD KEEPING 107 postulated above for this scenario; if the inference is possibly-bad then use the new engine, but otherwise, simply point to the old-engine certificate. If there were many proofs with the old engine but the bulk of inferences were okay according to the new test, and if running the engine is often expensive, then this method could represent a significant efficiency as a corrective. Let’s do a quick survey of when these various certificates are appropriate. Let’s also make the more interesting assumption that whether the engine is flawed is not agreed upon by all parties. Persons who think the old engine was correct will still accept the old certificates with their original significance for correctness. Persons who think the new engine is correct and that the test for possibly-bad cases is an accurate assessment will accept both new-engine certificates and also the hybrid certificates that depend on the old engine. Persons who think the new engine is correct but don’t trust the test for possibly-bad cases will insist on the simple new-engine certificates. All these certifications can coexist, even if their external significances are in dispute. 4.5.6 Certificate Structure and Internal Significance Continuing from the discussion in Certificate Significance (section 4.5.4) we elaborate upon what counts as a certificate, and how certification procedures are determined by certificate content. Before getting specific, let us sketch the design. The principal, dominant form of certificate indicates two Native Language programs, the first being the procedure invoked to create the certificate (and others like it), and the second being a procedure to be applied when “reconsidering” (section 4.5.9.1) the certificate later. These native language programs are pointed to by the certificate, and to understand them along with understanding the general method for reconsidering Stale Certificates (section 4.5.9.2) is to understand the “internal” or direct significance of the certificate. In order to facilitate Borrowing Certificates (section 4.5.2), we admit a special kind of certificate that has the same content as a normal “native” certificate, but which cannot be updated and can be created only by copying from a foreign FDL. A third kind of certificate-like object is a “certificate identifier” which may exist in the FDL ab initio, but is a distinguished object created as part of the FDL in order to identify other certificates by their content. The unifying characteristic of these certificates is that their content is strictly regulated by the FDL, unlike ordinary objects whose content is whatever the Clients make it. We defer discussion of Certificate Identifiers (sec108 CHAPTER 4. WORKING NOTES ON FDL DESIGN tion 4.5.8), stipulating here that the FDL classifies each certificate identifier as either “native” or “borrowed.” Both native and borrowed certificates of the ordinary kind, ie not certificate ids, have as content a Text whose operator consists of two object references, the first being a certificate identifier and the second being a reference to an appropriate code specifying object. The intention is that this second object contain the Native Language programs for creating and updating certificates referring to it in this way. This pair 〈C, K〉 of references constituting the certificate contents’ operator may the considered the certificate “kind,” and it can never be altered in an object once created. The content of K cannot be altered as long as K is part of the certificate kind for any existing certificate; this policy is part of what makes the FDL trustworthy. If you want better code and the old code still matters to someone, you must make a new object K ′ and employ a new certificate kind 〈C, K ′〉. A certificate with kind 〈C,K〉, where C is a native-certificate identifier, can only be created by interpreting the first subtext of object K, applied to some specified arguments. If this execution returns a Text T , then a new object is created whose operator is 〈C, K〉 and whose first subtext is T . There may be other subtexts as well indicating generally useful information as determined by the FDL implementors, such as dates or other transaction related data. How the native language program is interpreted is determined by the C in a way inherent to the FDL process. Thus, within an FDL, there may be multiple native language interpreters indexed by the certificate id. If one needs to add a native language to an FDL or improve a native language of an FDL, then a new certificate identifier should be introduced for the new interpreter. Once an interpreter is employed it must be unaltered if clients are to be able to trust the FDL. Similarly, different FDLs may have different implementations of a native language, perhaps with different execution results either intentionally or accidentally, or may support different native languages. Thus, native certificates must never be transferred as such between FDLs if client trust is to be maintained. A certificate with kind 〈C, K〉, again where C indicates native, can be updated only under circumstances explained in Stale Certificates (section 4.5.9.2). Then the second subtext of the content of object K is executed as a native language program according to C, applied to arguments as stipulated in Stale Certificates (section 4.5.9.2). If the procedure returns a text, then that becomes the new first subtext of the extant certificate. Again, any other subtexts are updated as the FDL implementors choose. We shall consider 4.5. RECORD KEEPING 109 Borrowed Certificates in more detail. 4.5.7 Borrowed Certificates In Certificate Structure it is explained how creation and update code are determined for “native” certificate identifiers. Here we explain how certificates are borrowed from other purported FDLs. A certificate with kind 〈C, K〉, where C is classified by the FDL as indicating a borrowed rather than a native certificate, cannot be updated – reconsideration of borrowed certificates always fails, which means that if they get in the way they should be replaced by native certificates. When one wishes to locally “re-establish” a borrowed certificate, one requests the creation of a native certificate stipulating a native certificate id C ′ which one thinks will execute the native code of K similarly to the way the foreign FDL is supposed to have interpreted it. FDLs that hope to cooperate and share Clients would do well to provide a standard collection of similar native languages and interpreters; multiple instances of a common implementation will, of course, minimize coding in this regard. A certificate with kind 〈C, K〉, where C is a borrowed-certificate identifier, is created by Merging (section 4.4.2) a Closed Map from a foreign FDL into the local FDL. When a merge is attempted one specifies a correspondence between objects that should be identified. If one stipulates that certificate id C in the local FDL is to be identified with C ′ of the foreign FDL, then the merge fails if any new certificates of kind C would have gotten imported; ie, foreign certificate ids can only be identified with native certificates ids if the certificates depending on them were already in the local FDL. How can a cross-FDL correspondence between identifiers, certificate identifiers in this case, be established when each space of identifiers is “internal” to its own FDL? In general, a Client of an FDL might establish an association between abstract identifiers of the FDL and other values (which might themselves be either concrete values or abstract identifiers), by storing in the FDL a text serving as a table pairing the values with the abstract identifiers. One FDL, say A, could borrow from another FDL, say B, by becoming its Client and creating two tables, one in A and another in B. One concrete value for each cross-FDL abstract id pair would be generated, and these values would mediate the two tables in A and B. Establishing such cross-FDL abstract identifier correspondences, to facilitate certificate borrowing or other content sharing more generally, should 110 CHAPTER 4. WORKING NOTES ON FDL DESIGN be so common that it should be “internalized” as an FDL service and obviate the need for exposing the intermediate concrete values that coordinate cross-FDL pairings. Further, significant efficiencies are likely in explicitly recognizing a mutual client relationship between FDLs. Hence there is a special role for FDLs as clients of other FDLs, essentially supporting federation, that is worth making efficient. 4.5.8 Certificate Identifiers The content of a certificate identifier is a Text whose operator is simply a reference to itself, and the subtexts, if there are any, may contain whatever is convenient or necessary to execution of Native Language programs as explained in Certificate Structure (section 4.5.6). The content of certificate identifier cannot be changed as long as any certificates mention it, hence the certificate identifier serves as an authentic indicator of how the certificates referring to it were established. The classification of an abstract identifier as a certificate identifier must be inherent to the FDL, as is its further classification as indicating normal certificates as opposed to indicating Borrowed Certificates (section 4.5.7). Certificate identifiers for borrowed certificates must be bound by the FDL to a Process Identity Certificate (section 4.7) for a foreign FDL, and to a cross-FDL abstract id correspondence as described in Borrowed Certificates (section 4.5.7). 4.5.9 Updating Certificates It is possible to manage the modification of certificate objects by methods specific to the kind of certificate. The point is that when large numbers of inter-related objects are created by means of automated procedures, such as proof generators, it will often be desirable to create slight variants of large data that should have rather localized effects. An economy can be achieved when this localization can be effectively detected and managed automatically. Of course, one is always free to stipulate kinds of certificate that are unmodifiable once created. 4.5. RECORD KEEPING 111 4.5.9.1 Altering Certificates In Current Closed Maps (section 4.5.2) we specified some operations on the current closed map considered “conservative.” Conservative operations are simple, whereas other operations force reconsideration of some Certificates (section 4.5.1) which may have become “stale” as a result. The assumption here is that certificates are normally intended to attest to some facts about the contents of, or identity between, objects and so may fall into doubt when those change. Rather than simply deleting or discounting certificates that become doubtful, we anticipate a more incremental processing of doubtful certificates that might rehabilitate some certificates or even leave them intact. The presence of stale certificates in the current closed map corresponds to an “inconsistent” state in a database, and part of completing an operation on the current closed map is to eliminate staleness. Reconsidering a certificate can result in its modification or deletion, which can force reconsideration of further certificates that depend on it, and so a protocol is needed for resolving these cascades of certificates going stale. See Stale Certificates (section 4.5.9.2). As explained in Certificate Structure (section 4.5.6), to implement a kind of certificate one adopts a procedure for creating new certification objects of that kind, and a procedure for reconsidering a certificate. When a reconsideration procedure for a certificate is executed to (successful) completion, the certificate object is either left intact, updated, or deleted. These certification procedures, in addition to creating certificates or modifying contents of “reconsidered” certificates, may create or delete other objects, and may alter the contents of non-certificates. But some basic operations may have cascading consequences on the FDL, beyond the control of any specific certification procedure: • Execution of a certificate creation procedure is a basic operation on the current closed map, and the content of the certificate will include an indication of its kind. Creation procedures can take arguments supplied at execution. The indication of certificate kind is beyond the reach of the certificate creation procedure stipulated for the kind itself, and is controlled by the system. 112 CHAPTER 4. WORKING NOTES ON FDL DESIGN • Execution of a reconsideration procedure for a kind of certificate is a basic operation that can be applied to any extant certificate of that kind. Again, the content cannot be altered to omit the fact that it is a certificate of its kind. • The content of any non-certificate can be changed to any content except that it cannot have the form characterizing certificates. • Object indices can be identified with each other (see Folding (section 4.4.2)). • When any object’s content is altered other than by conservative operations (see Conservation and Destruction (section 4.4.3)), be it a certificate or not, each certificate object referring to it in certain limited ways (section 4.5.9.3) will be “reconsidered” according to the procedure specified for its kind. If reconsidering a certificate alters its content, then certificates referring to it must themselves be marked for reconsideration. If reconsidering a certificate leaves it intact, then it engenders no further marking for reconsideration. • Similarly, when multiple objects are identified with each other (see Folding (section 4.4.2)), any certificate that contains references to more than one of them gets marked for reconsideration. See also Assimilation to Certificates (section 4.5.10). Of course, there are practical issues of making these current closed map transformations convenient. For example, users must be able to abort transformations and get advice about consequences of proposed transformations. 4.5.9.2 Stale Certificates In Altering Certificates the notion of “stale” Certificate (section 4.5.1) was introduced as a sort of database “inconsistency” induced by various operations and resolved by certificate “reconsideration” procedures. Here we elaborate on the methods for inducing and resolving staleness. We do not consider the staleness of certificates in the current closed map to be part of the map, but rather part of the state of the Session to which the current closed map belongs. As will be explained, other data pertinent to reconsidering a stale certificate are also maintained along with the mark of staleness. 4.5. RECORD KEEPING 113 Some quick orientation: At the level of interaction via a Session with the FDL process, current closed maps have no stale certificates; every operation on the current closed map at this level is automatically followed by reconsideration of all certificates marked stale. If an operation is attempted which induces staleness in any certificates, and those certificates are not recertified, rehabilitated or deleted, then the operation fails leaving the current closed map as it was. There is a procedure stipulated as part of a certificate’s kind (section 4.5.1) for reconsidering a stale certificate of that kind, and it is the execution of this procedure that effects the recertification, rehabilitation, or deletion or the certificate. The operations on the current closed map that can induce staleness in pertinent certificates are updating the content of an object, identifying two or more objects that were previously distinct (see Folding (section 4.4.2)), stipulation of a set of objects to be “shunned” in anticipation of deletion, and direct stipulation that a certificate is to be considered stale. When one of these occurs, data which may help to rehabilitate the certificate is saved as well, such as the old content of an object that has been changed. Not all certificates that may eventually become stale as the result of a change to the current closed map are necessarily marked stale at first; this makes it possible for some certificates to serve as buffers against various changes deemed “irrelevant” by other, more remote, certificates. When reconsidering a certificate object results in its alteration, pertinent certificates which depended on it in turn will are marked stale, thus a cascade of staleness marking is possible. This presents the following issues: • What are the “pertinent” certificates for reconsideration when an object is altered, multiple objects become identified, or a set of objects is to be shunned? • When a staleness inducing operations occurs, what data are saved for pertinent certificates? • How is a certificate’s reconsideration procedure applied in order to reconsider the certificate? See Pertinence, Extra State (section 4.5.9.4), and Resolving Staleness (section 4.5.9.6). 114 CHAPTER 4. WORKING NOTES ON FDL DESIGN 4.5.9.3 Certificates’ Pertinence to Objects (stipulation) Here is a key concept used in propagation of Stale Certificates. It is based on the reference relation (section 4.4.1) between objects: An object X refers “simply” to an object Y just when X refers (perhaps indirectly) to Y via a reference path with no interior certificate references. That is, either X refers directly to Y or X refers directly to a non-certificate object Z that refers “simply” to Y . As will be seen in Staleness (extra state) (section 4.5.9.4), the certificates pertinent to operations involving some change to a set of objects are those that simply refer to objects in that set. Certificates are intended normally to be directly “about” the content and identity of the objects to which they simply refer, and they get marked for reconsideration as a result of changes to such content or identity. This strategy is adopted rather than one of two more obvious ones for the following reasons. A simpler strategy would be to force reconsideration for all certificates that refer at all to the affected objects because they are, after all, about those objects and so could go wrong. However, we expect many certificate kinds to be designed to be independent of various features of the objects they refer to, for example such as what “comments” may be adorning their contents. When the reconsideration procedure stipulated for that kind of certificate is executed, it may ascertain that the referenced objects have not changed in ways it considers relevant and simply resolve the certificate by leaving it intact; then our staging strategy avoids forcing reconsideration of other certificates on account of changes to this one. This staging strategy enables the use of certificates as buffers against certain changes to their subjects. We shall use the term “buffering certificate” to mean certificates that remain intact when reconsidered due to certain changes to the objects they simply refer to. In order to make a certificate unaffected by certain changes to objects, rather than having it simply refer to those objects, one can have it refer to such “buffering” certificates that refer to those objects; then such changes will not even induce reconsideration beyond the buffering certificates. That expensive strategy of reconsidering all (indirectly) referring certificates would at least have been useful, and indeed is equivalent to our staging strategy when buffering certificates are not employed, since if no certificates remain intact after reconsideration then all the (indirectly) referring certificates will eventually get reconsidered (unless there is a failure earlier). 4.5. RECORD KEEPING 115 Consider another extreme strategy we have not adopted. Suppose that rather than forcing reconsideration of all simply referring certificates, we were to force reconsideration of only directly referring certificates. Under such a regime, certificates must be designed to carefully restrict their attention to those objects they directly refer to, which would fail to exploit a major convenience of our closed map design, namely allowing free and easy access to all the content one can reach from a small collection of object identifiers, i.e. allowing small expressions to refer (indirectly) to large numbers of objects. 4.5.9.4 Certificate Staleness Processing State The management of Stale Certificates (section 4.5.9.2) involves some extra state beyond which certificates of the current closed map are deemed stale. Recall that the ordinary state of the current closed map is that there are no stale certificates, and that staleness is intended as a temporary state; failure to eliminate staleness results in failure of the original operation and restores the current closed map to its original “prestale” state. In addition to the finite collection of stale certificates, there is for each stale certificate a collection of those objects that it simply (section 4.5.9.3) refers to whose contents have changed since the prestale current closed map; and each of those entries in the “changed object” collection is paired with the prestale value, which the certificate was presumably originally about. The purpose of this, as explained in Staleness (pertinence) (section 4.5.9.3), is to anticipate reconsideration procedures that leave the certificate intact based upon some relation between the old and new values that is deemed irrelevant to the the correctness of the certification. It is also possible that even if reconsideration does change the certificate content, thus forcing propagation of staleness to further pertinent certificates, knowing the difference between the old and new contents of simply (section 4.5.9.3) referenced objects may permit a more efficient incremental recertification than simply rerunning the certificate’s origination procedure. When the content of any object is updated, each certificate simply (section 4.5.9.3) referring to it is marked stale if it is not already so marked. Further, for each of these certificates the object is added to its “changed object” collection along with the prior content, unless it is already in the collection, in which case it is left as is. Another operation on the current closed map that changes the staleness state is Folding (section 4.4.2), which “identifies” some distinct object iden116 CHAPTER 4. WORKING NOTES ON FDL DESIGN tifiers with each other. For each stale certificate there is a “folded object collection” of the objects that it simply (section 4.5.9.3) refers to that resulted from such an identification of originally distinct identifiers. Similarly to the content change case above, the purpose is to admit the possibility of leaving the certificate intact or enable a more efficient incremental recertification. Upon Folding (section 4.4.2) the current closed map, any certificates that simply (section 4.5.9.3) refer to any of the newly “identified” objects are marked stale if not already so marked, and the identified objects get inserted in this folded object collection. It should also be noted that the extant “changed object collections,” “folded object collections” and the stale object collection must themselves be collapsed to reflect the new identifications. Another operation is simply to mark a certificate as stale even if nothing it simply (section 4.5.9.3) refers to changes in order to express doubt for external reasons. In order that the nature of this doubt may be communicated to the procedure for reconsideration, this operation takes a Text as argument to be saved with the stale certificate. With each stale certificate, therefore, is associated a (finite) collection of these “staleness fiats;” this operation then consists of marking a certificate as stale, if it’s not already, and adding the given “staleness fiat” to the collection for that certificate. Next we consider certificate deletion. 4.5.9.5 Staleness Processing State Continued shunning objects and deleting certificates We continue the discussion of State for processing stale certificates. There we introduced state and operations for incrementally adapting certificates to change of object content and identity. Here we introduce state and operations for facilitating incremental anticipation of object deletions. In addition to the operations described in Staleness State (section 4.5.9.4), another operation is to indicate that some objects should be “shunned,” which is simply a device for passing another set of objects to the certificate’s reconsideration procedure, but the intention is that the reconsideration procedure should try to update the certificate content in such a way that it avoids reference to the “shunned” objects. The purpose of this operation is its use prior to deleting (section 4.4.2) a collection of objects from the current closed map. When objects are deleted so are all objects that depend on 4.5. RECORD KEEPING 117 them; by “shunning” the objects beforehand, the reconsideration procedure has a chance to rebuild the certificate to avoid referring to the objects whose deletion is to come, which would otherwise simply delete the certificate as well. Shunning an object thus makes any certificate referring simply (section 4.5.9.3) to it stale, if it’s not already, and adds itself to the “shunned object collection” for each of those certificates. Finally, because reconsideration of a certificate may result in deletion of the certificate, and because we want to forestall deletion of such certificates until other certificates depending on them have had a chance to shun them, another part of the staleness processing state is a set of certificates marked for later deletion. When the reconsideration of a certificate requires its deletion, it is marked for deletion then shunned rather than being immediately deleted. When no stale certificates remain, certificates marked for deletion are deleted along with every object that refers to them. Of course, if any reconsideration procedures fail, then this point is never reached, and indeed this device could be exploited to protect an object from accidental deletion by referring to it with a certificate whose reconsideration procedure always fails. See Staleness State (section 4.5.9.4) and Resolving Staleness. 4.5.9.6 Resolving Stale Certificates As indicated in Altering Certificates (section 4.5.9.1), rather than simply adopting the expensive policy of simply deleting, or permanently marking as obsolete, Certificates (section 4.5.1) that fall into doubt, we permit the stipulation of a “reconsideration” procedure as part of defining a kind of certificate. The arguments to the reconsideration procedure are the (object id of the) certificate to be reconsidered and various values attached to that certificate object described in Staleness State (section 4.5.9.4) and Staleness and Deletion (section 4.5.9.5), namely: the “changed object collection,” along with the “prestale” contents associated with each member of the collection; the “folded object collection” of objects; the collection of “staleness fiats;” and the “shunned object collection.” When a stale certificate is reconsidered, this procedure is applied and the disposition of the certificate is determined by its result. If the procedure fails then the certificate remains stale, and presumably control passed to wherever the failure is caught. If the procedure completes, it returns one of three values: “intact,” “delete,” or a “new content” text. In any case 118 CHAPTER 4. WORKING NOTES ON FDL DESIGN the certificate is no longer stale; if the result of reconsideration is “intact” then that’s it for that certificate and no further staleness is induced by this; if the result is “delete” then the certificate is marked for deletion (section 4.5.9.5) and and the certificate is then shunned (section 4.5.9.5); if the result is a “new content” text then that text becomes the new content (except for the part indicating the certificate kind) of the certificate and pertinent certificates depending on it go stale. Let us emphasize a few points: 1. Although the Client can force deletion of a certificate (along with everything that refers to it) from the Current Closed Map of the Session, the only way to modify its content is by reconsideration. 2. Part of a certificate is an indication of its kind, which determines its creation and reconsideration procedures, and that part is beyond the reach of the reconsideration procedure (or the creation procedure for that matter). 3. Certificates will not be deleted until no stale certificates remain; they can only be marked for deletion until then. 4. Changing a certificate’s content or marking it for deletion will make any pertinent certificates referring to it stale, thus it is possible for reconsideration to cascade. 5. The difference between leaving a certificate “intact” upon reconsideration andusing its old content as its new content is that the latter will induce staleness in pertinent certificates referring to it. 4.5.10 Assimilating Ordinary Objects to Certificates We have presupposed a distinction between ordinary FDL objects and certificate objects. It would be possible to treat non-certificate objects as a specific kind degenerate of certificate object. To do this we would have to allow reconsideration procedures for certificates to take optional arguments; whether there would be some benefit other than contriving this assimilation remains to be seen. Let the creation protocol take as argument a possible content, and let executing it simply be using that argument as the new certificate’s content. 4.5. RECORD KEEPING 119 The “reconsideration” procedure would take an optional argument; if the optional argument is not supplied, then leave the object intact, otherwise update the content to the specified argument. Of course, if we were to do this assimilation to a single kind of object, we should drop the terminology of “certificate” in our general exposition, and simply say each object kind has creation and reconsideration procedures. The fact that simple reconsideration of our “degenerate” kind of object leaves its instances intact means that their being marked for reconsideration would have no effect.