FDL notes - Current Closed Maps

IF YOU CAN SEE THIS go to http://www.cs.cornell.edu/Info/People/sfa/Nuprl/Shared/Xindentation_hack_doc.html

Current Closed Maps

As was mentioned in Closed Maps, in a Session a Client develops a current closed map, normally by initializing it from the FDL, transforming it through a sequence of operations to generate new closed maps, then storing it back into the FDL in such a way that it can be later retrieved easily. Our focus here is on sequences of closed maps that may constitute the current closed map's history, especially with regard to Certificates, rather than on interaction with the FDL.

Some operations on closed maps which will be used to modify the current closed map are listed in Conservation and Destruction. Basically they involve "conservative" operations that leave certificates intact, and operations that may force modification of certificates. Whether an object is a certificate is conceived here as a distinctive property of the content.

It should be kept in mind that during a Session the current closed map is part of the session's state, and that the map will typically include programs that can operate on the state.

When a kind of certificate is implemented, policies for creation and alteration are stipulated, and the "internal" significance of the existence of a certificate object is that the current closed map has been developed from an Initial Closed Map (inherent to the FDL) by a sequence of transformations enforcing policies implicit in the rules for introducing or altering certificates in the FDL. Actually, we must weaken the claim slightly to say that the current closed map could have been so developed, since it may have been initialized from an FDL, and so part of being an FDL of closed maps is that any maps extracted from it could themselves have been built from the initial closed map by a sequence of transformations.

Design of certificate policy is nontrivial, especially as regards incremental reconsideration of doubtful certificates, and proposals follow (start with Altering Certificates). But one part is simple, namely some generic operations that cannot be constrained by certificate policies:

* One can always delete a collection of objects as long as every object referring to an object in the collection is itself in the collection.

* One can always uniformly rename objects, so long as no distinct objects become identified (references in all objects are altered as part of the renaming).

* One can always add a new object with any non-certificate content you please.

* One can always "clone" any collection of objects. Cloning some objects means making a new collection of objects with identical contents except that the clone references replace the original references.

Let us call these operations "conservative". Conservative operations are simple, whereas other operations can force change of certificates - see Altering Certificates. IF YOU CAN SEE THIS go to http://www.cs.cornell.edu/Info/People/sfa/Nuprl/Shared/Xindentation_hack_doc.html

Glossary FDLnotes

*	One can always delete a collection of objects as long as every object referring to an object in the collection is itself in the collection.

*	One can always uniformly rename objects, so long as no distinct objects become identified (references in all objects are altered as part of the renaming).

*	One can always add a new object with any non-certificate content you please.

*	One can always "clone" any collection of objects. Cloning some objects means making a new collection of objects with identical contents except that the clone references replace the original references.