Originally, the OCCT persistence was based on an object oriented database. In order to control what is actually stored, the applications had to define a database schema by mean of a set of persistent classes - classes inheriting from Persistent such as the ones from the PGeom and PTopoDS packages - then to bind their (transient) data model to this database schema through conversion drivers (e.g. MgtGeom, MgtTopoDS) - see Foundation Classes User's Guide chapter 5, Data Storage.
The OCAF-based applications using standard attributes (the ones from TDF, TDataStd, TNaming, TFunction, TPrsStd and TDocStd packages) can make use of a ready-to-use database schema, the so called Standard Schema. Since we left the object oriented database, this schema saves the OCAF data into files.
Two other data storage formats have been introduced in OCAF, not based on a binding to persistent classes, the XML and Binary OCAF formats (these formats are based on direct writing from the transient application data model to files, using appropriate drivers). Since the availability of these formats, we expect that all applications based on OCCT save their data either through XML or Binary OCAF or through the TopoDS_Shape save format (brep). If so, we could remove from OCCT the entire persistent classes' hierarchy, including the parallel Handle hierarchy, and the corresponding conversion drivers. This would lighten the OCCT build as well as the Handle revamping (on-going study).
If we go forward in this direction (to be validated), given that some of our customers are still using the original Standard Schema for saving OCAF data, we'll need to provide them with a solution.
If anyone else is still using this storage schema, please tell. As usual, any other remarks are welcomed.