Major Throughout the model there are various uses of "ack" type attributes which have been set to the data type of string. An ack type action is probably best reflected as a Boolean.
However, the repeated uses of "ack" attributes throughout the model suggest this attribute may be abstracted out. In addition if more information about an acknowledgement is needed there may be an opportunity to leverage the Status class from CIM.
IEC61968.Common.Status (compounded class)
This class contains dateTime, reason, remark, value that may be leveraged for this purpose.
See email exchange e.g. http://lists.oasis-open.org/archives/energyinterop/201104/msg00002.html (subject line "Ack Ack - a way forward")
"Ack" was introduced as a shorthand; Application Response is probably a better term. Need to get differentiated information in some exchanges.
My favorite issue that I hhad not yet entered.
Do we need a Bool and the 61698, or one, or....
dateTime
reason - not enumerated, do we need to?
remark free form
status, recommend app specific enum...
Note that for types of documents, the status is regarding the subject matter (e.g., TroubleTicket, SwitchingSchedule, Work, WorkTask, Specification, TypeAsset, AssetModel, etc.) of this particular type of document. It is not the status of the document, which is found in 'docStatus'.
I "think" that we have concensus that the various Ack strings can be removed from the message payloads as the returns (both normal and errors) along with message header information serve to address this need. Once the Ack string are removed this issue may be closed.