CAP – Demonstration of Practice (Implementation Workshop – Geneva, Switzerland 9-10 December 2008) Norm Paulsen (norm.paulsen@ec.gc.ca) Meteorological Service of Canada (Toronto) - Information Strategy Section December 9th, 2008

Alerting Scenario Imagine an event that is extremely critical (Tornado) Imagine a message Originator having difficulty keeping up with the unfolding situation (Tornado outbreak) Imagine the overall threat zone expanding in size (outbreak expanding to new areas) Imagine the initial CAP file has already been transmitted some time ago Let’s pick up the activity in progress….

Sample 6 p.m. local time (tornado outbreak) - <info>: Area 1 threat polygon (in this case it includes the area of concern over the <expires> time

Status 7 p.m. local time (numerous tornadoes reported) - <info>: new Area 2 threat polygon (again it includes the area of concern over the <expires> time

Alert Block? 7 p.m. local time (what does the CAP file contain?) - <msgType>Update (summarize the whole event) ..or.. - <msgType> Alert (focus on new threat area)

Message Originator… May not want to bother with updating previous threat zone information when under pressure to issue information on the new threat zone May have additional time constraints such as translation times and coordination issues with other jurisdictions Real life might suggest <msgType>Alert be optional (or even standard) in this Scenario No Area 1 referenced in the 7 p.m. CAP message

Perspective? If CAP is to be processed as designed (using XML philosophy and proper data theory principles) then… <msgtype>alert should work fine for the 7 p.m. message 6 p.m. message is still applicable Taking a closer look at <msgType>update <msgType> is an element of the <alert> block and Update implies that the information in all the containing <info> blocks is to supersede any previously <referenced> CAP file In this case the <info> block details from the first CAP file at 6 p.m. would be replaced by information included in the new CAP file at 7 p.m. So what does the <info> block for Area 1 contain?

<msgType>Update Is the 7 p.m. <info> block for area 1 auto-updated with new times for <effective>, <onset>, <expires>, etc… or are they left as is? Issuer may not be comfortable with the results of auto-updated time information on the previous threat zone as it could impact the integrity of <description>, <headline>, etc… However, if the <info> block is just repeated (all elements including time references), the presentation of the information should appear unchanged to the end client Real life might suggest <msgType>Update include a total repeat of the earlier <info> block Area 1 information in the 7 p.m. CAP message repeated and displays unchanged

Originator Concerns with <msgType>=Update? Is <urgency>, <severity> and <certainty> ok as they are? Is the <description> element still relevant? Are <effective>, <onset>, and <expires> times automatically updated or remain as they were? Does the distributor display an “Updated at X:XX time” Do they use <sent> or <effective>? Can they handle <effective> and <onset> be in the past? If <expires> occurs around the same time as the Update does the <info> block just disappear?

Originator concerns with <msgType>=Alert? Can a distributor accommodate multiple <info> blocks from different CAP files from different times The <references> and <incidents> elements in CAP suggests they are expected to do so Can two CAP message files combine and update into one file in a subsequent issue? The <references> element in a CAP file suggests it can

Conclusions Originators may… Off topic but… make use of <msgType>Alert in an threat zone expanding scenario repeat an <info> block in <msgType>Update and not update any time references or <description> elements Off topic but… use <msgtype>Alert to solve “upgrading” and “downgrading” scenarios keep all areas in separate messages (not advised) in order to use the <msgType>Cancel in a similar fashion