2009 VICTORIAN BUSHFIRES ROYAL COMMISSION
Letters Patent Issued 16 February 2009
Witness Statement of Jillian Patricia Edwards
Date of Document: 3 June 2009
Filed on behalf of:
Australasian Fire and Emergency Service Authorities Council (AFAC)
Prepared by: AFAC Corporate Counsel
ANNEXURE 8
WIT.039.001.0053
(. I,f ~, c,o I: 0 I
" '. 1'·6.· ..'.." '. "~',~."
.1j'-:UITn6lritldenG:lfi·w:CAP~V1.1
l .. :"j:'m,:http://www.oasls-open.org/appslorg/workgrouplemergenoy/download.php/14205/emergencyCAPv1.1-Committee%20Speclflcation.doc
·:l--nical ;"'kn,,\;~l·.:"
OASIS Emergency Management TC~~l~m'{~):
ElysaJones, Wamlng Systems, Inc <[email protected]'n>Art Sotterell, Individual <acb@lncid,iJ,Tl,com>
Aki!3'in"c~:
TheCommon Alerting Protocol (CAP)ls asimple butgeneral format for exchanging all-hazardemergenoy alerts and public warnings over all kinds ofnetworks. CAPallows a consistentWaming message to be disseminated simultaneously overmanydifferent warning systems, thusincreasing warning effectiveness while simplifying thewamlng task. CAPalso facilitates thedetection of emergingpatterns In localwamlngs ofvarious kinds. such as might Indicate anlJl1detected hazard or hostile act. And CAP prOVides a template for effective waming messagesbasedon best practices Identified In academic research andreal-world experience.
$~tlllle:
This document is the OASIS standard, adopted bya vote of the general membership endingSeptember 30,2005. Additional infonnation, including implementation guidelines and samplefiles, maybe found through theEmergency management TCweb page(htq Ilw\A~"J.oa~'ls~
OI'I;;,\;.tx~i,:r·: ,l:"nlttsss/emargancy/).
For information on whether anypatents have been disclosed that maybeessential toimplementing this apeclfloatlon, and anyoffers of patent 1I0ensing terms, please refer to theIntellectual Property Rights section of the Emergency Management TC webpage(http://wlfliw.oasis~open.org/committees/emergsncylipr.php).
CAP-V1.1Copyright © OASISOpen 2005. All Rights Reserved.
1 October 2005Page 1 or 3'5
WIT.039.001.0054
[, I ( '{l"j'CC.C, .• ' ,', t:
OASIStakes no position regarding the validity or scope of any intellectual property or other rights thatmight be claimed to pertain to the Implementation oruseof the technology described inthis documentorthe extentto whichany license under such rights might or mightnot be available; neither doesItrepresentthat it has made any effort to identify any sucl1 rights. Information on OASIS's procedures withrespectto rights in OASIS specifications can befound at the OASIS website. Caples ofclaims of rightsmadeavailable for publication and any assurances oflicenses to be madeavailable, or the resultof anattemptmade to obtain a general license or permission for the use of suchproprietary rights byImplemantors or usersof this specification, can be obtained from the OASIS President.OASIS invites any interested party to bringto Itsattention any copyrights, patents or patent applications,or other proprietary rights whichmay covertechnology thatmay be required to Implement thisspeoiflcatlon. Please address the Information to theOASIS President.Copyright© OASIS Open 2005. All Rights Reserved.
This document andtranslations of it may be copied andfurnished to others, andderivative worksthatcommenton or otherwise explain It or assist In itsImplementation may be prepared, copied, publlshedand distributed, In whole or Inpart, without restriction of anykind, provided that the above copyright noticeand this paragraph are included on all such copies and derivative works, However, this document itselfdoes not be modified in anyway, such as by removing the copyright notloe or references to OASIS,exceptas needed for thepurpose of developing OASIS specifications, Inwhich case theprocedures forcopyrights defined In the OASIS Intellectual Property Rights document mustbe followed, or as required totranslate It into languages otherthan Engllsh,The limited permissions granted above are perpetual andwill not be revoked by OASiS or its successorsor assigns.This document andthe information contained herein is provlded on an "AS IS" basis and OASISDISCLAIMS ALI-WARRANTIES, EXPRESS ORIMPLIED, INCLUDING BUTNOT LIMITED TO ANYWARRANTY THAT THEUSEOF THE INFORMATION HEREIN WILL NOTINFRINGE ANY RIGHTS ORANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FORA PARTICULAR PURPOSE.
CAP·V1.1Copyright@ OASIS Open2006. All Rights Reserved,
1 October2005Page20f36
WIT.039.001.0055
Introduction , , 41.1 Purpose ,.....•,.., ' " .., , , ," " ""'"'' ,.,,.., , " ,.", " ,,.."..41.2 History , , , , ,.41,3 Structure of the CAPAlert Message 4
1.3.1 <alert> , , , , , 51.3.2 <Info> ,', .., , , , , 51.3.3 <resource> , " , , 51.3.4 <area> , " , , 5
1.4Applications of the CAP Alert Message , :..51.5Terminology 51.6Normative References , " " ..6
2 Design Principles and Concepts (non-normative) 72.1 Design Philosophy., , , , 72.2 Requlremente for Oe8Ign , " " 72.3 Examples of Use Scenarios : " ,.." " , " 8
2.3.1 Manual Origination , , , 82.3.2 Automated Origination by Autonomous Sensor System 82.3.3 Aggregation and Correlation on Real-time Map " 82.3.4 Integrated 'PubllcAlartlng"." . , 82.3.5 RepUdiating a FalseAlarm 9
3 AlertMessage Structure(normative) , 10
3.1 Document Object Model 103.2 Data Dictionary , 11
3.2.1 'Ialert" Elementand Sub-elements " 113.2.2 "info"Elementand sub-elements " , , :143.2.3 "resource" Element and Sub-elements " "." " 213.2.4 "area"Element andSub-elements " 22
3.3 Implementation Notes : , 253.3.1 WGS-84 Note , 253.3.2 Security Note , 25
3.4XMLSchema , 25Appendix A. CAPAlert Message Example , , 29
A.1. Homeland SecurityAdvisory System Alert " 29A.2. Severe Thunderstorm WarnIng " , , 30A.3. Earthquake Report , 31AA. AMBER Alert (Including EAS Activation) 32
AppendIx 8. AcknOWledgments , 33OASIS Emergency Management Technical Committee 33
AppendiX C. Revision History , 35
CAP-V1.1Copyright© OASISOpen 2005, All RIghts Reserved.
1 Oclober2005Page3 of 35
WIT.039.001.0056
85
8687688990919293949696979899
100101102103104105106107108109110111112
[RFC2119]
[dateTime]
[FIPS 180~2]
[namespacas]
[RFC2046J
[RFC2119]
[RFC3066]
I,WGS 84]
[XML i.0}
[XMLSIG)
[XMLENC)
S. Bradner, Key wordsfor use in RFCsto Indicate Requirement Levels,i::r ofg ':1c/rfc:2119.txt, IETFRFC2119, March 1997.
N. Freed, XML Schema Part 2: Datatypes Second Edition,hitp:llwl/vw,w3.orgi ,'; \,;,1,"schema-2N.'d"rteTime,W3C REC-xmlschema-2,October2004.National Institutefor Standards andTechnology, Secure Hash Standard,http://csrc.nlstgov/jJbllcalions/fipsfi'iI' ;j ., 0-2/fij.::; r Q~·'·iithc! .ngenoiice.IJdf,August2002.T. Bray, Namespaces InXML, http://w\filw.w3.org/rr~/REC-)(rnl·names/, W3CREC-xml-names-19990114, January 1999.N.Freed, MUltipurpose Internet Mall Extenslqns (MIME) PartTwo: Media Types,htlp:llwww.iet'f."rg/li·.hi<;<;,.>W.L-:" IETF RFC2046, November 1996.S. Bradner, Key wordsfor use InRFCsto Indioate Requirement Levels,l..Itlp:llwww.i....tf.orglrfc!iL..:;·.lt-J .•:;(. IETF RFC 2119, March 1997.H. Alvestrand, rags for theIdentification of Languages,htij:;,·i''''',\,.ietf.org/rld: 'I :~.(;,jr.:.l,'.i, IETF RFC 3066, January 2001.National Geospatial Intelligence Agency, Department of Defense WorldGeodeticSystem 1984, I.Llp:/iJc1i(i,·i:l(u.lidi:'i,:il/Gand(i!ll'i)::>i50.).hhni, NGA TechnicalReportTR8350.2, January 2000.T. Bray, Extensible Markup Language (XML) 1.0 (Third Edillon),htlp:llwww.w3.ol·g/;.~.!<ii:; .:;!i. W3C REC-XML-20040204, February 2004.Eastlake, D., Reagle, J. and Solo, D. (editors), XML-Slgnalure Syntax andProcessing, .: 'iJ/ fiU:\:: writ., "';J:ilul,'ii;)',cofe-20020212/, W3CRecommendation, February 2002.Eastlake, D. and Reagle, J. (editors), XML Encryption Syntax andProcessing,htll:,:llwww.W3.orglTR/2002/REC-xmlenc-core-2002121 01, W3CRecommendMion, December 2002.
CAPN1.1Copyright © OASIS Open 2005. All Rights Reserved,
1 October 2005page6 of 35
WIT.039.001.0057
113 g g(~~OQlrro [PfJHull~e~~®~ ~[(1(Cn ~~©)nl1~®lg~~~ ~fi'U(O)~1\"'!rU(QJfiQITlf1J@l~~~@~
114 z,~ [iJ~si~ru Phih)$iDphy115 Among the principles which guidedthe design of theCAPAlertMessage were:
116 0 Interoperability - Firstand foremost, the CAP AlertMessage should provide a means for117 interoperable exchange of alerts andnotifications amohg all kinds of emergency Information118 systems.119 0 Completeness - TheCAPAlertMessage format should provide for all theelements of an120 effective publlcwarnln", message.
121 0 Simple Implementation - Thedesign should notplace undue burdens ofcomplexity on122 technical implementers. .
123 0 Simple XlIIlL and portable structure - Although theprimary anticipated use of the CAP Alert124 Message Ieas anXMLdocument, the format should remain sufficiently abstract to be adaptable125 to othercoding schemes.126 0 Multl-ua& fonnat - Onemessage schema supports multiple message types (e.g., alert! update!127 cancellations I acknowledgements! errormessages) Invarious applications (actual! exercise!128 test! system message.)129 G Familiarity - The dataelements and code values should bemeaningful towarning originators130 andnon-expert recipients alike.131 0 Inltrdllclpllnary artdlnternatlonal utility - Thedesign should allow a broad range of132 applications In public safety andemergency management and allied applications andshould be133 appllcabl~ worldwide.
134 ~.~ ~sqQ,d&'emlt:lfll~$ fior Desig8IJ135 Note: ThefollowIng requirements wereused as a basis fordesign and review of the CAP136 AlertMessage format. This list Isnon-normative and notintended to beexhaustive.
137 TheCommon Alerting Protocol SHOULD:138 '" Provide a specification for a simple, extensible format for digital representation of warning139 meSsages and notlflcatlons;140 '" Enable Integration of diverse sensor and dissemination systems;
141 0 Beusable over multiple transmission systems, including both TCPIIP-based networks and one-142 way"broadcast" channels;143 o Support credible end-to-end authentication and validation ofall messages;
144 e Provide a unique identIfier (e.g., an ID number) foreach warning message and for each message145 originator;146 e Provlde formUltiple message types, such as:
147 - Warnings148 - Acknowledgements149 - Expirations andcancellations150 - Updates and amendments151 - Reports of results fromdissemination systems152 - Administrative and system messages
153 0 Provide formultiple message types, such as:
CAP·V1.1Copyright II:) OASISOpen2005. All Rights ReselVed.
1October 2005Page7 of 35
WIT.039.001.0058
154 - Geographic targeting155 - Levelof urgency156 - Level of certainty157 - Levelof threatseverity
158 "Provide a mechanism for referencing supplemental information (e.g,. digital audio or Image files,159 additional text);
160 0 Usean established open-standard data representation;
161 0 Be basedona program of real-world cross-platform testing and evaluation;
162 Q Providea clearbasis fer certification andfurther protocol evaluation and Improvement; and,
163 o Provide a clearlogical structure that is relevant and clearly applicable to theneeds of emergency164 response and public safety users andwarning system operators.
165 ~DJ ~~SJm~O>~®$ ©~ Uh$~ ~C®llUtBJlT!(0~
166 Note: The follOWing examples of use scenarios were usedas a basis for design and167 review of the CAPAlertMessage format. These scenarios arenon-normative and not168 intended to be exhaustive or to reflectactual practices.
169 ~D~D '\I M~~U21! Olti~ifl1l21\thjlf{iJ
170 "The Incident Commander atan industrlal firewithpotential of a majorexplosion decides to issue a public171 alert withthree components; a)An evacuation ofthe area within halfa mileof the fire; b) a shelter-in-172 place instruction for people Ina polygon roughly describing a downwind dispersion 'plume' extending173 severalmilesdownwind andhalfa mile upwind from thefire; andc) a request for all media and civilian174 aircraftto remain above 2500 feetaboveground level when within a halfmileradius of the fire.175 "Usinga portable computer anda web page(and a pop-up drawing toolto enterthepolygon) the Incident176 Commander Issues the alertas a CAP message toa local alerting network."
177 ~D~.2 Au~oma1ed Origina~i(m by AuioriomollJs SenSOi" Sysiarri178 "A set of automatic tsunami warning sirens has been Installed along a popular NorthWest beach. A179 wirelessnetwork of sensor devIces collocated with thesirens controls theiractivation. When triggered,180 each sensor generates a CAP message containing its location andthesensed data at that locatlon that is181 needed for the tsunami determination. Eachsiren activates when the combination of its own readings and182 thosereported at byotherdevices on the network indicate anImmediate teunarnl threat. Inaddltion, a183 network component assembles a summary CAPmessage describing theevent and feeds it to regional184 and national alerting networks."
185 &;.~,3 Ag~u'~gBl'ldon o:ulld CO~Tsl;''ij;loru on Re~iu'lime M~p
186 "At the StateOperations Center a computerized map of thestate depicts, in realtime, all current and187 recent warning activity throughout the state. All major warning systems in thestate - the Emergency188 Alert System, siren systems, telephone alerting and other syetems -« haVe been equipped to report the189 detailsof theiractivation in theform of a CAPmessage. (Since many of them arenow activated byway190 of CAP messages, this is frequently just a matter of forwarding the activation message to thestate191 center.)192 "Using this visualization tool,state officials can monitor foremerging patterns of local warning activity and193 correlate It withotherreal timedata{e.g., telephone central office traffic loads, 9-101 traffic volume,194 seismic data, automatic vehicular crashnotifications, etc),"
195 ~.3,4 1i1i:\S@i'&~~d P,"!bil~ f.\iGw~iu·i~
196 •As partof an Integrated warning system funded bylocal industry, all warning systems Ina community197 can beactlvated simultaneously by the issuance byauthorized authority of a single CAP message.
CAP-V1.1Copyrlght@ OASISOpen 2005. AllRights Reserved.
1 October 2005Page 8 of 35
WIT.039.001.0059
198 "Eachsystem converts the CAP message dataintothe form suitable for its technology (text captioning on199 TV, synthesized volceon radio andtelephone, activation of the appropriate signal onsirens, etc.).200 Systems thatcan targettheir messages to particular geographIc areas -Implement the targeting specified201 in the CAPmessage with as little 'spill' as theirtechnology permits.202 "In this way, notonlyIs the reliability and reach of theoverall warning system maximized, butcitizens also203 get corroboratlon of the atertthrough multiple channels, which increases thechance of thewarning being204 actedupon."
205 ~t3,~ Repu~cli~v.nffil~ 8l FI~~r.e AiE:HT~\
206 "Inadvertently the integrated alerting network hasbeen activated with anInaccurate warning messaqe,207 This activation comes to officials' attention immediately through theirown monitoring facilities (e.g., 2.3.3208 above). HavIng determined that the alert is, in fact, Inappropriate, the officials Issue a cancellation209 message thatrefers directly to the erroneous prior alert. Alerting systems thatarestili in theprocess of210 delivering thealert(e.g., telephone dialing systems) stop doing so. Broadcaslsystemsdellverthe211 cancellation message. Other systems (e.g., highway signs) simply reset totheirnormal state."
CAP·V1.1COpyright e OASI S Open 2005, All Rights Reserved.
1 October2005Page9 of 36
WIT.039.001.0060
alertMessage 10 (identifil\!r)Sender ID (sender)Sellt Date/Time (sent) Elell1ents Inboldface are
Message status (status) mandatory; elements in italics
Message Type (msgType)have default values thatwillbeassumed If the element Is not
source (source) present: asterisks n Indicatescope (scope) that multiple Instances areRestriction (restrictlon) permitted,
Addl'esses (addresses)Handling Code (code) ..Note (note)Reference IDs(references)Incident IDs (Incidents)
4
*info resourceLal1guag~ (language) Descril)tiollEvent Category (category) * (rescurcepesc)
Evel1t Type(event) * MIME Type (mhneTyI>e)
Response Type(response'lype) ..IV
File Size (size)
Ul'gency(urgency) URI (uri)
Severity (severity) Dereferencecl URI (del'efUI'I)
Certainty (certainty)' Digest (digest)
Audlence (audience)Event Code (eventCode)"Effeotlve DatelTlme (effective) areaOnsetDatelTime (onset) Area DescriptionExpiration Datemme (expires) (areaDesc)
Sender Name (sencierName) * Area Polygon (polygon) .,
Headline (headline) Area Circle (circle) ..
Event Description (description) Area Geooode (geooocte)"
lnstructlone (Instruction) Altkucle (altitude)
Information URL (web) Ceiling (ceiling)
Contact Info(contact)Parameter (parameter) •
214
CAP-V1.1Copyright@ OASISOpen2005. All Rights Reserved.
1 October 2005Page 10of 35
WIT.039.001.0061
215 ~D~ [Q)£l~~ gn@~8@U1~rfY'
216 Note: Unless explicitly constrained within this Data Dictionary or theXML Schema217 (Section 3.4), CAPelements MAY have null values, 'Implementers MUST check for this218 condition wherever It mightaffectapplication performance.
219
Element Context Class. Definitionand Notes or ValueDomainName Attribute; (Optlonality)
Representation
~,~/U "~i0~"1:" t~!ern~n~: 5lR1d §tlb>"e!8~ti~(S1ir1:$1)
alert cap. The container (1) Surrounds CAP alert message sub-alert. for all elements
component (2) MUST Include thexmlns attributegroup
parts of the referencing theCAP URN asthealert message namespace, e.g.:(REQUIRED) <cap ,alert
xmlna: cap""urn I oasis I names, tc: emergency:capI1.1 n,.
(sub-elements)</oap:alerb
(3) In addition to the specified sub-elements, MAY contain one or more<Info> blocks.
Identifier caP· Theidentifier (1) A number orstring uniquely identifyingalert. oHlle alert thismessage, assigned bythe sender
message (2) MUST NOT Include spaces, commas or
identifier(REQUIRED) restricted characters « and &)
sender cap. Theidentlfier (1) Identifies theoriginator of this alert.
alert. of the sender Guaranteed byassigner to be unique
sender.of the alert globally; e.g., may be based onanmessage Internet domain name
Identifier (REQUIRED) (2) MUST NOT Include spaces, commas orrestricted characters « and&)
sent cap. Thet/meand (1) Thedate and time Is represented inalert. dateof the [dateTime] format (e. g.,"2002- 05-
sel1t.origination of 24T16: 49: 00-07: 00" for24 May 2002 atthe alert 16: 49 PDn.
time message (2) Alphabetic llmezone designators such(REQUIRED) as"Z" MUST NOT be used. ThetimezoneforUTe MUST berepresented as "·00:00"or "+00:00.
CAPN1.1Copyright © OASIS Open 2005, All Rights Reserved,
1 October 2005Page11of35
WIT.039.001.0062
Elemei'lt Content. Clas$. Definition and Notes or Value DomainName Attribute. (Optlonality)
Representation
status cap. The code Code Values:
alert. denoting the "Actual" - Actionable by all targeted
status.appropriate recipientshandling of
code the alert "Exercise"· ActIonable only by designatedmessage exercise participants; exercise identifier(REQUIRED) should appear In <note>
"System" • For messages that supportalertnetwork Internal functions.
"Test"· Technical testing only, allrecipients disregard"Draft" - A preliminary template or draft,not actionable in Itscurrentform.
msgType cap. The code Code Values:
alert. denoting the "Alert" • Initial Information rsqutrlnqnature of the attention by targeted reclplentstype. alert message
code (REQUIRED) "Update" - Updates andsupercedes theearliermessage(s) identified in<references>"Cancel" • Cancels the earliermessage(s)Identified In <references>"Ack" • Acknowledges receipt andacceptance of the message(s» identifiedin <references>"Error" indicates rejection of themessage(s) Identified in <references>;explanation SHOULD appear in <note>
source cap. Thetext Theparticular source of this alert:e.g.,an
alert. identifying the operator or a specific deVice.sourceof the
source. alert messageidentifier (OPTIONAL)
scope cap. The code Code Values:
alert. denoting the "Publip" • Forgeneral dissemination tointended unrestricted audiencesscope. distribution of
code the alert "Restricted" • For dissemination only tomessage users witha known operational(REQUIRED) requirement (see<restriction>, below)
"Private" • Fordlssemlnatlon only tospecified addresses (see<address>,below)
CAp·V1.1Copyright © OASIS Open2006. All Righte Reserved.
1October 2005Page12of 35
WIT.039.001.0063
Element Context. Class. Definition and Notes 01' ValueDomainName Attribute. (Optlonallty)
Representation
restriction cap. Thetext Used when<scope> value is "Restricted"alert. describing the
restriction.rulefor limitingdistribution of
text the restrictedalertmessage(conditional)
addresses cap. Thegroup (1) Used when <scope> valua is "Private"alert. listing of (2) Each recipient SHALL beidentified by
Intendedaddresses. recipients of
an identifier or anaddress
group theprivate alert (3) Multiple space-delimited addressesmessage MAY be Included, Addresses Including(conditional) whltespace MUST beenclosed in
double-quotes.
code cap. Thecode (1) Any user-defined flag orspecial codealert. denoting the used to flagthe alert message for
special special handling.code handling ofthe (2) Multiple Instances MAY occur within a
alertmessage single <Info> block.(OPTIONAL)
note cap, Thetext Themessage note Isprimarily Intended foralert. describing the usewith Cancel and Error alert message
note.purpose or types.significance of
text the alertmessage(OPTIONAL)
references cap. Thegroup (1) Theextended message identifler(s) (inalert. listing the formsender, Identifier, sent) of an
references.identifying earlierCAP message ormessagesearlier referenced bythis one,
group message(s) (2) If multiple messages are referenced,referenced by theySHALL beseparated bythe alert whitespace.message(OPTIONAL)
CAP-V1.1Copyright © OASiS Open 2006. All Rights Reserved.
1 October 2005Page 130f35
WIT.039.001.0064
Element Context. Class. Definition and Notes or Value DomainName Attribute. (Optionality)
Representation
incidents cap. Thegroup (1 ) Used to collate multlple messagesalert. listing naming referring to different aspectsof the
Incidents.thereferent same incidentincident(s) of (2) If mUltiple Incident Identifiers are
group thealert referenced, they SHALLbe separatedmessage bywhltespace. Incident names(OPTIONAL) including whltespace SHALLbe
surrounded by double-quotes
~"~"~ "nutii\/u EU€ih-dl@ur2 ~;iU-lil~ f~QtiLHtJi®u'iiiltBr{~;:s
info cap. Thecontainer (1) Multiple occurrences are permittedalertlnfo. for all within a single <alert>. If targeting of
info.component multiple "info" blocks in the sameparts of the info language overlaps, information In later
group sub-element of blocks may expand but maynotthealert override thecorresponding values Inmessage earlierones. Each set of "info"blocks(OPTIONAL) contaIning the same language Identifier
SHALL betreated as a separatesequence.
(2) Inaddition to the specified sub-elements, MAY contain one or more<resource> blocks and/or oneor more<area> blocks.
language cap. Thecode (1) Code Values: Nalurallanguagealertlnfo. denoting the identifler per[RFC 3066].
language.language of the (2) If notpresent, anImplicitdefault valueinfosub- of lien-US" SHALL be assumed.
code element of thealertmessage (3) A nullvalue in thiselementSHALL be(OPTIONAL) considered equivalent to "en-US."
CAP-V1.1Copyright C> OASIS Open2005. All Rights Reserved.
1 October 2005Page 14 of35
WIT.039.001.0065
Element Context. Class. DefinitIon and Note!! Oi' Value DomainName Attribute. (Optlonality)
Representation
category cap. The code (1) CodeValues:alertlnfo. denoting the "Geo" - Geophysical (Inc. landslide)
category ofcategory. the subject "Met"- Meteorological (inc. flood)
code event of the "Safety" • General emergency andpubllcalert menage safety(REQUIRED) "Securtty" - Lawenforcement, military,
homeland and local/private security
"Rescue" - Rescue and recovery"Fire" " Firesuppression and rescue
"Health" - Medical and public health"Env" • Pollution and otherenvironmental
"Transport" - Publicand privatetransportation
"Infra"· Utility, telecommunication, othernon-transport infrastructure
"CBRNE" - Chemical, Biological,RadiologIcal, Nuclear or High-YieldExplOsive threator attack"other" • Otherevents
(2) Multipleinstances MAY occurwithin asingle<info> block.
evel1lt cap. The text
alertlnfo. denoting the
event.type of theSUbject event
text of the alertmessage(REQUIRED)
CAp·V1.1 .Copyrlght@ OASISOpen 2005. All Rights Reserved.
1October2005Page 15 of 35
WIT.039.001.0066
'\
"'. 'j -.
EIGmGn~ Conteltl. Claise. Definition and Notes or Value DomainName Attribute. (Optionallty)
Representation
responseType cap, The code (1) Code Values:alel1lnfo, denoting the "Shelter' - Take shelter Inplace or perresponseType.
typeof action <instruction>recommended
code for the target "Evacuate" - Relocate as Instructed in theaudience. <Instruction>(OPTIONAL) "Prepare" - Make preparations per the
<instruction>"Execute" - Execute a pre-planned activityidentified in <Instruction>"Monitor" - Attend toInformation sourcesas described In<Instruction>"Assess" - Evaluate the Information in thismessage. (This value SHOULD NOTbeusedin public warning applications.)"None" - Noaction recommended
(2) Multiple instances MAY occurwithinasingle<Info> block.
urgency cap. The code (1)The"urgency" I "severity", and "certainty"alertlnfo. denoting the elements collectively distinguish less
urgency.urgency of the emphatic from more emphatic messages,subject event (2) Code Values:
code of the alert"Immediate" - Responsive actionmessage
(REQUIRED) SHOULD betaken Immediately"Expected" ~ ResponsIve action SHOULDbe taken soon (within nexthour)"F.uture" - Responsive action SHOULD betaken In thenear future"Past" - Responsive action Is no longerrequired"Unknown" - Urgency notknown
CAP-Y1.1Copyright© OASISOpen2005, All Rights Reserved,
1 October2005Page 16of 36
WIT.039.001.0067
Element Context. Class. Definition and Notes or Value DomainName Attribute. (Optlonallty)
Representation
severity cap. The code (1) The "urgency", "severity" I and "certainty"alertlnfo. denoting the elements collectively dl&tlngulsh less
severity.severity of the emphatIc from more emphatic messages.subject event (2)Code Values:
code ofthe alertmessage "Extreme" • Extraordinary threat to life or(REQUIRED) property
"Severe" • Significant threat to lifeorproperty"Moderate" - Possible threat to lifeorproperty"Minor" • Minimal threat to lifeor property·Unknown" • Severity unknown
certainty cap. The code (1) The "urgency', "severity", and "certainty"alertlnfo. denoting the elements collectively distinguish less
certainty.certainty of emphatic from more emphatic messages.the subject (2) Code Values:
code event of theatert message "Observed" - Determined to have(REQUIRED) occurred or to be ongoing.
"Likely" • Likely (p >-50%)"Possible" - Possible butnotlikely (p <=-50%)"Unlikely" - Not expected to occur (p - 0)"Unknown" - Certainty unknown
(3) Forbackward compatibility with CAP1,0, thedeprecated value of "Very Likely"SHOULD betreated asequivalent to"Likely."
audience cap. Thetextalertlnfo. describing the
Intended.audience. audience of thetext alertmessage
(OPTIONAL)
CAP·V1.1Copyright© OASISOpen 2005. All Rights Reserved.
1 October2005Page 17of 35
WIT.039.001.0068
Elament Context. Class. Definition and Notes 01' Value DomainNama Attribute. (Optianallty)
Representi'iioi"l
eventCode cap. A system- (1) Any system-specific codefor eventalertlnfo. specific code typing, in the form:
event.identifying the <eventCode>eventtype of
code the alert<valUeName>valueName</valueName>
message <value>value</value>
(OPTIONAL) </eventcode>
wherethe content of "valueName" Is a user-assignedstring designating the domainofthe code, and thecontent of "value" is astring (which may represent a number)denoting the value itself(e.g., valueName="SAME" andvalue="cEM" ) .
(2) Valuesof "valueName" that areacronyms SHOULD berepresented In allcapital letterswithout periods (e.g.,SAME,FIPS,ZIP).(3) MultipleInstances MAYoccur Within asingle<Info> block.
effective cap. Theeffective (1) The dateandtime is represented in
alertlnfo. timeoftha [dateTlme] format (e. g., "2002-05-
effective.Information of 24T16: 49 :00-o7:00"for 24 May 2002 atthe alert 16: 49 PDT).
time message (2) Alphabetic tlmezone designators such(OPTIONAL) as liZ"MUSTNOT beused. The timezonefor UTC MUST be represented as "-00:00"or "+00:00.
(3) if this Item is not included, the effectivetime SHALL be assumed to be the sameasIn <sent>.
onset cap. Theexpected (1) The dateand time 1s represented In
alertlnfo. timeof the [dateTlme] format (e. g., "2002- 05-
onset.beginning of 24Tl6: 49: 00-07: 00"for 24 May2002 atthe SUbject 16:49 PDT).
time event of the (2) Alphabetic timezone designators suchalertmessage as "Z" MUSTNOT beused. The timezone(OPTIONAL) for UTe MUST be represented as "-00:00"or "+00:00.
CAP·V1.1Copyright © OASIS open 2005. All Rights Reserved.
1 October 2006Page 18 of36
WIT.039.001.0069
Element Context, Class. Definition and Notes or ValueDomainName Attribute. (Optlonallty)
Representation
expires cap. The expiry time (1)ThedateandtimeIs represented inalertlnfo. of the [dateTime]format (e. g., "2002-05-
expires.information of 24T16: 49: 00-07: 00" for 24 May 2002 atthe alert 16:49 PDT).
time message (2)Alphabetic tlmezone designators such(OPTIONAL) asoZ' MUST NOT beused. The timez.onefor UTe MUST be represented as "·00:00' .or "+00:00.(3) If thisItem Isnot provided, eachrecipient Isfreeto setItsownpolicy as towhen themessage is no longer in effect.
senderName cap. The text The human-readable name of theagency oralertlnfo. naming the authority Issuing this alert.
sander.originator ofthealert message
name (OPTIONAL)
headline cap. The text A briefhuman-readable headline. Note that
alertlnfo. headline ofthe some displays (forexample, short
headline.alert message messaging service devices) may only(OPTIONAL) present thisheadline; It SHOULD bemade
text asdirect and actionable aspossible whileremaining short, 160characters MAY beauseful target limitfor headline length.
description cap. The text Anextended human readable description of
alertlnfo. describing the thehazard oreventthat occasioned this
description.eubject event message.ofthe alert
text message(OPTIONAL)
instruction cap. The text Anextended human readable Instruction toalertlnfo. describing the targeted recipients. (If different instructions
recommended areintended for different recipients, theyinstruction. actionto be should be represented by useofmultipletext taken by <Info> blocks.)
recipients ofthe alertmessage(OPTIONAL)
CAP-V1.1Copyright © OASISOpen2005. All Rights Reserved.
1October2006Page19 of 36
WIT.039.001.0070
IElem\\;nt Context. Class. Definition and Notes Of Vaiue DomainName Attribute. (Optionality)
Representation
web cap The identifier of A full, absoluteURIforan HTML page oralertlnfo. the hyperllnk othertext resource with additional or
Information.associating reference information regarding this alertadditional
Identifier informationwiththealertmessage(OPTIONAL)
contact cap. Thetextalertlnfo. describing the
contact forcontact, follow-up andtext confirmation of
the alertmessage(OPTIONAL)
parameter cap. A system- (1)Any system-specific datum, in the form:alertlnfo. specific <parameter:>
parameter.additional <valueName:>valueName< !valueName:>parameter
group associated with <value:>value<!value>
the alert <!parameter:>message wherethe contentof"valueName" Is a(OPTIONAL) user-asslqned string designating the
domain of the code, and thecontent of"value" Is a string (Which may represent anumber) denoting the value Itself(e.g.,valueName .,"SAME" and value="clv".)
(2)Valuesof lvalueName" thatareacronyms SHOULD berepresented In allcapital letterswithout periods (e.g., SAME,FIPS, ZIP),(3)Multiple instances MAY occurwithinasingle <info> block.
CAP-V1.1Copyright© OASIS Open 2005. All Rights Reserved.
1 October2005Page 20of 35
WIT.039.001.0071
Element Context. Class. Definition and Notes or Value DomainName Attribute. (Optlonallty)
Representation
~,~,3 oOf®~©\L.!i"C~H IEla~"i(1i~:rit ~b"i@ Suboo@lem®i'u~$
resource oap Theoontainer (1)Refers to an additional file with
alertlnfoResource. for all supplemental information related to thisoomponent <info> element; e.g.,an Image or audio file
resource. partsof the (2)MUltiple ocourrences MAYoccur within agroup resource sub- single <info> block
element of theinfo sub-element of thealertelement(OPTIONAL)
resourceDesc cap. The text Thehuman-readable text describing thealertlnfoResource. describing the content andkind, suchas "map" or "photo,"
type and of the resource file.resourceDesc. content of thetext resource file
(REQUIRED)
mlmeType cap. The Identifier of MIME content type andSUb-type asa1ertlnfoResource. theMIME described In [RFC2046]. (Asof this
mimeType.content type document, thecurrentlANA registeredand SUb-type MIME types are listedat
identifier describing the http://wwW.lana.org/assignmentsJmedla-resource file types/)(OPTIONAL)
size cap. The integer ApproXimate sizeof the resource file in
alertlnfoResource. indicating the bytes.sizeof the
size. resource fileinteger (OPTIONAL)
uri cap. The identifier of A full absolute URI, typically a UniformalertlnfoResource. the hyperlink Resource Locator that can be used to .
for the retrieve the resource over the Interneturi. resource file ORidentifier (OPTIONAL)
a relative URI to name the content ofa<derefUri> element if one is present In thisresource block.
CAP·Vl.1Copyright @ OASISOpen2005, All Rights Ressrved.
1October 2005Psge 21 of35
WIT.039.001.0072
Elameri'1: Context. ClaGOl. Definition and Notes ci'Value DomainName Attribute. (Optionality)
Representation
derefUrl cap The base-64 (1)MAYbe used either with or insteadofalertlnfoResource. encoded data the <uri> element in messages transmitted
derefUri.contentofthe overone-way (e.g., broadcast) datalinksresource file where retrieval of a resource via a URI is
data (CONDITIONAL) not feasible.(2)Clients Intended forusewith one-waydatalinks~UST support this element.(3)Thiselement MUST NOTbe usedunless the senderis certain that all directclients are capable ofprocessing it.
(4) If messages including this element areforwarded onto a Wlo-way network, theforwarder MUST strip the<derefUri>element and SHOULD extract the filecontents and provide a <uri> link to aretrievable version ofthe file.(5)Providers of one-way data linksMAYenforce additional restrIctions on the useofthiselement, including message-size limitsand restrictions regarding file types.
digest cap. The code Calculated usingtheSecure HashalertlnfoResource. representing Algorithm (SHA-1) per [FIPS 180-2]
digest.the digitaldigest ('hash")
code computed fromthe resourcefile(OPTIONAL)
~,~,<Q. ".~)lu,(:~ffi" l:k~IJ~(·m'i: 8,mJ t';Ub"8~Ii~u~,:&Ht;'J
area cap. The container (1) Multiple occurrences permitted, InwhichalertlnfoArea. forall case the targetarea forthe <Info> blockis
component the union of all the Included <area> blocks.area. parts of the (2) MAY contain oneormultiple Instancesgroup area sub- of <polygon> I <circle> or<geocode>. If
element of the multiple <polygon>, <circle> or <geocode>info sub- elements are Included, theareadescribedelement ofthe by this<area> is theunion of thesealert message represented by the lncluded elements.(OPTIONAL)
CAP·V1.1Copyright© OASIS Open 2005. All Rights Reserved.
1 October2005Page 22 erss
WIT.039.001.0073
element Context. Class, Definition and Notes or Value DomainName Attribute. (Optionality)
Representation
areaDesc cap. The text A text description of theaffectedarea.
alertlnfoArea. describing theaffected area
area. of the alerttext message
(REQUIRED)
polygon cap, Thepaired (1) Code Values: Thegeographic polygon is
alertlnfoArea. values of points represented by a whitespace-delimited list
polygon.defining a of [WGS 84] coordinate pairs. (SeeWGS-polygon that 84 Noteat endof thissection.)
group delineates the (2)Thefirst andlast pairs of coordinatesaffected area of MUST be the same.thealert
(3) SeeCoordInate Precision Noteatendofmessage(OPTIONAL) thissection.
(4)MUltiple Instances MAYoccur within an<area>.
circle cap. Thepaired (1)Code Values: ThecircularareaIsalertlnfoArea, values of a represented by a central point given as a
circle.pointand [WGS·84] coordinates pair followed by aradius space character andaradiusvalueIn
group delineating the kilometers. (See WG$-84 Note at end ofaffected area of thissection.)thealert (2)SeeCoordinate Precision Noteat end ofmessage thissactlon.(OPTIONAL)
(3)MUltiple Instances MAYoccurwithin an<area>.
CAP-V1.1Copyright@ OASISOpen2006. All RightsReserved.
1 October2005Page 23of35
WIT.039.001.0074
Ellitmeil~ Context Class. Definition and Notes or Value Domai~
Name Attribute. (Optionality)Representation
gaocode cap. The geographic (1)Anygeographically-based code toalertlnfoArea. code describe message target area:
geocade.delineating the <parameter>affectedarea of
code the alert <valuaName >va1 ueName<!valueName>
message <value>va 1ue<!value>
(OPTIONAL) </parameter>
where the content of "valueName" Isa user-assigned string designating thedomain ofthecode, and the content of "value" is astring (which may represent anumber)denoting thevalue itself(e.g., valueName""!SAME" andvalue:::"oo6113").
(2)Values of"valueName" thatareacronyms SHOULD berepresented In allcapital letters withoutperiods (e.g., SAME,FIPS, ZIP).(3) Multiple instances MAY occur withinasingle <info> block.(4) This element Is primarily forcompatibilitywith othersystems. Use ()fthis elementpresumes knowledge of thecoding systemonthe partof recipients; therefore, forinteroperability, It SHOULD be used Inconcert withan equivalent description In themore universally understood <polygon> and<circle> forms whenever possible.
altitude cap. The specific or (1) If used with the <ceiling> element thIsalertlnfoArea. minimum value is the lowerlimitof a range.
altitude.altitude of the Otherwise, thisvaluespecifies a specificaffected area of altitude.
quantity the alert (2)The altitude measure is in feetabovemessage mean sealevel per the[WGS. 84] datum.(OPTIONAL)
ceiling cap. The maximum (1) MUST NOT be used except InalertlnfoArea. altitude of the combination with the <altitude> element
affected area of (2) The ceiling measure IsIn feet aboveceiling. the alertquantity message
mean sealevel per the(WGS· 84] datum.
(conditional)
CAP·V1.1Copyright © OASISOpen2005. All Rights Reserved.
1 October2005Page24of 35
WIT.039.001.0075
220
221
222223224225
226
227228229230231232233234235
236
237238239240241242243244245
246
247248249250
3,3. 11 WGS~84 Not~
Geographic locations in CAP are defined using [WGS 84] (World Geodetic System 1984), equivalent toEPSG (European PetroleumSurvey Group) code 4326 (2 dimensions). CAP does not assignresponsibilities for coordinatetransformations from and to other Spatial Reference Systems. See section1.5 Terminology for the format of coordinate pairs within CAPelements.
3.3.2 Security No~e
BeCE,use CAP is anXML-baaad format, existing XML security mechanisms canbeusedto secureandauthenticate its content. V\lhile these mechanisms areavailable to secure CAP Alert Messages, theyshouldnotbe used Indlsorlmlnately.Note thatthis section adds two tags to CAPby referenoe. These are: "Signature and "EncryptedData".Both elements arechildrenof the <alert> element and are optional. If tl1e "EncryptedData" elementexists, no other elements will be visibleuntilafterthe mesaage Is dectYpled. ThIs makes the minimalCAP message analertelement which encloses an EncryptedData element. Themaximal CAP message,if an EnoryptedData element is present is an <alert> element enclosing asingle EncryptedData elementand a single Signature element.
3.3.:U DigitalSignaiures
The alertelement of a CAP Alert Message MAYhave an Enveloped Signature, asdescribed by XML·Signature andSyntax Processing [XMLSIG]. Other XMLsignature mechanisms MUST NOT be used inCAP Alert Mesl3ages.Processors MUST NOT reject a CAPAlert Message containIng such a sIgnature simply because theyarenot capable ofverifying it; they MUSTcontinue processing and MAY Inform theuser of their failuretovalidate thesignature.In otherwords, the presenceof an element withthe namespace URI [XMLSIG] and a localnameof·Signature" asa child of the alert element mustnot cause a processor to fallmerely because of itspresence.
3.3.2.2 EncryptioilThe alertelement of a CAP Alert Message MAY be encrypted, using themechanisms described by XMLEncryption Syntax and ProcessingIXMLENC]. Other XML encryption mechanisms MUST NOTbe usedin CAPAlertMessages; however, transport-layer enoryptlon mechanisms may beused Independently ofthis requirement.
<?xrnl version .. "1.0" encoding .. "UTF-8"?><schema xmlns " ''http://www.w3.org/2001/XMLSchema''
targetNamespace = "urn: eas is lOam!!lS Jtc: emergency: cap, 1.1"XI\11ns Jcap .. "urn: oasis Jnames J tc: smergency: cap: 1.1"xmlrts, xe .. "httpJ //www.w3 •org/2001/XMLschema"elerrtentFormDefault .. "qualified"attributeFor:mPefault = "unqualified">
<element name .. "alert"><annotation>
<dodumentation>CAP Alert Message (version 1.1)</documentation></annotation><complex'rype>
<sequence><element; name" "identifier" type" "string"/><element name .. "sender" type .. "string"/><element name .. "eent" type .. "dateTime"/><element name .. "status">
<simpleType><restriction base .. "string" >
<enumeration value .. "Actua1"1>
CAP-V1.1Copyright@OASIS Open 2005. All Rights Reserved.
1 October2005Page25of35
WIT.039.001.0076
"unbounded">
.. "unbounded" / >
"Exercise" I,"System"/>"Test"!>"Draft"l>
veluevaluevaluevalue e
"restriotion" type 0 "string" minoocurs " "0"1>"addreaSf;ls" type = "string" minoccurs • "0"/>"code" type = "string" minocours " "0" maxOccurs"note" tYl?f;I .. "string" minoccurs u "0"1>"references" type w "string" minOccurs " "0"1>"incidents" type "I'tring" minOcours e "0"1>"info" minoccurs = "0" ma,x,Oocurs ~ "Unbounded">
<enumeration<enumeration<enumeration<enumeration
</restriction><!simpleT¥1'e>
</element><elemf;lnt name. "msgType">
<simpleType><restriction base .. "lOtrin9">
<enumeration value "Alert"l><enumeration value ~ "update"l><enumeration value "Cancel"l>"enumeration valuf;l "Ack"!><f;lnumeration value ~ "Error"!,
"/rf;l5tr10tion></simpleType>
"/f;llement><element name II:l lIsourcell type r=l- '!string " minOccurs • l!OIl/><element name .. "soope">
<simpleType><;restrlction base .. "string">
<enumf;lration value .. "public"l><enumeration value "Restricted"l><enumerat1on value. "private"l>
</rel'triction></l'imple'I'ype>
</element><element name<element name ..<element name<element name ..<elemf;lnt name '"<elemf;lnt nams ..<element name "
<complexType><sequf;lnce>
"element name .. "language" type .. "lenguagf;l" daf auLt; .. "en-US" minOcou~'B • "O"!,<element name .. "oategory" rnaxOccurs .. "unbounded">
<simple'l'ype><reatdction base .. "string'>
<enumeration value .. "Geo-I><enumeration value ~ "Met'l>"enumeration value e "Safety"!><enumeration valuf;l ~ "Security"/><enumeration value e "Rescue"!"<enumf;lration value e "Fire"l><enumeration value e "Health"I'"<enumeration value s "gnv'l><"numeration value "Transport'!><enumeration value .. "Infra"l><enumeration value ~ "CBRNE"/><enUmera.tion value e "other"l>
<h:estrioUon></simpleType>
</element><element name" "event" type ='string"l><element name = "reeponseType" minOocurs .. "0" maxOccurs
<eimpleType><restriotion base e "string">
<enumeration value .. "Shelter"I,<enUmeration va'Lue .. "Evacuate" I>"enumeration value ~ "Prepare"!><enumeration value "Execute"!'<f;lnumeration value "Monitor"!'"enumeration value ~ "None"l>
</restriotion'</simple'I'ype,
<I element><element name .. ·urgency">
<simpleType><restriction base· "string">
<enumeration valuf;I "Immediate"l>..enumeration value .. "Expected"l>"enumeration value. "Future"l><enumeration value "Past"l><enumex-ation value a "Unknown"!>
<!restriction><laimpleType>
"/element><element name" "severity">
<sirnple'type>
CAp·V1.1Copyrlght © OASISOpen2006. All Rights Reserved.
1 October 2006Page 26of 36
WIT.039.001.0077
"0"1,.
"0" maxOccurs .. "unbounded">
"resouroeDesc" type = "string"l>.. "mimeType" type" "string" minOccurs = "0" I>
"ei~e" type'" "integer" minOocurs = "0'1>.. "uri" type e "anyURI" minOccurs '" "0"1>
"derefUri" type = "string" minOccurs .. "0"1>" "digest" type = "string" minOccurs '" "0"1>
"effective" type" "dateTime" form .. "qualified" minOocurs"onset" type" "dsteTime" minOccurs = "0"1>"expires" type. "dateTime" minOccurs " "0"1,."senderName" type'" "string" minocours .. "0"1>"headline" type .. "string" minOccurs " "0"1>"description" type" "string" minOocurs " "0"1>"instructiori" type" "string" minoccurs = "0"1>"web" type = "anyORI" minOccurs = "0"1>"oontact" type " •string" minoccurs " "0" I>"parameter" minOcoure " "0" maxOccurs = "unbounded",.
~~restriction base" "string">~enumeration value .. "Extreme"l>~enumeration value ~ "Severe" I>~enumeration value "Moderate" I""enumeration value .. "Minor"l><enumeration value "Unknown"I"
~/rest:t'iction>
"/i.impleType,,~/element>~element name .. "certainty';>
"simp1eType>~re.. triction base", "string">
"enumeration value .. "Observed" I>~enume):ation value "Liltely" I><enumeration value "Possible"l>':enumera.tion value "Unlikely"l><enumeration value" "Unknown"l>
"/l:estriction>~/simpleType>
~/element><element name .. "audience" type" "string" minOccurs .. "0"1><element name .. "eventCode" minOccure .. "0" maxoccuxs " "unbounded">
"compleXType>"sequence,.
<element ref .. "cap,valueName"l>"element ref "cap,value"l>
</sequence><:/complexType>
</element>"element name<element name '""element name<element name ""element name<element name ..<element nB.l1le ..~element name ..~element name ..<element name ..
"complexType>"sequence>
"element l:'ef "cap,valueName"/"<element ref .. "cap,value"l>
"/eequence></complexTypa>
"/elemepl:>~element name .. "resource" minOocurs '" "0" maxOccurs " "unbounded">
"complexType~
~sequence>
"element name<element name<element name<element name<element name<element name
~/sequence>
"/complexType>~/element>"element name" "area" minOccurs
<complex'l'ype><sequence>
"element name "areaOesc" type" "string"l>"element name" "polygon" type" "string" minOcours '" "0" maxocouz-a " "unbounded"l><element name" "circle" type", "string" minOcours " "0" maxoccurs '" "unbounded" />"element name" "gaocade" minOccurs = "0" maxoccurs .. "unbounded">
"complexType"<sequence>
. "element ref" "cap,valueName"l>"element ref "cap,value"l>
"/aequenoe><:/complexType>
"/element>"element name '" "altitude" type = "string" minOcours " "0" I>~elemant name" "ceiling" type = "atring" minOccurs " "0"1>
</sequence></oomplexType>
</element></sequence>
</complexType><:Ielemen!:>
</sequence>"/camplexType>
CAP·V1.1Copyrighte OASIS Open 2005. All Rights Reserved.
1 Ootober2005Page 27 0135
WIT.039.001.0078
",jelement>",element name",element name
</schema>
"valueName" type D "string"/>"value" type e "string" />
CAP-V1,1Copyright © OASISOpen 2005. All Rights Reserved.
1 October2005Page 280135
WIT.039.001.0079
442
The following Isa speculative example in the form of a CAP XML message.
443
444
( .
< I tl C.I
<?xml version c "1,0" encoding ~ "UTF-B"?<alert xmlns = "\1Ill:oBlliSlnames:tc,emergencYlcap:l.l".
<identifier.43bOB07l3727<!identifier><sender>heesedhs.gov<!sender.<sent>2003-04.02T14,j9101-05:00<!sent.<status.Actual<!status><rnsgTyps>Alert<!msgType.<scope>Public<!ecops.<info>
<Category>Security</category><event>Homeland Seourity Advisory System Update<!event.<urgenoy>Irnmediats<!urgenoy.<severity>severs<!severity.<certainty.tikely<!certainty><sende~ame>U.S. Government, Department of Homeland Security</eenderNams.<beadline.Homslartd Security Bate Code ORANGE</headline><description.The Department of Homeland Security hee eleveted the Homeland Security Advisory
System threat level to ORANGE / High in response to intelligence which may indicate a heightenedthreat of terroriam.<!description>
<instruction> A High Condition is deoleu:ed when there is a high dslt of terrorist attacks , Inadditiort to the Proteotive Meaaures taken in the pre.·vioua Threat Conditions, Fe.deral departmentsand agertoies should oonsider agency-specifio Proteotive Measures in accordanoe with theirexieting.plans.</instxuction>
<web>http://www.dhs.gov/dhspublic/display?theme~29</web.
<par;l.meter><valueName>Ha~</valueName><value>ORANGE<!value>
</pal;ameter><resource.
<tesourceDeso>Image file (GIF)</resourceDesc><oxi.http,!!www.dhs.gov!dhspublic!getAdvisorylrnage<!uri>
</resource•<area>
<areaDeso>U.S. nationwide and interests worldwide</areaDesc.</area>
</info><!alert>
CAP·V1.1Copyrighl@ OASIS0PllO 2005. All Rights Reserved.
1 October 2005Page29 of36
WIT.039.001.0080
484
485
t o~ 0 r ~'\f®n'® i hlL%'U©®~'~'IIr"l)'~u'U (§llJ'rrufIi1L'
The following is a speculativeexample in the formof a CAPXML message.
<?xml version " "1. 0" encoding c "U'l'F-8"? ><alert xmlns c "urn:oasis,names,tc,Bmergency,cap,l.l">
<identifier>KST01055887203</identifier><sendar>[email protected]<laender><sent>2003-06-17T14,57,OO-07,Oo</sent><status>Actual</status><msgT~a>Alert</msgType><scope>Publio</scope>dnfo>
<category>Met</category>cevent>SEVERE ~EONDKRSTORM</event><responeeTypB>shelter</responsBType><urgency> Imrnediate</urgency><severity>8evere</savarity>ccertainty>Observed</certainty><eventCode><valu~ame>Bame</valueName><value>SVR</value>
</eventCode><expires>2003-06-17T16,OO,OO-07:00</expires><sBnqerName>NATIONAL WEATHER SERV1CE SACRAMENTO CA</eenderNeme><headline>SnVERE THUNOERSTORM WARNING</headline><description> AT 254 PM PDT .•. NATIONAL WEATHER SBRVICE DOPP~ER ~AR Ih~ICATED A SEVERE
THUNDERSTORM OVER SOUTH CENTRAL ALPINE COUNTY •.• OR ABOUT 18 MILES SOUTHEAST OF KIRKWOOD ... HOVINGSOUTllWBsT AT S MPH. HAIL•.. Im'ENSE RAUl AND STRONG DAMAGING WIND9 All!! LIKELY WI'!'H THISSTOnM.</geecription>
<instructiou>TAKE COVER IN A SUBSTANTIAL SHELTER UNTIL THE STORM PAS9ES.</inatruction><contactsBARUFFALDl/JUSKIE</contact> .<ax-ae>
<areaDeec>l'IX'I'REME NORTH CENTRAL TUOLUMNE COUNTY IN CALII.'ORNrA, EXTREH& NOR.TlIEASTERllCALAVERAS COUNTY IN CALIFORNIA, SOUTHWESTERN ALPINE COUNTY IN CALIFORNIA</areaDesc>
<polY9on>38.~7,-120.14 38,34,-119.95 38.52,-119.74 38.62,-119.89 38.47,-120,14</polyson><geocod<;l>
<valueNama>FIPS6</valueName><value>006109</value>
</geocode><geocode"
<valueName" FIPS6< IvalueName><velue>006009</value>
</geocode><geoQode>
<valueName>PIPS6</valueName><value>006003</value>
</geocode></aree>
</info></alert>
CAP·V1.1Copyright © OASIS Open2005. All Rights Reserved.
1 October 2005Page 30 013.5
WIT.039.001.0081
l\ o'J. l.C&~ H q~J'(. lq,·C
The following is a speculative example in the formofa CAP XML message.
<?xml version" "1.0 '1 encodfnq 0= "tlTF-8"?><alert xmkns " "u:nlloasis :names : to, el1lergency,oap,l.l">
<identifier>TRI13970976.1</identifier.<sender>[email protected]</sender><sent>2003-06-11T20,56,OO-07,OO<!sent><status>~ctual</Btatus><msgType>~lert</me9Type>
<scopa>Public</ecope><incidents.13970876</incid~nts>
<info><category>Geo</category><event~Earthquake</event><urgsncy>Past</urgency.<ssverity>Minor</severity><certainty>Ohservad</certainty><send~rName>SouthernCalifornia'Seismic Network (TriNet) operated by Caltech and
USQS</eenderName><headline>EQ 3.4 Imperial County CA - PRELIMINARY REPORT</neadline><desoription>~ minor earthquake measuring 3.4 on the Riohter scale occurred near Brawley,
California at 8:53 PM Pacific Daylight Time on wednesday, June 11, 2003. {This is a computergenerated solution and has not 1st been reviewed by a human.)~/deecription>
<web>http.//www.trinet.org/ecsn/scen.html</web><parameter>
<valueName>EventlO</valueName><velue>13970876</value>
</pa.ramete:r><parameter>
~valueName.Ve:rBion</valueName>
<valus>l</value></parameten<parameter>
<velueName.Magnitude</valueName><valus>3.4 Ml</value>
</pa.ramete:r><parameter>
<~alueName>Depth</valueName>
<value>11.9 mi.</value></parameter><paral1leter> '
<valueName>Quslity</velueName><value.Excellent</valuB>
</paratneter><:area~
<areaDeac>1 mi. WSW of Brawley, CAl 11 mi. N of E1 Centro, CAl 20 mi. E of OCOTILLO(quarry) I 1 mi. N of the Imperial Fault</areaOeec>
<circle>32.9525,-115.5527 o</circle></area>
</info></alert>
CAP-V1.1Copyright@ OASIS Open 2005. All Rights Reserved.
1 October 2005Page31of35
WIT.039.001.0082
587
588
589590591592593594595596597598599600601602603604606606607608609610611612613614615616617618619620621622623624625
l ,dice l i:[[!;l t l@Ll (lui1C[~)]@;IKti( i (~ t \\,;U'(j'(§jU@L'l!j
The following is a speculative example in the form of a CAP XMLmessage.
<?xml version a "1.0" encoding ~ ·UTF-B"?;.<alert mnlns ,. "urn,oasia:names,tc,emergency:cap:1.1">
<identi£ier>KARO-0300112239-Sw</identifier><sender>[email protected]</sender><sent>2003-06-11T22,39:00-07:00</sent"<status;.Actual</status><msgType>Alert</msgType><source"SW</source><scope>?ublic</scope><info>
<category>~escue</categ6ry>
<event"child Abduction</event><urgency>Immediate</urgency><severity>severe</severity><certainty>Likely</oertainty><eventCods>
<valueName>S~</valueName>
<value>CAE</valus></eventCode><senderName>LOg ANGELES POLICE DEPT - LAPD</senderName><headline>AMBER ALERT</headline><description>DATE/TIME: 00/11/03, 1915 HRS. VICTIM(S), KHAYRI DOE JR. M/B 'BLK/BRa 3'0", 40
LBS. LIGHT COMPLBXION. DOB 06/24/01. WEARING RED SHORTS, WHITE T-SHIRT, W/BLUE COLLAR.LOCATION: 5721 DOE ST., L~S ~GELES, CA. SUSPECT(S): KHAYRI DOE SR. DOB 04/10/71 M/B, BLK HAIR,BRO EYE. VEHICLE, 81' BUICK 2·DR, BLUE (4XXXOOO) .~/desoription>
<contact>DET. SMI~H, 77TH DIV, LOS ANGELES POLICB DBPT-LAPD AT 213 485-2309~/contact>
<area><~reaDeec>Los Angeles County</areaDesc~
<geocode><valueName>BAME~/valueName>
<value>006037</value></geooode>
</arf!Ja></in£o>
</alert>
CAp·V1.1Copyright© OASISOpen2005. All Rights Reserved.
1 October2005Page32 of 35
WIT.039.001.0083
626 . 1-, IL l t
627 ("{).!~ [,[Ui"lfQ"'7n~y ~G[ l®~t tl: ,..1(~ltll L11.dtl.CC
628 JohnAerts, LA County Information Systems Advisory Body629 PattiAymond, IEM630 MarkBenemerlto, Sungard Availability Services631 Jeff Berg. Motorola632 Art Botterell, Partnership for PublicWaming633 ChrisBranton, IEM634 Rex Brooks, HumanMarkup.org, Inc.635 Thomas Sui.TheBoeing Company636 Len Bullard, Individual637 Charles Campbell, Individual638 Richard Carlton, IndivIdual639 EliotChristian, USDepartment of the Interior640 MarcConnolly, Oracle641 Robin Cover, OASIS642 Michael Daconta, USDepartment of Homeland Security643 David Danko, ESRI644 PaulDenning, Mitre Corporation645 JohnDias, Lawrence Livermore National Laboratory646 Matthew Dovey, Oxford University647 Sukumar Dwar!<anath. Individual648 ScottEdson, LA County Information Systems Advisory Body649 Nas.eamElkarra, Individual650 David, Ellis, Individual651 Paul Embley, Individual652 JackFox, US Department of Homeland Security653 Lawrence Freudinger, NASA654 Gary Ham, Disaster Management Interoperability Services655 Travis HUbbard, Disaster Management (nteroperabllity Services656 Stephen Jepsen, Oracle657 Elysa Jones, Warning Systems. Inc.658 Joyce Kern, Sungard AvailabJllty Services659 Hong-Eng Koh, SunMicrosystems660 JeffKyser, Warning Systems, Inc,661 Louis Lagonik, Lockheed Martin662 Kim Lambert, LMI Government ConSUlting663 RIchard Maslin,S, IBM664 Carl Mattocks, Individual665 Maurice McGinley, Individual.666 TomMerkle, Lockheed Martin667 80na Nasutlon, MTGManagement Consultants, LLC.668 Steve Ollis, Individual669 AshParikh, Raining Data Corporation670 Brian Pattinson, Unisys Corporation671 Gary Poindexter, IndivIdual672 Walid Ramadan, Individual673 Michelle Raymond, Individual674 Carl Reed, Open GIS Consortium (OGC)675 Kent Reed, NIST676 Jeffrey Ricker, Individual677 David Roberts, Unlsys Corporation
CAP-Vl,1Copyright @ OASIS Open 2005. All Rights Reserved.
1 October 2005Page 33 of 35
WIT.039.001.0084
678 Dave Robinson, Wells Fargo679 Eleanor Robinson, Anteon Corporation680 John Ruegg, LA County Information SystemsAdvisory Body681 Barry Schaeffer, Individual682 William Schroeder, ESRIa83 John Sliva, Individual684 Kwasi Speede, Anteon Corporation685 Michael Thompson, The Boeing Company686 Rob Torchon, E Team687 Brett Trusko, OASIS688 Rlcl< Tucker, MItre CorporatIon689 RIchardVandame, US Department of Homeland Security690 Jerry Weltman, IEM691 Preston Wemtz, Individual692 Konstantin \Mlms, Individual693 Bob Wyman Individual694 Jack Zhang Beijing Harmony TechnologiesCo, Ltd695
CAP·V1.1Copyright@ OASIS Open2005. All Rights Reserved.
1 October2005Page34of35
WIT.039.001.0085
696
697
Rev Date ByWhom What
1.1 2005·07·27 Art Botterell Edits to conform object model,datadictionary andschema:
Q Reordered Items Inobject diagram and datadictionary to match sequence required byschema.
0 Edited schema to make<scope> mandatory andtopermit multiple Instances of <responseType>and <eventCode>, In accordance withthedatadictionary•
1.1 2005-07-23 Art Bottarell Applied changes per recommendations of MessagingSubcommittee basedonInl,tial publiccomment periQd:
0 Modified XMLsyntaxof <eventCode> ,<parameter> and<geooode>
0 Added '0raft" valuefor <:status>
• Changed CAPnamespece to URN form0 Tightened usage of dateTImeformats In<sent>,
<effective>, <onset> and<expiration>0 Corrected schema to correct value of"CBRNE'ln
<event>
Q Conformed exam piesin Appendix A tonewnamespace.
1.1 2005·04·28 ElyseJones Technicsl Committee approved thev. 1.1 draftwilh thefollowing addlli onalchanges:
• Normative language added to specify uniquenessor <identifier>
0 Change [dateTi me] formatfor <sent>, <effective>,<onset> and <expires> elements
0 Change <language> elementRFC from 1166 to3066 and addednull
• Changed the<mlneType> element RFC 1521 to2046
0 Added <derefURI;> element
0 Security Note updated andadded DigitalSignature andEncryptlonnoteparagraphe
1.1 2005-01-04 Art Bolterell Messaging Subcommittee approved v. 1.1 draftforsubmission to full Technical Committee:
0 Added <responseType> elament
0 Made <category> element mendatory
0 Amended enum eratedvaluesfor the<certainty>element
0 Deleted the<password> element
0 Various aditorial corrections andclarifications
1.0 2004·04·01 Art Botterell CAP 1.0adopted as OASIS Standard (see CAP 1.0specification document for priorchange history.)
CAP-V1.1Copyright@ OASIS Open 2005. All Rights Reserved.
1 October 2005Page 35of 35
WIT.039.001.0086