2.1 “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) SHALL 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) It is RECOMMENDED that a valid email address in the format example@domain that identifies the agency that assembled the message, or another agency that originated the message be used.

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 passed through a system, such as a data aggregator, with no alterations, then the <sender> can remain as is.  However, if any changes are made to the message, or if the aggregator is the authority to its clients, the <sender> value should change to reflect the aggregator, and the original message’s extended identifier (sender, identifier, sent) is to be added to the <incidents> block, with a <source> value added identifying the original sender and what was changed.

Technical

Example (note 3):

When the Duty Operations Officer at the Department of Fire and Emergency Services (DFES) in 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 DFES Duty Operations Officer reformats the data into CAP format using that State’s alerting system, then redistributes the message on behalf of WAPOL.

<alert>

   …

   <sender>example@dfes.wa.gov.au</sender>

   <info>

      <senderName>Western Australia Police

      </senderName>

   …

</alert>

status

REQUIRED

Notes:

1) Value of “Actual” SHALL be used when messages are intended for public dissemination.

2) Value of “Test” denotes that alert SHALL be treated as a log-only event and not be broadcast as a valid alert.

Technical

Example:

CAP v1.2 Standard

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 alert 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 alert for public distribution:

<alert>

   <sender>example@bom.gov.au</sender>

   <scope>Public</scope>

   <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>

   <code>urn:oasis:names:tc:emergency:cap
:1.2:profile:CAP-AU:1.0</code>

   <note>Invalid eventCode</note>

   <references>TEST-1,2011-01-01T12:00:00+10:00
   </references>

   …

   <info>

      …

   </info>

</alert>

restriction

CONDITIONAL

Notes:

1) Can be used to reflect the combined classification of all of the <info> elements and the handling of the entire message.

2) Classifications SHALL be in accordance with national security classifications and non-national security markings listed in the Australian Government Protective Security Policy Framework (PSPF).

Technical

Example:

<alert>

   …

   <scope>Restricted</scope>

   <restriction>CONFIDENTIAL</restriction>

   <addresses>insert valid recipient addresses
   </addresses>

   …

   <info>

</alert>

code

REQUIRED

Notes:

1) The value for <code> SHALL be “urn:oasis:names:tc:emergency:cap:1.2:profile:CAP-AU:1.0”

2) A value used to identify which version(s) of the CAP-AU Profile the alert message is intended to be compliant with.  Used by the message producer to assure conformance with the Profile approved for use within the Australian environment.

3) Does not preclude the option of using <code> for other purposes, such as version referencing, interoperability, layer identification, system specific functions, user-defined values, flags, special codes, etc.

Policy

Example. To denote interoperability where a message can be processed using profiles from different countries or organisations – this example identifies compatibility with the Australian (CAP-AU) and Canadian (CAP-CP) Profiles:

<alert>

   …

   <scope>Public</scope>

   <code>urn:oasis:names:tc:emergency:cap
:1.2:profile:CAP-AU:1.0</code>

   <code>profile:CAP-CP:0.4</code>

   …

</alert>

references

OPTIONAL

Notes:

1) For “Update” and “Cancel” messages, all related messages that have not yet expired MUST be included as a reference, as a missed message could result in an alert playing beyond its intended time.  Include the entire update trail, not just the most recent update.

2) Referencing all alert messages with <info> elements that still have an <expires> time in the future, ensures that any messages that may still be playing incorrectly are properly superseded by the most recent Update or Cancel message. This resolves issues caused by transmission delays and/or lost messages that may result in message chains being broken.

Technical

Example A. The first Alert message with a <expires> time of 0001UTC:

<alert>

   <identifier>IDS20210</identifier>

   <sender>example@bom.gov.au</sender>

   <sent>2011-05-11T00:35:00+09:30</sent>

   <status>Actual</status>

   <msgType>Alert</msgType>

   …

   <info>

      …

      <expires>2011-05-12T00:01:00-00:00</expires>

      …

   </info>

</alert>

Example B. Subsequent UPDATE message with a 3 hour <expires> time:

<alert>

   <identifier>IDS20211</identifier>

   <sender>example@bom.gov.au</sender>

   <sent>2011-05-11T02:00:00+09:30</sent>

   <status>Actual</status>

   <msgType>Update</msgType>

   …

<references>example@bom.gov.au,IDS20210,2011-05-11T00:35:00+09:30
   </references>

   <info>

      …

      <expires>2011-05-11T05:00:00+09:30</expires>

      …

   </info>

</alert>

Example C. Another subsequent UPDATE message with a 3 hour <expires> time that references the first two related messages:

<alert>

   <identifier>IDS20212</identifier>

   <sender>example@bom.gov.au</sender>

   <sent>2011-05-11T03:00:00+09:30</sent>

   <status>Actual</status>

   <msgType>Update</msgType>

   …

   <references>example@bom.gov.au,IDS20210,
2011-05-11T00:35:00+09:30  example@bom.gov.au,IDS20211,2011-05-11T02:00:00+09:30</references>

   …

   <info>

      …

      <expires>2011-05-11T06:00:00+09:30</expires>

      …

   </info>

</alert>

Example D. A further subsequent UPDATE message with a 3 hour <expires> time referencing the most recent two messages as the earliest one has expired and should not be playing anymore for two possible reasons – a) it has been superseded, or b) it has expired:

<alert>

   <identifier>IDS20213</identifier>

   <sender>example@bom.gov.au</sender>

   <sent>2011-05-11T04:00:00+09:30</sent>

   <status>Actual</status>

   <msgType>Update</msgType>

   …

   <references>example@bom.gov.au,IDS20211,2011-05-11T02:00:00+09:30   example@bom.gov.au,IDS20212,2011-05-11T03:00:00+09:30</references>

   …

      <info>

      …

      <expires>2011-05-11T07:00:00+09:30</expires>

      …

   </info>

</alert>

incidents

OPTIONAL

Technical

Example. To denote that all messages showing this sub-element are related to the same hazard event:

<alert>

   <identifier>IDS20213</identifier>

   <sender>example@bom.gov.au</sender>

   <incidents>”Cyclone Yasi:2011”</incidents>

   …

   <info>

      …

   </info>

</alert>

2.2 “info” Element and Sub-elements

Any <info> sub-elements whose use is specified as REQUIRED, are only mandatory inclusions when the <info> element is to be included in a CAP-AU message.

info

OPTIONAL

Notes:

1) This element MUST be included for all alert messages intended for public distribution.

2) Different <info> elements MAY be used to support two separate <area>s that are experiencing different levels of threat, where each <area> uses the same <category>, <event> and <eventCode> values in both <info> elements, but requires different <urgency>/<severity>/<certainty> values.

3) Multilingual messages MUST use separate <info> elements for each language, with all non free-form text elements repeated verbatim in each element.  Each element must be identical (i.e., they MUST have the same <eventCode>, urgency, severity, certainty, geocodes) except for those elements which will differ because of language such as free form text and resource links. 

4) Multiple <eventCode> elements MAY be included in order to support interoperability between message producer and consumer systems e.g. interpretation of AUeventLIST codes and other nations event code lists.

Policy

Example: Weather alert for public distribution:

<alert>

   …

   <status>Actual</status>

   <msgType>Alert</msgType>

   <source>example@bom.gov.au</source>

   <scope>Public</scope>

   …

   <code>urn:oasis:names:tc:emergency:cap
:1.2:profile:CAP-AU:1.0</code>

   …

   <info>

      …

   </info>

</alert>

language

OPTIONAL

Notes:

1) If this sub-element is used, the value SHALL be blank or “en-AU” or an alternate language code that is identified in accordance with country codes specified in the “Codes for the Representation of Names of Languages (ISO 639.2)”

2) CAP v1.2 assumes that a blank or null value in this element SHALL be considered equivalent to US English or “en-US”.  

3) "en-AU" SHALL be used when the CAPv1.2 default value of "en-US" is not acceptable for the content of the message (standard language code for Australian English defined by ISO 3166-1 alpha-2). 

4) When this sub-element is to be included, the alert message producer MUST ensure an appropriate value is used.

5) The language value is important for message distributors.

6) Mixing public display content or text from different languages within the same <info> element is not allowed, except for inherently multilingual content (people, places, things) that may or may not include accented characters.  Where fixed CAP values, which often appear as a word from a specific language, are used for software processing purposes and not for display, these values are not translated between <info> elements (e.g. <category>, <urgency>, <severity>, <certainty>, <responseType>, etc…).

7) When creating public alert messages in languages other than English, a translation of the event list to the appropriate language should be conducted in advance for inclusion in alerts.

Technical

Example A. Original INFO element expressed in Australian English and enumerated <urgency> value of “immediate” written in english :

<info>

   <language>en-AU</language>

   …

   <urgency>Immediate</urgency>

   …

   <headline>Chemical spill Highway 1
      </headline>

   …

</info>

Example B. INFO element translated into Italian and enumerated <urgency> value of “immediate” written in English:

<info>

   <language>ita</language>

   …

   <urgency>Immediate</urgency>

   …

   <headline>Chimica fuoriuscita Highway 1
      </headline>

   …

</info>

event

REQUIRED

Note:

A CAP-AU Profile message SHALL include only one <event> value that is extracted from either the Tier I or Tier II column of the Australian Event Code List for CAP-AU Profile (AUeventLIST).  Using these pre-defined values ensures that all public alert messages are using common terminology to describe hazard events.

Policy

responseType

OPTIONAL

Note:

It is RECOMMENDED that alert message producers include response types when applicable, along with a corresponding <instruction> value.  Using <responseType> allows for automated dissemination in all included languages, of the actions the end user is expected to take when instructions may not be available, or not available in all languages

Technical

Example:

<alert>

   …

   <info>

      …

      <responseType>Shelter</responseType>

      <responseType>Monitor</responseType>

      …

      <instruction>Take cover as threatening conditions approach and monitor local media broadcasts for further updates</instruction>

   …

   </info>

<alert>

urgency

REQUIRED

Note:

Australian jurisdictions / organisations MAY need to further restrict the urgency values for use within their particular jurisdiction / organisation. However consuming systems should accept the entire set of values.

Technical

Example:

The Bushfire Alerts Levels used in Australia could be mapped to the CAP v1.2 enumerations as follows:

Advice = Expected

Watch and Act = Expected

Emergency Warning = Immediate

severity

REQUIRED

Note:

Australian jurisdictions / organisations MAY need to further restrict the severity values for use within their particular jurisdiction / organisation. However consuming systems should accept the entire set of values.

Technical

Example:

The Bushfire Alerts Levels used in Australia could be mapped to the CAP v1.2 enumerations as follows:

Advice = Moderate

Watch and Act = Severe

Emergency Warning = Extreme

certainty

REQUIRED

Note:

Australian jurisdictions / organisations MAY need to further restrict the certainty values for use within their particular jurisdiction / organisation. However consuming systems should accept the entire set of values.

Technical

Example:

CAP v1.2 Standard

eventCode

OPTIONAL

Notes:

1) <valueName> SHALL be “https://govshare.gov.au/xmlui/handle/10772/6495” or alternate event code list if authorised.

2) <valueName> MUST reflect the unique short title or URL of the authorised event code list that is to be the source for the <event> value. 

3) The CAP-AU Profile SHALL constrain each alert message to one single value from an authorised <eventCode> list in order to avoid any potential confusion or difficulty handling a single alert message containing multiple events.

4) Conventions regarding Event Codes:  Code lists not defined by this Profile or not recognised by a receiver SHALL be passed through by CAP-AU Profile-compliant devices.  This acknowledges the possible existence of other Australian and non-Australian codes which may appear in alert messages.

5) The version suffix shown in <valueName> (e.g. “:2.0”) will change as new versions of the AUeventLIST document are published.  As <eventCode> is a multi-use element, messages may be created that use codes from different versions of the Event References document in order to provide backward compatibility and to ease transition between list updates.

Technical

Example A. For the AUeventLIST:

<valueName>https://govshare.gov.au/xmlui
/handle/10772/6495</valueName>

Example B.  Acceptable – shows two <info> elements with same <event> code, but different <area> data indicating a different <severity> value is relevant to each area.

<alert>

   …

   <info>

      …

      <event>Thunderstorm</event>

      …

      <severity>Extreme</severity>

      …

      <eventCode>

<valueName>https://govshare.gov.au

/xmlui/handle/10772/6495</valueName>

         <value>thunderstorm</value>

      </eventCode>     

      …

      <area>

         <areaDesc>area 1</areaDesc>

         …

         <geocode>

<valueName>http://www.ga.gov.au
/place-name/</valueName>

<value>XXX</value>

         </geocode>        

         …

      </area>

   </info>

   <info>

   …

   <event>Thunderstorm</event>

   …

   <severity>Moderate</severity>

   …

   <eventCode>

         <valueName>https://govshare.gov.au/xmlui/handle/10772/6495</valueName>

      <value>thunderstorm</value>

   </eventCode>  

   …

   <area>

      <areaDesc>area 2</areaDesc>

      …

      <geocode>…</geocode>

      …

   </area>

   </info>

</alert>

Example C. Not Acceptable – shows two <info> elements with different <event> codes:

<alert>

   …

   <info>

      …

      <event>Thunderstorm</event>

      …

      <eventCode>

<valueName>https://govshare.gov.au
/xmlui/handle/10772/6495</valueName>

<value>thunderstorm</value>

   </eventCode>

      …

      <area>

         <areaDesc>area 1</areaDesc>

         …

         <geocode>…</geocode>

         …

      </area>

   </info>

   <info>

   …

   <event>Tornado</event>

      …

      <eventCode>

<valueName>https://govshare.gov.au
/xmlui/handle/10772/6495</valueName>        

<value>tornado</value>

      </eventCode>     

      …

      <area>

         <areaDesc>area 2</areaDesc>

         …

         <geocode>…</geocode>

      </area>

      </info>

</alert>

Example D. For an updated version of the AUeventLIST where codes may need to be used from the previous list during transition to the new list:

<eventCode>

<valueName>https://govshare.gov.au/xmlui
/handle/10772/6495</valueName>

   <value>civilEmerg</value>

</eventCode>

<eventCode>

<valueName>https://govshare.gov.au/xmlui
/handle/10772/6495</valueName>

   <value>cccccccccccc</value>

</eventCode>

Example E. For the Canadian event code list:

<eventCode>

   <valueName>profile:CAP-CP:xxxxxxx:n.n
   </valueName>

   <value>cccccccccccc</value>

</eventCode>

Where xxxxxxx denotes the short title of the Canadian list; n.n denotes the version number of the Canadian list; and cccccccccccc denotes the actual event code to be used.

effective

OPTIONAL

Notes:

1) Messages are considered to be effective when sent, so if this element is not included, the effective time SHALL be assumed to be the same as in <sent>.

2) Usually only included when <msgType> <value> is Alert, in order to direct the effective time of the alert message.

3) DO NOT use when <msgType> <value> is Cancel.

4) When the content of a message applies across multiple timezones, the message producer SHOULD use UTC times in preference to local times.  The message producer SHOULD consider whether the message consumer is capable of converting UTC to the correct local time

Technical

Example A. Correctly formatted <effective> time in Hobart, Tasmania at 0700 AEST:

<alert>

   …

   <sent>2011-05-13T07:00:00+10:00</sent>

   …

   <info>

      …

      <effective>2011-05-13T07:00:00+10:00
        </effective>

      …

   </info>

</alert>

Example B. Same as A) but using UTC equivalent to 0700 AEST: 12 May 2011 at 2100 hours.

<alert>

   …

   <sent>2011-05-12T21:00:00-00:00</sent>

   …

   <info>

      …

      <effective>2011-05-12T21:00:00-00:00
        </effective>

      …

   </info>

</alert>

expires

OPTIONAL

Notes:

1) It is RECOMMENDED that alert message producers provide an <expires> value so that distributors, aggregators, recipients and message consumers can interpret how long the information within an <info> element of an alert message should remain in effect.

2) When the content of a message applies across multiple timezones, the message producer SHOULD use UTC times in preference to local times.  The message producer SHOULD consider whether the message consumer is capable of converting UTC to the correct local time.

Technical

Example A. Correctly formatted <expires> time in Darwin at 0700 UTC:

<alert>

   …

   <info>

      …

      <expires> 2011-05-13T07:00:00-00:00
        </expires>

      …

   </info>

</alert>

Example B. Invalid formats:

   <expires></expires>

   <expires>0</expires>

   <expires>0000-00-00T00:00:00-00:00</expires>

   <expires>””</expires>

   <expires>2011-05-13T07:00:00</expires> (missing UTC zone)

senderName

OPTIONAL

Notes:

1) It is strongly RECOMMENDED that this element be populated by alert message producers as this value is expected to be used for public presentation purposes.

2) To be the publicly-recognisable name of the agency issuing the alert.

3) The full text, or at least the first ten words, of this element could be used in the construction of recorded audio or text-to-speech audio.

4) The full text, or at least the first 60 characters, of this element could be used in the construction of video display text.

Technical

Example:

<alert>

   …

   <sender>example@dfes.wa.gov.au</sender>

   …

   <info>

      …

      <senderName>Western Australia Police

      </senderName>

</alert>

headline

OPTIONAL

Notes:

1) Headline SHALL include human readable adaptations of the following sub-elements that message consumers can be expected to understand:

a) text associated with <event>,

b) text associated with <areaDesc> value(s), and

c) the word “to” followed by value for <expires>.

2) The full text, or at least the first ten words, of this element could be used in the construction of recorded audio or text-to-speech audio.

3) The full text, or at least the first 60 characters, of this element could be used in the construction of video display text.

Technical

Example:

CAP v1.2 Standard

description

OPTIONAL

Notes:

1) Address essential information first as content may get truncated during transmission.

2) The full text, or at least the first ten words, of this element could be used in the construction of recorded audio or text-to-speech audio.

3) The full text, or at least the first 60 characters, of this element could be used in the construction of video display text.

Technical

Example:

CAP v1.2 Standard

instruction

OPTIONAL

Notes:

1) Should be completed by alert message producers to improve clarity and provide public with direction concerning what actions to take in order to stay out of harm’s way.

2) In circumstances where the <instruction> information is to be added by an alternate authority; the message producer will distribute the initial alert message (without an <instruction> element included) and the alternate authority will receive that message and add the <instruction> element as well as identify the new authoritative source for the information through the <senderName> and other applicable values then re-distribute the message accordingly.

3) Address essential information first as content may get truncated during transmission.

4) The full text, or at least the first ten words, of this element could be used in the construction of recorded audio or text-to-speech audio.

5) The full text, or at least the first 60 characters, of this element could be used in the construction of video display text.

Technical

Example:

The Bureau of Meteorology issues a cyclone warning using a CAP message.  The Bureau has no authority to issue evacuation notices, so an alternate authority like Emergency Management Queensland (EMQ) would re-distribute the cyclone warning with an <instruction> element included.

parameter

CONDITIONAL

Notes:

1) The values are not case sensitive, and SHALL NOT be translated.  Multiple MinorChange elements are allowed.

2) It is recommended that alert message producers indicate when an update message contains non-substantive content changes in order to support advanced distribution decisions associated with reducing the number of cases of over-alerting.

3) When an alert message is considered a minor update, all <info> elements MAY contain a “MinorChange” parameter value(s) with an appropriate value setting that details the extent of the minor change: 

   <valueName>urn:oasis:names:tc:emergency:cap:1.2
:profile:CAP-AU:1.0:MinorChange</valueName>

4) When no change has occurred in an <info> element relative to the previous message, the value of “none” SHOULD be used.

5) Substantive changes.  Adding or removing an <info> element relative to the previous message is considered a substantive change.  If a message consumer chooses to ignore this parameter and value, all update messages should be considered substantive as per the intent of the CAP v1.2.

6) If a transmission error occurs and the message consumer does not receive the referenced previous message to which the non-substantive change applies, the current message SHOULD be considered substantive.

7) Non-Substantive changes.  This element MUST only be used when all <info> elements in a message contain non-substantive content changes or no change.  The addition, removal, or change of the following elements MAY be considered non-substantive:  <audience>, <headline>, <description>, <instruction>, <web>, <contact>, <parameter>, <areaDesc>, and <resource> sub-elements.  Electing to process non-substantive content is left up to the message producer or consumer.

8) Both message producer and consumer systems are free to impose additional constraints on what they consider to be non-substantive changes.

9) When a change has occurred between <info> elements, the value of “text” SHOULD be used in the <info> element(s) where applicable.  For example: some free form text content may have been added or modified.

10) When a correction is made to some free form content, the value of “correction” SHOULD be used in the <info> element(s) where applicable.

11) When the addition, modification, or removal of a <resource> sub-element and its associated content takes place relative to the previous message, the value of “resource” SHOULD be used in the <info> element(s) where applicable.

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 other 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.

Technical

Example:

   <parameter>

      <valueName>

        urn:oasis:names:tc:emergency:cap:
        1.2:profile:CAP-AU:1.0:MinorChange
         </valueName>

      </value>correction</value>

   </parameter>

2.3 “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 CAP-AU message.  The <resource> sub-elements SHOULD be used to provide supplemental information, such as images or audio files, to assist a message consumer to better understand the context of the event. [There are no profile considerations for this element.]

2.4 “area” Element and Sub-elements

Any <area> sub-elements whose use is specified as REQUIRED, are only mandatory inclusions when the <area> element is to be included in a CAP-AU message.

Geographic locations in Australia SHOULD be referenced to the Geocentric Datum of Australia 1994 (GDA94).  The Intergovernmental Committee on Surveying and Mapping advises that for most practical applications, [GDA94] coordinates can be considered the same as [WGS 84]; therefore, CAP-AU accepts that for the practical purposes of public alerting, the coordinates derived from a [GDA94] reference system SHALL be considered to be equivalent to [WGS 84] coordinates that are required by CAP v1.2.

area

OPTIONAL

Notes:

1) MUST include a minimum of one recognised <geocode> value.

2) Where multiple <area> elements are used, consolidation of <area> elements into as few <area> elements as possible is RECOMMENDED.

3) Area descriptions (like events) MUST be translated by the message producer in cases where the name is not derived from the preferred Location Reference source to ensure the intended audience for the message recognises the area being described.

4) In the case of both single and multiple <area> elements, each <areaDesc> MUST have one value and will be in the language of the <info> element.

5) It is RECOMMENDED that an associated geospatial value for the <polygon> or <circle> elements be included in the <area> element as well.  The use of <polygon> and <circle> are preferred where the message consumer has the ability to interpret the geospatial information in those sub-elements.

6) Avoid using both <polygon> and <circle> in a single message when possible; however, if both are used then the <area> should be considered to be the union of the <polygon> and <circle> sub-elements.

Technical

Example:

<info>

   …

   <area>

      <areaDesc>Near Bowen, QLD</areaDesc>

      …

      <circle>-20.085,147.764 10</circle>

      <geocode>

<valueName>http://www.iso.org/iso
/country_codes.html</valueName>

<value>AU-QLD</value>

      </geocode>

      …

   </area>

</info>

Where: -20.085,147.764 is the Lat/Long for the area near Bowen; and 10 is the radius value in kilometres (Note there is a space character separating the radius value from the lat/long).

areaDesc

REQUIRED

Notes:

1) Textual description of the area SHALL be defined by the combination of area elements that is recognisable to the message consumers.

2) The value SHALL be derived from the Location Reference document specified under <geocode> or other location source providing the source is recognised by the message consumer.

3) The full text, or at least the first ten words, of this element MAY be used in the construction of recorded audio or text-to-speech audio.

4) The full text, or at least the first 60 characters, of this element MAY be used in the construction of video display text.

Technical

Example:

CAP v1.2 Standard

geocode

OPTIONAL

Notes:

1) <geocode> SHOULD be used as the backup method to define alert areas whenever the consumer system has no ability to interpret the more accurate geospatial information stated in <polygon> or <circle> sub-elements.  Multiple <geocode> sub-elements MAY be used as necessary to fully cover the target area for the alert message.

2) The RECOMMENDED Location Reference source for Australia is the Geo-coded National Address File (G-NAF), maintained by PSMA Australia on behalf of the members of the Intergovernmental Committee on Surveying & Mapping (ICSM). G-NAF covers locations and addresses within the complete national geography of Australia.  The latest version of G-NAF can be sourced from: http://www.psma.com.au/?product=g-naf

3) Location information from the following secondary sources would also be considered suitable to specify if warranted by the hazard situation:

a) ISO3166-2 when the area to be covered by the message includes a whole State region (refer: http://www.iso.org/iso/country_codes.html);

b) Gazetteer of Australia available from Geoscience Australia (refer: http://www.ga.gov.au/place-name/ ; and

c) Postcodes with four (4) decimal characters and no space between characters (refer: http://www.psma.com.au/?product=postcode-boundaries)

4) A <geocode> consisting of the ISO3166-2 designator for the continent of Australia (i.e. AU) SHALL be used to indicate a message intended for the entire continent of Australia and its Territories.

5) Messages MAY include <geocode>s from different Location Reference sources in order to provide backward compatibility and to ease transition between list updates.

Technical

Example A (for note 2):

<geocode>

<valueName>http://www.psma.com.au
/?product=g-naf</valueName>

<value>…</value>

</geocode>

Example B (for note 3.a):

<geocode>

<valueName>http://www.iso.org/iso
/country_codes.html</valueName>

<value>AU-VIC</value>

</geocode>

Example C (for note 3.b):

<geocode>

<valueName> http://www.ga.gov.au
/place-name/</valueName>

<value>…</value>

</geocode>

Example D (for note 3.c):

<geocode>

<valueName>http://www.psma.com.au
/?product=postcode-boundaries
</valueName>

<value>2600</value>

</geocode>

Revision

Date

Editor

Changes Made

WD01

30 Nov 2011

Elysa Jones

First complete draft with base provided by Greg Trott and CAP Profile Subcommittee decisions included

WD02

1 Dec 2011

Elysa Jones

Changes addressed during CAP Profile Subcommittee meeting 30 Nov 2011:

a. Added lines 101-102 in non-normative section 1.5 and note into header of “area” element on page 31 regarding GDA94

b. Removed note from page 13 and updated all occurrences of the URN for the profile on pages 5, 10, 11, 12, 16, 18, 19, 20, 21, 22, 23, 27, 28, 31, 32, 33 to “urn:oasis:names:tc:emergency:cap
:1.2:profile:CAP-AU:1.0”

c. Removed note from page 34 and updated all occurrences of the conformance target names on pages 33 and 34 “CAP-AU”

d. Corrected the company names for Trott, Leinenweber and Grapes in the acknowledgements

e. Updated the table of contents

WD03

9 Dec 2011

Elysa Jones

Changes addressed during the EM-TC meeting 6 Dec 2011:

a. Removed the reference to CAP Logo and guidance from the last line of the Notices section.  It will now appear on the front page in the related works section.

b. Deleted lines 105-113 of the non-normative section which referenced attachments to an Australian document.

WD04

30 Jan 2012

Elysa Jones

Changes addressed by the CAP Profiles subcommittee in response to public review comments:

a. Removed brackets around copyright in the OASIS notice, added related works section to cite the CAP logo Committee Note, and fixed formatting of the pdf.

b. Corrections to Table 1: corrected a document name; added clarifying sentence to Note 1 <event> sub-element; corrected sentence in Note 1 of <eventCode>; added words to Note 2 of <eventCode>; added sentence to Note 3 of <eventCode>;  fixed <value> in Example B of <eventCode>; added clarification to Note 7 of <area>; clarified Note 1 of <geocode>; added new <area> Note 8; fixed typo in Note 2 of <effective>; corrected  <expires> time in the example; added examples to <urgency> and <severity>; clarified Notes for <urgency>, <severity> and <certainty>; fixed typos in <effective> and <resource> elements; clarified Notes for <urgency>, <severity> and <certainty>

c.  Add term “Layer” and definition to 1.3

d.  Additional changes to Table 1:  removed Note 2 from <alert>; added recommendation to Note 1 of <sender>; changed Note 3 of <sender> to use message identifier and source element; removed Note 4 and Example 4 of <sender>; changed <source> to <sender> and corrected placement of <sender> in Example A of <msgType>; removed Note 3 and renumber subsequent notes of <info>; added clarification of what must be identical in multilingual messages of <info>; deleted Note 2 and Note 3 and moved examples from <event> to <eventCode>; clarified Note 3 and Note 4 of <eventCode>; changed <effective> and <expires> from REQUIRED to OPTIONAL; clarified Note 1 and removed Note 2 from <expires>; reworded Note 1 and removed Note 4 in <effective>; changed <effective> Examples A and B; corrected Note 2 of <instruction>; added sentence to Note 1 of <parameter>; corrected Note 2 of <parameter>; corrected Note 3 of <parameter>; removed Note 15 and 16 from <parameter>; removed Notes 1, 2, 3 from <resource>; corrected URN in example of <area>; removed Note 2 of <area>; removed Note 6 of <area>; replaced 8 Notes in <geocode> with 5 Notes and corrected corresponding example references; corrected URN in Example B and D of <geocode>;

e. Switched headers for Table 1 “Use” and “Type”

WD05

14 Mar 2012

16 Mar 2012

Elysa Jones

Werner Joerg

Minor corrections to update publication dates, address minor spelling and spacing errors.

Fixed formatting and footers.

CSD03

9 Aug 2013

Greg Trott

Minor corrections requested by the Australian CAP Stakeholder Group, and a subsequent review of proposed changes conducted on behalf of the EM‑TC by Darrell O’Donnell, Gary Ham and Norm Paulsen.