<?xml version="1.0" encoding="UTF-8"?>

<!-- <!DOCTYPE sddlschema SYSTEM "sddlschema.xsd">-->

<sddl>

<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<!-- -->
<!--  SDDL Name:    EXECUTED.SDDL-->
<!-- -->
<!--  Purpose:      This SDDL file defines the EXECUTED relation.-->
<!-- -->
<!--  Modification History:-->
<!-- -->
<!--    Date       PR      Who                       Reason-->
<!--  - - - -    - - - -   - -   - - - - - - - - - - - - - - - - - - - - - -->
<!--  08/24/99   39260     Baum  Original implementation-->
<lm>  07/03/03   48821     CTB   Converted to XML format </lm> <!-- last mod -->
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->


    <record name="EXECUTED_TYPE">

        <description>This relation is used to replace the executed_flg in
                   qobservation. That table will be replicated and OPUS
                   cannot update it. Some additional data is also supplied
                   but only the executed_flg is updated by OPUS software.
                   The additional fields can be used to distinguish dumps
                   from science observations.</description>



            <field name="program_id">
                    <type>C3</type>
                    <description>When a proposal is accepted into the PMDB by SPSS it must
                    be assigned a unique 3 character base 36 program identifier.
                    This is done by the PMDB/ACCEPT_PROP command.  This program
                    identifier is tagged as 'program_id' in most PMDB relations.
                    Is is used for identification of proposals by spacecraft
                    and OPUS software. It is also used in the OPUS and DADS
                    rootname for all archived science data files.
                    Because of flight design software, program_id must be
                    three characters.</description>
            </field>

            <field name="obset_id">
                    <type>C2</type>
                    <description>An observation set is a collection of one or more
                    alignments that are grouped together based on FGS pointing
                    requirements.  That is, if multiple alignments can all be
                    executed using the same guide star pair, they are grouped
                    into the same observation set.

                    An observation set is identified by a 2 character base 36
                    string.  This field,  typically called 'obset_id', will
                    often contribute to the index on relation together with a
                    proposal_id, version_num, and possibly other fields.

                    OBSET is an abbreviation for observation set.</description>
            </field>

            <field name="ob_number">
                    <type>C2</type>

                    <description>For exposures, observations are numbered sequentially
                     throughout an observation set and are assigned by 
                     SMS/Gen. The connection between ob_number and the
                     PMDB alignment and exposure ids is in the table qolink.</description>
            </field>

            <field name="proposal_id">
                    <type>C5</type>
                    <description>A proposal consists of many individual observations 
		    submitted as a package by a proposer.  When a proposal is 
		    processed by the proposal entry system (RPS2), 
		    it is assigned a proposal identifier.  That identifier is 
		    an integer that is converted into a 5 character base 36
		    string.</description>
            </field>

            <field name="si_id">
                    <type>C4</type>
                    <description>This is the identifier type for a Science Instrument (SI).
		     The SI list includes the following:
			FOC  - Faint Object Camera
			FOS  - Faint Object Spectrograph
			WFPC - Wide Field Planetary Camera 1
			WFII - Wide Field Planetary Camera 2
			WF3  - Wide Field Camera 3
			HRS  - High Resloution Spectrograph
			CSTR - COSTAR
			1    - Fine Guidance Sensor 1
			2    - Fine Guidance Sensor 2
			3    - Fine Guidance Sensor 3
			NIC  - NICMOS
			STIS - Space Telescope Infrared Spectrograph
                        ACS  - Advanced Camera for Surveys
                        COS  - Cosmic Origins Spectrometer</description>
                        
            </field>
 
            <field name="control_id">
                    <type>C5</type>

                    <description>This is information on how OPUS is supposed to
                     process the data. The data is stored in five bytes:

                     H/Y/N  : Calibration data flag
                     F/P    : Output product type  (film/plot) - unused
                     2 bytes: Output format spec               - unused
                     Y/N    : Output product holding tank flag</description>
            </field>
 
            <field name="coord_id">
                    <type>C10</type>
                    <description>This is the SI aperture and coordinate system
                    identifier; it specifies the aperture and
                    coordinate system of the instrument to be
                    used for the observation of the target.
                    It is the aperture identifier concatenated with
                    the aperture coordinate system identifier.
                    They specify the default location of the target within 
                    the aperture.</description>
            </field>
 
            <field name="executed_flg">
                    <type>C1</type>

                    <description>When the record is created this value is blank. When
                     the observation has been executed on board HST, OPUS
                     receives a science POD file or OMS generates an 
                     astrometry file from engineering data, and this field is
                     updated to the Type (ninth) character of the dataset
                     rootname. </description>
            </field>
    </record>



    <relation name="executed">

        <type>EXECUTED_TYPE</type>

        <description>Execution status data</description>

        <subsystem_using>OPUS</subsystem_using>

        <index name="executed_1">
            <type>unique clustered</type>
            <field name="program_id"/>
            <field name="obset_id"/>
            <field name="ob_number"/>
        </index>

        <index name="executed_2">
            <type>nonclustered</type>
            <field name="proposal_id"/>
            <field name="obset_id"/>
            <field name="ob_number"/>
        </index>

    </relation>
</sddl>
