OBIX v1.0 Comments

[cisi@ix.netcom.com]

Re spaceTemp as a point: Good point (pun intended).
This is a standard contract defined by oBIX for representing point information.

I am still struggling with the standard contract defined by oBIX for representing
alarm information.
Reference the definition of "alarm" in paragraph 15:
"an alarm indicates a condition which requires notification of either a user or
another application". 

My confusion starts with the third paragraph of 15.1 and includes 3 parts:
1. "An alarm which implements neither StatefulAlarm nor the AckAlarm contracts is
completely stateless - these alarms merely represent events" implies that an event
is a subset of alarm. Back to the definition of "alarm" in paragraph 15 and
changing "condition" to "event" yields "an alarm indicates an event which requires
notification of either a user or another application". This implies that alarm is
a subset of event.
2. "An alarm which implements StatefulAlarm but not AckAlarm will have an in-alarm
state, but not acknowledgement state" is ok but I am having difficulty coming up
with an application wherein recording that someone acknowledged the alarm and the
time of the acknowledgement would not be required,
3. "Conversely an alarm which implements AckAlarm but not StatefulAlarm will have
an acknowledgement state, but not in-alarm state."
I do not understand how there can be an acknowledgement state if there has been no
in-alarm state. Without the in-alarm state, there is no need for notification and
thus no need to acknowledge the notification. Actually, I do not understand how an
alarm can not implement StatefulAlarm. If an event does not have an in-alarm state,
it is not an alarm.
All this is only a point of confusion for me. More important is the fact that the
standard contract defined by oBIX for representing alarm information includes
contracts for StatefulAlarm and AckAlarm. 

Then, in 4.16.8, the status facet includes one of 3 alarm values:
1. unackedAlarm: in alarm but not acknowledged
2. alarm: in alarm
3. unacked: a past alarm condition which remains unacknowledged.
I believe there are additional alarm values which should be defined in the standard
contract, namely:
4. ackedAlarm: in alarm and acknowledged.
5. pastAlarmAcked: past alarm which has returned to normal and was acknowledged.
6. noAlarmNoAck: the normal state. 

I'll try to plug these values into an example.

The thermostat object described in the Quick Start example had three child objects:
	a current space temperature value represented by the spaceTemp element,
	a desired temperature value represented by the setpoint element, and
	a control output value represented by the furnaceOn element.
If the application called for a temperature alarm function,
six children or grandchildren objects could be added:
	a high temperature alarm value represented by an alarmSetpoint element
	a high alarm state value represented by an alarm element
	a high alarm time stamp value represented by an alarmTimestamp element
	a return to normal time stamp value represented by a normalTimestamp element
	a high alarm acknowledge state value represented by an ack element
	a high alarm acknowledge time stamp value represented by an ackTimestamp
		element. 
Assume the initial current space temperature value is below the high temperature
alarm value; the initial high alarm state value would be reset.
Since there is no high temperature alarm state to acknowledge,
the initial high alarm acknowledge state value would be reset.
The status facet alarm value would be "noAlarmNoAck".
If the current space temperature value increases to the high temperature
alarm value,
	the high alarm state value would be set
	the high alarm time stamp value would record the time of the high
		temperature alarm.
	the status facet alarm value could be "alarm".
Since an alarm condition requires notification, the transition of the high alarm
state value from reset to set triggers a horn and flashing lights to wake a user
or an interrupt to wake an application. If the application requires the user to 
acknowledge the alarm, the status facet alarm value would be "unackedAlarm". 
In order to acknowledge that the user or application is awake and aware of the
alarm condition, the user/application sets the high alarm acknowledge state value.
The status facet alarm value would be "ackedAlarm".
Normally, the transition from reset to set of the high alarm acknowledge state
value will stop the horn and flashing lights so that they are available to any
other alarm event.
The high alarm acknowledge time stamp value would record the time of the
acknowledgement.
When the current space temperature value decreases below the high temperature
alarm value
	the high alarm state value would be reset
	the return to normal time stamp value would record the time of the return
		to a normal temperature.
If the alarm state has not been acknowledged when the high alarm state transitions
to normal, the status facet alarm value would be "unacked". Then, when the user 
finally acknowledges the past alarm, the status facet alarm value would be
"pastAlarmAcked".
If the alarm state had been acknowledged before the high alarm state transitions
to normal, the status facet alarm value would be "noAlarmNoAck".	

Finally, something has to reset the acknowleded state in order for the system to
see the transition from reset to set.
Actions such as turning on a horn are triggered by an event.
Events are identified by an event state transition.
I guess the event state could be represented by a flip-flop.
But, then some other mechanism would have to keep track of what the flip-flop
state means. Assigning a meaning to each state is simpler,
i.e. reset means normal and set means alarm or
reset means unacknowledged and set means acknowledged.
Therefore, for the event to be identified the next time it occurs, the event state
must be returned to its normal state. Specifically, if we want to recognize the next
transition to the acknowledged (set) state, the high alarm acknowledge state
value must be returned to its unacknowledged state at some point.

This specification was very well done. My comments are self serving in that they
help me work through some points of confusion. Hopefully, they will be helpful
to others.