The goal of this plan is to provide test results on the three core
archive modules XMLStore, MonitorStore and BulkStore.  These are not
really user tests as the core archiven is not a user-oriented package,
but rather aimed to provide persistency services to the other ALMA
subsystems. The main difficulty will be to get relevant test data.  We
can foresee the use of three kinds of test data:

 1. Actual bulk data from the correlator or the simulator (ALMA EDF??)
    This enables testing the actual archiving system as well as the
    retrieval and the consistency of the format(s) used.

     1. Bulk data from the simulator. The simulator should be able to produce
        the same data structures as the correlator. This enables the
        system to test data delivery without the need to run the
        correlator or the ATF.

     2. Bulk data from the correlator either produced by the ATF or by
        the correlator in simulation mode(??).


 2. XML meta-data produced by the other subsystems and/or the
    simulator. This kind of data mainly reflects the project structure
    for the entities and the ALMA data model for the parameters.

     1. The other subsystems will produce the different entities of
        the ALMA project structure and fill them with various
        parameters of the ALMA data model (ALMA DM). These entities
        will be stored in the XMLStore by the subsystems which are
        responsible for them and retrieved by other subsystems in
        order to retrieve project information necessary to fullfill
        their job. In general every subsystem will create its own
        entities and store them. The implementation of the project
        structure and ALMA DM as XML entities is up to the subsystems
        and the communication between them through the archive has to
        be carefully tested. While initial tests with the generic
        project structure can be carried out with dummy entities which
        do not contain all the details of the ALMA DM, subsequent
        tests should reflect the ALMA DM as completely as
        possible. Since the archive is not really involved in the
        maintenance of the entities or DM parameters the tests in this
        area are more data flow/communication tests for the
        consistency of the implementation of the project structure and
        the ALMA DM. 
	
	The actual XMLStore related tests are pretty straightforward
        as they only test that XML entities are stored and indexed
        correctly on ingest and that the basic retrieval mechanism
        works.

     2. The simulator will probably simulate the data flow starting at
        the level of the control subsytem, i.e. at the single SB
        level. In this case the subsequent entities have to be filled 
        by the simulator and the relevant links in the parent entities 
        have to be created as well. Along with the XML entities the 
        simulator will also produce the bulk data as described above. 
        This bulk data needs to carry back-links to the correct entities 
        in order to be able to identifiy the bulk data with their SB.


 3. Monitor data created either by the ATF and send to the archive by
    the Control subsysten or by the simulator

     1. At the ATF:
        This needs to be organized and does not really fit in the
        current release cycle of the Computing IPT.

     2. Simulator:
        Probably the simulator will only produce the part of the monitor
        data stream which is relevant for the reduction of the science
        data. The rest of the monitor data stream has to be defined
        and tested as well. Who and when this can be done is unclear.

     Also in this case the basic core test for the archive to be able
     to handle monitor data is pretty straightforward the main
     problem is the correct linking between the different parts of the
     ALMA DM.