Temporal rules are Activations which fire after a given time if they are still true; ie if a room is empty for five minutes then turn off the light.
The <duration> element within rules allows a unit of time to be assigned before the rule, if it is still on the Agenda, is fired:
<duration seconds="2" />
The units of time can be specified in any combination of days, hours, minutes and seconds as shown in the following xsd code snippet:
<xs:element name="duration" minOccurs="0" > <xs:complexType> <xs:attribute name="days" type="xs:nonNegativeInteger"/> <xs:attribute name="hours" type="xs:nonNegativeInteger"/> <xs:attribute name="minutes" type="xs:nonNegativeInteger"/> <xs:attribute name="seconds" type="xs:nonNegativeInteger"/> </xs:complexType> </xs:element>
When a <duration> is specified a class is created implementing the Duration interface. While units can be specified in an combination internally they are stored as a long representing the time in miliseconds.
The Agenda uses the standard java.util.Timer class to schedule Activations specified time and as such does not offer any guarantees of real-time performace - from Sun's javadocs:
- This class does not offer real-time guarantees: it schedules tasks using the Object.wait(long) method.
Currently no Conflict Resolution strategy is assigned to temporal rules - so if several rules with the same durations are all activated with the same assertion/modify action they will be fired in the order in which the Activations are created.
