Minutes of the Event Data Model Working Group Meeting
                                  30 March 1999
                                   Rob Kennedy,
                for the CDF Run II Event Data Model Working Group


Attending: Rob Kennedy, Jim Kowalkowski, Marc Paterno, Prem Singh,
           Liz Sexton-Kennedy
By Video:  MIT (Betsy Hafen)
By Phone:  Berkeley (Marge Shapiro, Paolo Calafiura)


I) Summary of CDF - ROOT Event I/O Meeting - Rob Kennedy

	Rob K presented a draft version of his talk "Event I/O and ROOT" to be
given at the 31-Mar-1999 Offline Meeting. For the draft version, see

http://www-cdf.fnal.gov/upgrades/computing/projects/edm/slides/EDM_root_issues_19990330.ps


A) ROOT I/O and Individual Classes

	Jim K expressed concern about schema evolution and the implementation of
I/O support for STL containers. Suppose one wished to change the kind of
container in the future, the kind of element. Rob K. stated that this of course
depends on the implementation by Fons Rademakers. One can imagine that the
Streamer() for an STL container would permit the user to change the exact kind
of container in use, as long as it was compatible with the category of container
that was stored. A vector and a list would be interchangeable, as would a set
and a map, or instance. As far as elements as concerned, their Streamer() would
be called as part of saving/restoring the container, so their schema evolution
is independent of the containers.

	Marc P. asked how we would handle in one program a class which has
different versions of a method's implementation. Rob K. pointed out that this
case is no different from out Ybos experience. The class developer must test a
version number in the method in order to insure the correct implementation is
used for the correct version of the persistent format.

	Marc and Jim described alternatives to using if/else-if blocks in
Streamer() and possible other methods which vary in implementation according to
the persistent format of a class. Marc described using polymorphism, with an
abstract class defining the interface and concrete classes defining individual
"versions" of a class. This would require that algorithm code be rewritten to
use pointers to the base class instead of concrete instances of a class... or a
naother layer of handles would be needed to hide this change. Jim K described a
scheme which would save pointers to different versions of a method in an array,
using the version number as index. Paolo C. pointed out that this seemd like
overkill to avoid (usually) just on if/esle-if block in user classes.

	Marge S. followed up this discussion by noting that we still would need
some way for a class to indicate that a method , feature, or data member of a
class is not implemented (we used to return -999.0 by convention).

	Marge also commented that we should revisit some of the lack of STL
support and other known current limitations of rootcint when we being the code
review for the Tracking system (perhaps in week of 06-April?). Do other known
limitations of rootcint cause problems for our Offline classes?

B) ROOT I/O and Data Handling

	Paolo asked why not make the "group of TBranches" into a TTree? Rob
agreed that should be considered, and a number of benefits. The there would be
a TTree level for each stage of processing and a TTree level for groups of
TBranches. Both of these level are specified by the user as the input dataset.
Rob will use this as the model so long as no fatal problems surface.

	Marge stated that we should have a clear proposal for what goes into
the User TTrees in an event. Ntuples are not StorableObjects, and are
intended to the accessed with ROOT functioning as a replacement for PAW. So does
it make sense to store them in the "Logical Event". The reason to push other
portions of the event into the List of Trees of Lists of Trees is primarily I/O
efficiency. If users do not require that the central Data handling system deal
with their n-tuples, then there is no reason to force users to put n-tuples or
histograms into the User Trees. There may be issues of interference with having
n-tuples and histograms in the EDM event and the HepTuple behavior.

	Our example of streaming through BPad data and then wanting to go back
to a few Raw pick-events has a more efficient recommendation. The user runs job
1 to input all appropriate BPad data, and creates a list of Raw events it would
like to see. The user then runs a second job using the pick-event list to stage
the Raw and Dst events from tape to disk. Once on disk, the user runs a third
job to access the Raw event datafiles on disk, as well as perhaps the BPad
pick-events.

	Jim commented that he did not think the ROOT team was aware of our
Offline Framework / Infrasrtucture (AC++, CalibDB, Geometry) is all relatively
independent of ROOT. So, the 50 lines of code example requested by the ROOT
team may not be what they are expecting. Rob stated that a prototype of ROOT I/O
will be delivered on 01 June 1999, and will include a prototype for I/O modules
and user algorithm code access to event data.

.the end.