Proposal for L1 Inclusive Trigger Option
	--------------------------------------------
	Version 1.2
	Peter Wilson
	23 April 2002

Purpose: Provide a L1 "Trigger" that can be used for monitoring/error paths 
	which reuire more than one L1 Trigger for a single L2 trigger (Path).
	Examples include a L2 Error trigger and monitoring paths which have 
	an Auto-accept w/prescale at L2 but are an inclusive mix of L1 
	triggers.

Proposal: define a new L2 Option that will work without any L1 trigger
	specified in the path but will provide a mechanism to define the 
	mix of L1 triggers to use in an inclusive way at L2.  

Option "INCLUSIVE" with one Parameter, "MASK_TYPE".  This would be a text 
	string.  Currently three values:

	"ALL" - At L2 use an OR of all L1 bits.  This would 
		be used as the input for the L2 Error trigger. 

	"TRACK" - At L2 use an OR of all L1 bits which contain
		ONLY ONE_TRACK, TWO_TRACK, or SEVEN_TRACK options (may also
		contain a PRESCALE option).  

	"NON_TRACK" - At L2 use an OR of all L1 bits which 
		contain options other than ONE_TRACK, TWO_TRACK, "
		SEVEN_TRACK or PRESCALE.  

	The OR "NON-TRACK" and "TRACK" should be same as "ALL". 


Separating TRACK and NON-TRACK will allow different prescales for these 
inclusive samples being fed to monitoring.  

Interpretration by DB Validation code:

	o L1/L2 validation would allow these paths to have no L1 trigger
		associated with them

	o Java code for L2 header generation will create a bitmask for
		each of these based on the above criteria.  

	o L2 code for L1 bit comparison would compare with bitmask instead
		of single bit for any trigger with the INCLUSIVE option.


Additional note: for the monitoring triggers we will want to change the 
readout list based on the trigger path.  These should have trigger diagnostic 
readout.  How do we indicate the desire to have this for a specific path?  
Should this be a L2 specific option associated with the path?