The Cover PagesThe OASIS Cover Pages: The Online Resource for Markup Language Technologies
Advanced Search
Site Map
CP RSS Channel
Contact Us
Sponsoring CP
About Our Sponsors

Cover Stories
Articles & Papers
Press Releases

XML Query

XML Applications
General Apps
Government Apps
Academic Apps

Technology and Society
Tech Topics
Related Standards
Created: May 19, 2005.
News: Cover StoriesPrevious News ItemNext News Item

OASIS Advances Common Alerting Protocol and Emergency Data Exchange Language.


Members of the OASIS Emergency Management Technical Committee have released a Version 1.1 Committee Draft for the Common Alerting Protocol (CAP) specification, and invite public review through July 15, 2005. Members of the TC are also actively participating in the development an XML-based Emergency Data Exchange Language (EDXL), intended to provide a broader integrating framework for a wide range of emergency data exchange standards and application types.

Version 1.0 of the Common Alerting Protocol was approved as an OASIS Standard in April 2004 and has been adopted widely. CAP is "a simple but general format for exchanging all-hazard emergency alerts and public warnings over all kinds of networks. CAP allows a consistent warning message to be disseminated simultaneously over many different warning systems, thus increasing warning effectiveness while simplifying the warning task. CAP also facilitates the detection of emerging patterns in local warnings of various kinds, such as might indicate an undetected hazard or hostile act. CAP also provides a template for effective warning messages based on best practices identified in academic research and real-world experience."

In CAP Version 1.1, "several important changes have been made as a result of real-world implementation by participating groups." A responseType element has been added to support recommendation of specific life-saving measures to be taken in the event of an emergency: Shelter: Take shelter in place or per an instruction; Evacuate: Relocate as instructed in the instruction; Prepare: Make preparations per the instruction; Execute: Execute a pre-planned activity identified in an instruction; Monitor: Attend to information sources as described in an instruction; etc. CAP version 1.1 now also includes a derefURI element to allow inclusion of the contents of a web page in situations where real-time retrieval of the web page is not practical.

The category element is now mandatory in CAP Version 1.1; it stores a code identifying the category of the subject event of the alert message: geophysical; meteorological; general safety; security (law enforcement, military, homeland and local/private security); rescue and recovery; fire; medical and public health; pollution and other environmental hazards; public and private transportation; infrastructure (utility, telecommunication, other non-transport); CBRNE (chemical, biological, radiological, nuclear or high-yield explosive threat or attack).

The CAP format "is compatible with emerging techniques, such as Web services, as well as existing formats including the Specific Area Message Encoding (SAME) used for the United States' National Oceanic and Atmospheric Administration (NOAA) Weather Radio and the Emergency Alert System (EAS). CAP also offers enhanced capabilities that include: (1) flexible geographic targeting using latitude/longitude shapes and other geospatial representations in three dimensions; (2) multilingual and multi-audience messaging; (3) phased and delayed effective times and expirations; (4) enhanced message update and cancellation features; (5) template support for framing complete and effective warning messages; (6) compatible with digital encryption and signature capability; (7) facility for digital images and audio."

The primary use of the CAP Alert Message is to "provide a single input to activate all kinds of alerting and public warning systems. This reduces the workload associated with using multiple warning systems while enhancing technical reliability and target-audience effectiveness. It also helps ensure consistency in the information transmitted over multiple delivery systems, another key to warning effectiveness. A secondary application of CAP is to normalize warnings from various sources so they can be aggregated and compared in tabular or graphic form as an aid to situational awareness and pattern detection."

While "primarily designed as an interoperability standard for use among warning systems and other emergency information systems, the CAP Alert Message can be delivered directly to alert recipients over various networks, including data broadcasts. Location-aware receiving devices could use the information in a CAP Alert Message to determine, based on their current location, whether that particular message was relevant to their users. The CAP Alert Message can also be used by sensor systems as a format for reporting significant events to collection and analysis systems and centers."

The Emergency Management TC continues to refine the Common Alerting Protocol, bringing it into alignment with other specifications in the Emergency Data Exchange Language (EDXL) suite. EDXL technical specifications are being developed by the OASIS EM-TC in collaboration with DHS/FEMA, the Emergency Interoperability Consortium (EIC), ComCARE Alliance, and other organizations within the emergency management community. At the present time, CAP and EDXL are being progressed in parallel; the OASIS TC hopes to have CAP completely aligned with EDXL by the time of the CAP Version 2.0 release.

Bibliographic Information

Common Alerting Protocol, v. 1.1. Edited by Elysa Jones (Warning Systems, Inc) and Art Botterell (Individual Member). Produced by members of the OASIS Emergency Management TC. Committee Draft. April 28, 2005. Document Identifier: 'CAP-V1.1'. 34 pages.

Contributors [OASIS Emergency Management Technical Committee]: John Aerts (LA County Information Systems Advisory Body), Patti Aymond (IEM), Mark Benemerito (Sungard Availability Services), Jeff Berg (Motorola), Art Botterell (Partnership for Public Warning), Chris Branton (IEM), Rex Brooks ( (Inc), Thomas Bui (The Boeing Company), Len Bullard (Individual), Charles Campbell (Individual), Richard Carlton (Individual), Eliot Christian (US Department of the Interior), Marc Connolly (Oracle), Robin Cover (OASIS), Michael Daconta (US Department of Homeland Security), David Danko (ESRI), Paul Denning (Mitre Corporation), John Dias (Lawrence Livermore National Laboratory), Matthew Dovey (Oxford University), Sukumar Dwarkanath (Individual), Scott Edson (LA County Information Systems Advisory Body), Nasseam Elkarra (Individual), David (Ellis (Individual), Paul Embley (Individual), Jack Fox (US Department of Homeland Security), Lawrence Freudinger (NASA), Gary Ham (Disaster Management Interoperability Services), Travis Hubbard (Disaster Management Interoperability Services), Stephen Jepsen (Oracle), Elysa Jones (Warning Systems (Inc), Joyce Kern (Sungard Availability Services), Hong-Eng Koh (Sun Microsystems), Jeff Kyser (Warning Systems (Inc), Louis Lagonik (Lockheed Martin), Kim Lambert (LMI Government Consulting), Richard Masline (IBM), Carl Mattocks (Individual), Maurice McGinley (Individual), Tom Merkle (Lockheed Martin), Bona Nasution (MTG Management Consultants (LLC), Steve Ollis (Individual), Ash Parikh (Raining Data Corporation), Brian Pattinson (Unisys Corporation), Gary Poindexter (Individual), Walid Ramadan (Individual), Michelle Raymond (Individual), Carl Reed (Open GIS Consortium - OGC), Kent Reed (NIST), Jeffrey Ricker (Individual), David Roberts (Unisys Corporation), Dave Robinson (Wells Fargo), Eleanor Robinson (Anteon Corporation), John Ruegg (LA County Information Systems Advisory Body), Barry Schaeffer (Individual), William Schroeder (ESRI), John Silva (Individual), Kwasi Speede (Anteon Corporation), Michael Thompson (The Boeing Company), Rob Torchon (E Team), Brett Trusko (OASIS), Rick Tucker (Mitre Corporation), Richard Vandame (US Department of Homeland Security), Jerry Weltman (IEM), Preston Werntz (Individual), Konstantin Wilms (Individual), Bob Wyman (Individual), Jack Zhang (Beijing Harmony Technologies Co Ltd).

About the OASIS Emergency Management TC

Background: "[Given] natural and man-made disasters, there is an enormous need to remove any barriers that prevent or hinder data, communication, and technology interoperability. Many of the barriers are inherit side effects of bringing together diverse people, cultures, geographical locations, and systems, but today's technology can and should be used to help bridge gaps and overcome these obstacles. Specifically, applications can be empowered to support open structured information standards, which can then provide mechanisms to leverage disparate data, any services, and functional assets."

The OASIS Emergency Management TC was chartered to "design, develop, and release XML Schema-based standards that begin to solve the real-world problems of incident preparedness, response, and emergency management. These standards will not only provide a framework for data exchange, but also for functionality and service accessibility, all with the common goal of seamless application and data interoperability.

The core scope of this activity shall include, but is not limited to: (1) Unified incident identification; (2) Emergency GIS data accessibility and usage; (3) Notifications methods and messages; (4) Situational reporting; (5) Source tasking; (6) Asset and resources management; (7) Monitoring and data acquisition systems; (8) Staff, personnel and organizational management.

The Emergency Management TC has three subcommittees:

  • Notification and Messaging (EM MSG) Subcommittee, chaired by Rex Brooks and Art Botterell, "focuses on the exchange of alerts, notifications, and incident related messages, which not only include various types of informational broadcast, but also electronic ICS (Incident Command System) form representation." See the email archive.
  • Infrastructure Framework (EM IF) Subcommittee, chaired by Tom Merkle, "focuses on identifying, researching, and providing guidance on various standards, both developed in and external to the OASIS EM TC, as they relate to emergency and incident management with the purpose of ensuring elemental compatibility with both the currently adopted systems and communication mediums today, as well as tomorrow." See the email archive.
  • Geospatial Information Systems (EM GIS) Subcommittee, chaired by Carl Reed, "focuses on ensuring each OASIS EM TC-related specifications has the proper geospatial capabilities to allow a GIS to leverage our formats. Additionally, the group is responsible for providing guidance for filling GIS related gaps within the existing emergency and incident standards." See the email archive.

Related Effort: Emergency Data Exchange Language (EDXL)

While the OASIS Emergency Management TC progresses the CAP specification toward a version 2.0, its members are also working with other organizations to develop the first components of the Emergency Data Exchange Language (EDXL). The EDXL standards activity is coordinated with DHS/FEMA (as part of the Disaster Management eGov Initiative) and with the Emergency Interoperability Consortium (EIC); hosting services are provided by the Comcare Alliance. Background information on EDXL is presented in a January 2005 Memorandum of Agreement (MOA) which "establishes an alliance between the Department of Homeland Security (DHS) and the Emergency Interoperability Consortium (EIC) to promote the design, development, release and use of XML schema-based standards or other standards, tools, and processes that will help solve data sharing problems..." According to the accompanying announcement, "The next generation of data sharing standards, being developed with the leadership of emergency response organizations, is called Emergency Data Exchange Language (EDXL). It goes beyond alerting to address the routing and substance of a wide variety of interagency emergency messaging..."

According to a summary from Art Botterell, "CAP came first and focused on alerting, eventing, and attention-management applications. EDXL was a follow-on initiative to create an integrating framework for a wide range of emergency data exchange standards to support operations, logistics, planning and finance. The first instance of EDXL is set to be a common routing-assertion element that can be used to envelop other kinds of XML documents including CAP messages... but that's just one component, not the whole idea... The Technical Committee's plan has been to continue to refine the existing CAP 1.0 spec, which is already in use in a variety of systems and addresses a number of immediate needs, though one or more sub-versions (CAP 1.1 being in work right now)... while at the same time setting up the broader EDXL framework... and then to bring CAP into that larger framework with CAP 2.0 at some point in the future. So, CAP is a particular document for a narrow set of applications, while EDXL was conceived as a much broader framework for integrating numerous documents and application types..." [adapted from a posting of April 21, 2005 by Art Botterell]

A draft of the Emergency Data Exchange Language (EDXL) Distribution Element was released by the EM-TC on May 17, 2005: This draft describes a standard message distribution framework for data sharing among emergency information systems using the XML-based Emergency Data Exchange Language (EDXL). This format may be used over any data transmission system, including but not limited to the SOAP HTTP binding. The <Distribution> element asserts the originator's intent as to the dissemination of that particular message or set of messages. Note that use of the <Distribution> element does not guarantee that all network links and nodes will implement the asserted dissemination policy or that unintended disclosure will not occur. Where sensitive information is transmitted over untrusted networks, it should be encrypted in accordance with the Web Services Security (WSS) standard with any updates and errata published by the OASIS Web Services Security Technical Committee, or some other suitable encryption scheme. The EDXL Distribution Element (DE) comprises a <Distribution> element as described, optional <targetArea> elements describing geospatial or political target area for message delivery, and a set of <messageElement> elements each containing specific information regarding a particular item of content, which it includes within a <contentObject> structure. The included content may be any XML or other file or document. The <Distribution> block may be used without content to form the body of a routing query to, or response from, a directory service." 'Figure 1' provides a UML diagram for the Data Model of the EDXL Distribution Element.

EDXL Initiative Overview from the Comcare Alliance

"The goal of the EDXL initiative is to facilitate emergency information sharing and data exchange across the local, state, tribal, national and non-governmental organizations of different professions that provide emergency response and management services. The effort focuses on standardization of specific messages (messaging interfaces) to facilitate emergency communication and coordination particularly when more than one profession is involved. Once standardized, any technology vendor or organization can easily develop their XML-based messaging interface.

The EDXL Practitioners group drives priorities and requirements for specific EDXL messages sets and messaging components. The objective is to rapidly deliver implementable standard messages in an incremental fashion directly to emergency response agencies in the trenches, providing seamless communication and coordination supporting each particular process. The effort first addresses the most urgent needs and proceeds to subsequent message sets in a prioritized fashion. The goal is to incrementally develop and deliver standards...

The EDXL initiative is a national effort including a diverse and representative group of local, state and federal emergency response organizations and professionals, following a multi-step process. A group of practitioners from leading emergency response organizations prioritize specific message sets and define base requirements...

Standard Message Sets: [Several] EDXL components and message sets [have been] identified to date for standardization activity. It is important to distinguish between the 'Distribution Element' vs. the other message sets; 'Distribution Element' may be thought of as a container which facilitates the routing of message sets (any properly formatted XML emergency message) to recipients. The message sets (e.g., Alerts, Resource Management) are carried as payloads that are routed by the Distribution Element...

  • Distribution Element: An EDXL 'Distribution Element' has been developed [and] the OASIS Emergency Management Technical Committee is reviewing it to make it a public standard... The Distribution Element carries and routes 'payload' message sets (such as Alerts or Resource Management), by specifying key routing information such as incident type and affected geography, as well as basic information such as incident ID, message type and sending agency. A series of demonstrations starting in October 2004 verified application of the Distribution Element by demonstrating generation, receipt and update of common message sets across different emergency technology tools owned by a diversity of government jurisdictions and emergency response agencies. A growing number of emergency technology vendors are using the Distribution Element in ongoing demonstrations and are prepared to incorporate it into their production systems when it becomes an official standard...

  • Alert Message Set: The Common Alerting Protocol (CAP) was developed by many of the same parties and processes as EDXL. It was originally sponsored by the Partnership for Public Warning and became an official OASIS standard in 2004. It has been adopted as a payload within EDXL messages, due to the flexibility of the EDXL 'open container model'. CAP messages facilitate the exchanging of hazard emergency alerts and public warnings. Any other accepted standard XML format can also be the payload carried and routed by the EDXL distribution element.

  • Resource Message Set: The initial EDXL practitioner group said last fall [2004] that its next priority was message sets regarding Resource Messaging (RM). They asked for messages to request (or respond to requests) for persons and things required in emergencies. A draft document addressing a Resource Message has been developed and is being considered by the Standards Working Group. A number of detailed scenarios are being analyzed to determine the wide range of specific interagency and inter-profession resource messages.

  • Geographic Information Systems (GIS): Following Resource Management Messaging, the next priority is to provide message sets addressing GIS information. The GIS message set addresses the need to identify, track, trend, or forecast events and resources. This message set also addresses the need to establish the geospatial context; to communicate about geographic features and things through standard symbols and associated information. For example, a GIS message may assist an emergency responder to assess the geographic scope of an event, to locate a required resource, to pinpoint where a resource needs to report, or to assess other geographic considerations related to an event. The symbology for this message will be 'consumed' from efforts led by FEMA, FGDC and other applicable efforts developing common mapping symbols.

  • Situation Status: Situation status is a report providing the overall status of an event and the subsequent emergency response.

  • Other specific message sets: Additional message needs will be addressed as the Practitioners raise the need for them..." [adapted from the document "Emergency Data Exchange Language (EDXL) Overview and Phased Approach" (Evolution Technologies)]

EDXL: Summary from the Emergency Interoperability Consortium (EIC)

According to a report from EIC ("Creating an Emergency Data Exchange Language"):

EDXL was proposed as a "cooperative effort to define a NIMS-compliant family of shared data exchange specifications encompassing: Incident Notification and Situation Reports; Status Reporting; Resource Requests and Dispatch; Analytical Data; Geospatial Information; Identification and Authentication.

The first design principle for EDXL will be collaboration and transparency; the second will be adopting, promoting and spreading the work that has already been done to other professions (particularly with the very extensive GJXDM dictionary), i.e. no re-inventing of wheels; the third principle will be speed to deployment. The Disaster Management eGov Initiative (managed by DHS' Disaster Management Program) is providing organizational resources and technical support. The involvement of all emergency practitioner groups is encouraged. The ComCARE Alliance has been tasked by DHS to facilitate these groups' participation...

EDXL is intended to "comprise three layers of data exchange standards utilizing XML data syntax and services:

  • EDXL Vocabulary: Specified data elements and taxonomies to apply common terminology to data sharing regarding emergency incidents, conditions, resources, activities and outcomes. This will draw heavily on current common-vocabulary efforts (Justice Data Dictionary, FEMA resource typing, NIMS, etc) and the XML standards cited above. This project will support emergency organizations reviewing the XML and taxonomy work product of other professions to find commonalities (the 'common terms' project).
  • EDXL Messages: We will develop formats for messages (XML documents) using the EDXL Vocabulary to implement routing of emergency messages (a draft 'header' has been produced, trialed and submitted for standards approval) and business processes such as emergency response resources reports, queries, updates, cancellations and error-handling. The current focus is on resource messages.
  • EDXL Interfaces: Technical protocols and formats for routing of EDXL messages over various kinds of data networks and systems, based on SOAP and web-services standards, but generalized for use in a wide variety of communications environments. Our goal is to make it simple and straightforward for vendors to write interfaces from their products to EDXL."

EDXL References:

Other Initiatives

Standards for emergency alert and response systems are being developed within many jurisdictions: see for example the listing "Emergency Standards Efforts" from the web site, and the small collection of XML-related initiatives referenced in "XML and Emergency Management." Here are two examples:

  • U.S. National Information Exchange Model (NIEM). "NIEM is an interagency initiative to provide the foundation and building blocks for national-level interoperable information sharing and data exchange, announced in February 2005. It is initiated as a joint venture between the U.S. Department of Homeland Security (DHS) and the U.S. Department of Justice (DOJ) with outreach to other departments and agencies. The base technology for the NIEM is the Global JXDM. The NIEM will leverage both the extensive Global JXDM reference model and the comprehensive Global JXDM XML-based framework and support infrastructure. Its mission is to assist in developing a unified strategy, partnerships, and technical implementations for national information sharing — laying the foundation for local, state, tribal, and federal interoperability by joining together communities of interest. That foundation consists of three parts: core data components, reusable XML exchange packages, and business-process models for information sharing. The business process drives the creation of information exchange packages that are populated by reusable components..."


  • Emergency Services Interconnection Forum (ESIF). "ESIF is the primary venue for the telecommunications industry, public safety and other stakeholders to generate and refine both technical and operational interconnection issues to ensure that life-saving E9-1-1 service is available for everyone in all situations. ESIF enables many different telecommunications entities to fully cooperate and interconnect with each other to determine the best practices and solutions necessary to effectively and promptly deploy E9-1-1 services. ESIF's mission is to facilitate the identification and resolution of both technical and operational issues related to the interconnection of telephony and emergency services networks. ESIF is co-convened by the Alliance for Telecommunications Industry Solutions (ATIS) and the National Emergency Number Association (NENA).


Principal References

Hosted By
OASIS - Organization for the Advancement of Structured Information Standards

Sponsored By

IBM Corporation
ISIS Papyrus
Microsoft Corporation
Oracle Corporation


XML Daily Newslink
Receive daily news updates from Managing Editor, Robin Cover.

 Newsletter Subscription
 Newsletter Archives
Bottom Globe Image

Document URI:  —  Legal stuff
Robin Cover, Editor: