Table 1: CAP v1.2 Australia Profile Specification CAP Element Profile Specification Normative Profile Specification Non-Normative “alert” Elements and Sub-elements alert REQUIRED Note: The <alert> element is not specific to any included <info> element, but is to serve as a general reference to all associated <info> elements and their content. Technical identifier REQUIRED Notes: 1) be assigned by the message producer. 2) For messages that are to be shared between organisations, the <identifier> SHOULD enable the message to be associated with a specific hazard event and originating organisation. 3) A national database of hazard event identifiers does not yet exist in Australia Technical Example: CAP v1.2 Standard sender REQUIRED Notes: 1) email address in the format example@domain that identifies the agency that assembled the message, or another agency that originated the message. 2) Use of Third Level Domain (example@bom.gov.au) or Fourth Level Domain (example@ses.sa.gov.au) names as the <sender> value, are considered acceptable methods to create uniqueness. 3) If an alert message created by another agency is being Technical Example (note 3): When the Duty Operations Officer at the Fire and Emergency Services Authority (FESA) of Western Australia (WA) receives hazard alerting information from the WA Police (WAPOL) in non-CAP format (i.e. it was received via a telephone call), the FESA Duty Operations Officer reformats the data into CAP format using that State’s alerting system, then redistributes the message on behalf of WAPOL.
msgType REQUIRED Notes: 1) Processing of “Ack” or “Error” messages is optional, and systems may impose their own associated rules. 2) Message states, and the transition from one state to another, are implied with the use of the <msgType> and <references> elements. 3) For alert messages intended for public distribution, a <msgType> of “Alert”, “Update” or “Cancel” does affect the message state, and an <info> element is REQUIRED. 4) For messages with a <msgType> of “Ack” or “Error”, an info element is not required, as these messages are primarily intended for system level purposes and not for distribution to the public. Technical Example A. Weather for public distribution: <alert> <status>Actual</status> <msgType>Alert</msgType> … <code>urn:oasis:names:tc:emergency:cap :1.2:profile:CAP-AU:1.0</code> … <info> … </info> </alert> Example B. Message that is not intended for public distribution: <alert> <status>Actual</status> <msgType>Error</msgType> <source>example@bom.gov.au</source> <scope>Private</scope> … <addresses>insert valid recipient addresses </addresses>
12) When the addition, modification, or removal of layer based values takes place relative to the previous message, the value of “layer” SHOULD be used in the <info> element(s) where applicable. 13) When the content change does not meet the criteria of the parameter values, the value of “other” SHOULD be used in the <info> element(s) where applicable. A <note> element should always be used with “other” changes. 14) A <note> element MAY be used to further explain the reason for the minor changes in this update. “resource” Element and Sub-elements Any <resource> sub-elements whose use is specified as REQUIRED, are only mandatory inclusions when the <resource> element is to be included in a message.