Index: trunk/archive/scripts/src/concepts.txt
===================================================================
--- trunk/archive/scripts/src/concepts.txt	(revision 4281)
+++ trunk/archive/scripts/src/concepts.txt	(revision 4386)
@@ -27,4 +27,8 @@
 FPA.RADECSYS		System of RA,Dec (e.g., J2000 or ICRS)
 FPA.NAME		An identifier (e.g., observation number) for the FPA instance
+FPA.DATE		UT date (YYYY-MM-DD)
+FPA.TIME		UT time (HH:MM:SS.sss)
+FPA.DATETIME		UT date and time (YYYY-MM-DDTHH:MM:SS.ss)
+FPA.MJD			Modified Julian Date
 
 Chip-level:
@@ -43,7 +47,7 @@
 CELL.GAIN		CCD gain (e/ADU)
 CELL.READNOISE		CCD read noise (e)
+CELL.SATURATION		CCD saturation point (ADU)
+CELL.BAD		CCD bad pixel point (ADU)
 
-CELL.XOFFSET		Offset on the CCD of window start in x
-CELL.YOFFSET		Offset on the CCD of window start in y
 CELL.XBIN		Binning in x
 CELL.YBIN		Binning in y
@@ -55,13 +59,57 @@
 value to become out of sync).  And there is no reason why (most)
 concepts lower down can't be specified higher up, and simply be
-inherited.  The exception to this is the OBSNUM (observation number),
-which allows an FPA to be identified given a cell, etc.
+inherited.  The exception to this is the FPA.NAME (observation
+number), which allows an FPA to be identified given a cell, etc.
+
+There are so many ways of specifying dates and times.  We probably
+want a high-level function, psCellGetTimeObs() to sort through all of the
+possibilities.
+
+Similarly with binning: CCDSUM is a common header, or the bin factors
+might be in separate headers.
 
 
-These are optional:
+Retrieval
+=========
 
-DB.HOST		Database host name (for psDBInit)
-DB.NAME		Database name (for psDBInit)
-DB.USER		Database user name (for psDBInit)
-DB.PASSWORD	Database password (for psDBInit)
+Each of the concepts can be retrieved in the following ways:
 
+1. FITS header translation: the camera configuration contains a
+   "TRANSLATION" entry, which gives the concept along with the FITS
+   header equivalent.
+
+2. Database: the camera configuration "DATABASE" entry contains
+   information on how to poll the database for the required concept.
+   The DATABASE entry contains metadatas specified using the TYPE:
+
+	TYPE		dbEntry		TABLE		COLUMN		GIVENDBCOL	GIVENPS
+
+   An example DATABASE entry is:
+
+	CELL.GAIN	dbEntry		Camera		gain		chipId,cellId	CHIP.NAME,CELL.NAME
+
+   This says, in the database, you basically do: "SELECT gain IN
+   Camera where chipId == CHIP.NAME and cellId == CELL.NAME" (where I
+   have, no doubt, taken liberty with the SQL query).  In this case,
+   CHIP.NAME and CELL.NAME are looked up before the query is executed,
+   using means other than a DB query (otherwise we could get stuck in
+   an infinite loop).
+
+3. Defaults: the camera configuration "DEFAULTS" entry contains
+   default values.  These default values may simply be specified, or
+   they may be dependent upon another value.  In the latter case, an
+   additional keyword, "CONCEPT_DEPEND", where "CONCEPT" is the
+   concept of interest, and "DEPEND" is literal, is specified with the
+   value being the concept on which it is dependent.  Then, the
+   concept is a METADATA type, with the elements being values of the
+   other concept on which it is dependent.  An example is helpful:
+
+	CELL.YPARITY_DEPEND	STR	CHIP.NAME
+	CELL.YPARITY	METADATA
+		ccd00	S32	-1
+		ccd35	S32	1
+	END
+
+   This says that the CELL.YPARITY is dependent upon the CHIP.NAME:
+   ccd00 has negative parity, and ccd35 has positive parity.
+