ROOT Alternative Data Models. ----------------------------- Combining ROOT and D0OM ----------------------- The main goal for some kind of ROOT and D0OM combination would be to develop a file format that is simultaneously readable using the D0OM I/O interface as well as by cint. This kind of file format would reduce the disctintion between data and ntuples, which would add more flexibility to the analysis process. Analysis tools could be used to browse D0 data and, and data tools could read and write ntuples. Such flexibility would obviously be beneficial for D0. The alternative, which is to continue as we do now with strictly separate data and ntuple data formats, can be done now with out any changes to either ROOT or D0OM. Most discussion about how to do this has considered the possibility of reading and writing data in standard ROOT data formats throuth the D0OM I/O interface -- or in other words, using ROOT as an I/O back end for D0OM. Such an idea is natural for D0OM, as D0OM was specifically designed to accomodate alternative I/O back ends. ROOT and D0OM data models ------------------------- The main obstacle to developing a jointly readable file formats is the fact that the ROOT and D0OM data models are currently incompatible. There are three incompatibilities: 1. Base Classes: d0_Object (D0OM) vs. TObject (ROOT). 2. Container classes: STL (D0OM) vs. ROOT-specific containers, such as TArray. 3. Smart pointers. D0OM has them (d0_Ref). ROOT doesn't. The feasibility of developing a joint file format depends to a large extent on the possibility of reducing the differences between the ROOT and D0OM data models to the extent that a single C++ header can be used for both Scenario I: ROOT and D0OM data models remain incompatible --------------------------------------------------------- If the two data models remain incompatible, as they are now, then a scenario for combining ROOT and D0OM is as follows: 1. Add a ROOT I/O back end class (d0StreamROOT) to D0OM. Such an I/O class would probably work by defining a TObject subclass that could stream data in d0_Object subclasses. The D0OM dictionary could be accessed for this purpose. 2. Develop an automatic way to convert D0OM style C++ headers to ROOT style headers that are understandable to cint. The above scenario has the advantage of not requiring any changes in ROOT. However, the incompatibility of ROOT and D0OM headers represents a very great barrier to the successful implementation of such a scheme. Scenario II: ROOT and D0OM data models are reconciled ----------------------------------------------------- The disadvantages of Scenario I are so great, that most discussion has centered on the possibility of reconciling the ROOT and D0OM data models, at least to the extent of allowing a single set of headers to be used for both. If this can be accomplished, then the modifications needed to D0OM in order to accomodate ROOT data are fairly easy. A ROOT I/O back end class (d0StreamROOT) would be still required, as in item 1 above. We consider the three incompatibilities in turn. Base class ---------- In principle it is simple to make TObject a base class for all D0 persistent classes by simply deriving d0_Object from TObject. There is an issue involving the amount of physical (i.e. compile- and link-time physical coupling between TObject and the rest of ROOT. D0 would prefer to have *no* physical coupling, as is the case with other D0OM I/O mechanisms, so that non-ROOT-I/O programs do not have to link against ROOT libraries. It is almost certainly possible to bypass the physical coupling issue by implementing a D0OM ROOT I/O back end that does not require D0 persistent objects to be derived from TObject. However, TObject would still be required as a base class by cint. This might be accomplished by enclosing the derivation of d0_Object from TObject inside the d0_Object header file in a suitable conditional compliation directive. Containers ---------- The ROOT team is already committed to modifying the ROOT data model to allow STL containers. This will involvea a significant effort on the part of the ROOT developers to upgrade cint. Adding STL support to ROOT will involve two phases. Phase I is the header parsing and streamer generation phase, which will allow STL containers to be saved using ROOT's persistence mechanism. Phase II is full support of STL containers in interpreted C++. The ROOT team may be able to borrow some of Scott Snyder's D0OM code for phase I. Smart pointers -------------- Once template support is added to cint, there there is no reason that ROOT can not also support smart pointers as part of its object model. However, one difference between STL containers and D0 smart pointers (template class d0_Ref) is that whereas the former are standard, the latter are D0-specific. Probably some conditional compilation would be required so that different definitions of d0_Ref were seen by C++ and cint. Areas of Concern ---------------- 1. Can a reasonable level of template support be achieved within cint? What is the status of the project to support STL containers in ROOT? 2. How could the D0-specific smart pointer class d0_Ref reasonably be supported in the ROOT object model? 3. Is it possible to sufficiently decouple TObject from the rest of ROOT? Effort ------ The following are some tasks that would have to be undertaken by the D0OM and ROOT developers. Product Task Difficulty ----------------------------------------------------------------- D0OM Derive d0_Object from TObject Easy Add ROOT I/O back end, including default implementations for the TObject interface requirements. Medium (1 FTE-mo) ----------------------------------------------------------------- ROOT Support STL containers Hard Support smart pointers (class TRef?) Easy (?) In this scenario, it is clear that most of the coding burden is is within ROOT rather than D0OM. Recommendations --------------- 1. Any attempt to combine ROOT and D0OM should procede on the assumption that the ROOT and D0OM object models will be reconciled to the extent that a single set of C++ headers suffices for both (possibly including conditional compilation). Any conditional compilation should be limited, if possible, to D0OM headers (as opposed to user headers). 2. The ROOT object model should be modified to support templates, including STL containers and a built in templated smart pointer class.