This is the primary key, automatically set when a row is inserted. Instrument on which calibration occurred. Standard calibration software is only guaranteed to work with instruments from the recommended set. Calibration type. Standard calibration software is only guaranteed to work with those on the recommended list. Normal production calibrations will be "vanilla". "ideal" is commonly used for simulations For now only XML format is supported Field is optional. If supplied, must be non-negative integer Start of period for which calibration is valid End of period for which calibration is valid Time the row is entered into database. Client is not allowed to set it Where the data was taken. May be used "as is" or may be input to some procedure, such as a root macro or analysis job. Optional place to specify what version of data format was used for this data set, so that consumers can decide how or whether to read it Every calibration must be marked with one of these completion states. "OK" just means the procedure completed, not necessarily that the results were any good. Is this calibration to be taken seriously (i.e., PROD)? Ideally, only one calibration of a given calib_type, flavor, etc., covering a particular instant should be PROD at a time. Date when this calibration was declared to be PROD (if it ever was) Date, if any, when this calibration ceased being called PROD program, script or whatever adding the row is responsible for filling in this field with something identifying it Service creating the row should determine user id invoking it and put it in this field. Typically complete path and filename for the calibration data. May include one or more environment variables written with delimiters $(...), e.g. a plausible data_ident might be $(CALIBUTILROOT)/xml/Cal/CalMuSlope_LAT.xml [maybe should change to using standard unix delimiters ${..} ? Or does it matter, since Windows does it differently?] Optional comments about input to calibration algorithm Optional comments about anything at all