Specification URIs:

This Version:

http://docs.oasis-open.org/emergency/edxl-rm/v1.0/pr02/EDXL-RM-SPEC-V1.0.doc

http://docs.oasis-open.org/emergency/edxl-rm/v1.0/pr02/EDXL-RM-SPEC-V1.0.pdf

http://docs.oasis-open.org/emergency/edxl-rm/v1.0/pr02/EDXL-RM-SPEC-V1.0.html

Previous Version:

http://docs.oasis-open.org/emergency/edxl-rm/v1.0/cd01/EDXL-RM-SPEC-V1.0.doc

http://docs.oasis-open.org/emergency/edxl-rm/v1.0/cd01/EDXL-RM-SPEC-V1.0.pdf

http://docs.oasis-open.org/emergency/edxl-rm/v1.0/cd01/EDXL-RM-SPEC-V1.0.html

Latest Version:

http://docs.oasis-open.org/emergency/edxl-rm/v1.0/EDXL-RM-SPEC-V1.0.doc

http://docs.oasis-open.org/emergency/edxl-rm/v1.0/EDXL-RM-SPEC-V1.0.pdf

http://docs.oasis-open.org/emergency/edxl-rm/v1.0/EDXL-RM-SPEC-V1.0.html

Technical Committee:

Emergency Management          

Chair(s):

Elysa Jones, Warning Systems, Inc.

Editor(s):

Dr. Patti Aymond, Individual

Rex Brooks, Individual

Tim Grapes, DHS Disaster Management Interoperability Service

Gary Ham, Individual

Dr. Renato Iannella, National ICT Australia (NICTA)

Dr. Karen Robinson, National ICT Australia (NICTA)

Werner Joerg, IEM, Inc

Alessandro Triglia, OSS Nokalva, Inc

Related work:

This specification is related to:

·         Emergency Data Exchange Language (EDXL) Distribution Element, v. 1.0

 

Declared XML Namespace(s):

urn:oasis:names:tc:emergency:EDXL:RM:1.0

urn:oasis:names:tc:emergency:EDXL:RM:1.0:Reference

urn:oasis:names:tc:emergency:EDXL:RM:1.0:RequestResource

urn:oasis:names:tc:emergency:EDXL:RM:1.0:ResponseToRequestResource

urn:oasis:names:tc:emergency:EDXL:RM:1.0:RequisitionResource

urn:oasis:names:tc:emergency:EDXL:RM:1.0:CommitResource

urn:oasis:names:tc:emergency:EDXL:RM:1.0:RequestInformation

urn:oasis:names:tc:emergency:EDXL:RM:1.0:ResponseToRequestInformation

urn:oasis:names:tc:emergency:EDXL:RM:1.0:OfferUnsolicitedResource

urn:oasis:names:tc:emergency:EDXL:RM:1.0:ReleaseResource urn:oasis:names:tc:emergency:EDXL:RM:1.0:RequestReturn

urn:oasis:names:tc:emergency:EDXL:RM:1.0:ResponseToRequestReturn

urn:oasis:names:tc:emergency:EDXL:RM:1.0:RequestQuote

urn:oasis:names:tc:emergency:EDXL:RM:1.0:ResponseToRequestQuote

urn:oasis:names:tc:emergency:EDXL:RM:1.0:RequestResourceDeploymentStatus

urn:oasis:names:tc:emergency:EDXL:RM:1.0:ReportResourceDeploymentStatus

urn:oasis:names:tc:emergency:EDXL:RM:1.0:RequestExtendedDeploymentDuration

urn:oasis:names:tc:emergency:EDXL:RM:1.0:ResponseToRequestExtendedDeploymentDuration

 

Abstract:

This XML-based Emergency Data Exchange Language (EDXL) Resource Messaging specification describes a suite of standard messages for data sharing among emergency and other information systems that deal in requesting and providing emergency equipment, supplies, people and teams. This format may be used over any data transmission system, including but not limited to the SOAP HTTP binding.

Status:

This document was last revised or approved by the Emergency Management Technical Committee on the above date. The level of approval is also listed above. Check the current location noted above for possible later revisions of this document.

Technical Committee members should send comments on this specification to the Technical Committee’s email list. Others should send comments to the Technical Committee by using the “Send A Comment” button on the Emergency Management TC web page at http://www.oasis-open.org/committees/emergency/.

For information on whether any patents have been disclosed that may be essential to implementing this specification, and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of the Technical Committee web page at http://www.oasis-open.org/committees/emergency/ipr.php

The non-normative errata page for this specification is located at http://www.oasis-open.org/committees/emergency/.

 

Copyright © OASIS® 1993–2007. All Rights Reserved.

All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual Property Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the OASIS website.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to OASIS, except as needed for the purpose of developing any document or deliverable produced by an OASIS Technical Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must be followed) or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

OASIS requests that any OASIS Party or any other Party that believes it has patent claims that would necessarily be infringed by implementations of this OASIS Committee Specification or OASIS Standard, to notify OASIS TC Administrator and provide an indication of its willingness to grant patent licenses to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification.

OASIS invites any Party to contact the OASIS TC Administrator if it is aware of a claim of ownership of any patent claims that would necessarily be infringed by implementations of this specification by a patent holder that is not willing to provide a license to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification. OASIS may include such claims on its website, but disclaims any obligation to do so.

OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS' procedures with respect to rights in any document or deliverable produced by an OASIS Technical Committee can be found on the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this OASIS Committee Specification or OASIS Standard, can be obtained from the OASIS TC Administrator. OASIS makes no representation that any information or list of intellectual property rights will at any time be complete, or that any claims in such list are, in fact, Essential Claims.

The names "OASIS", “Emergency Data Exchange Language,” “Emergency Data Exchange Language Distribution Element,” “Emergency Data Exchange Language Hospital Availability Exchange,” “Emergency Data Exchange Language Resource Messaging,” “EDXL,” “EDXL-DE,” “EDXL-HAVE” and “EDXL-RM” are trademarks of OASIS, the owner and developer of this specification, and should be used only to refer to the organization and its official outputs. OASIS welcomes reference to, and implementation and use of, specifications, while reserving the right to enforce its marks against misleading uses. Please see http://www.oasis-open.org/who/trademark.php for above guidance.

1     Introduction.. 8

1.1 Purpose.. 8

1.2 History.. 8

1.3 Structure of the EDXL Resource Message.. 9

1.4 Terminology.. 10

1.5 Normative References.. 10

1.6 Non-Normative References.. 11

2     Design Principles and Concepts (non-normative) 12

2.1 Requirements for Design.. 12

2.2 Distribution of EDXL-RM.. 13

2.2.1 EDXL DISTRIBUTION ELEMENT (EDXL-DE) 13

2.2.2 EDXL RESOURCE MESSAGING (EDXL-RM) DISTRIBUTION.. 13

2.3 Example Usage Scenarios.. 13

2.3.1 Safecom Explosion.. 14

2.3.2 Cedar Fire Incident 14

2.3.3 Hurricane. 15

2.3.4 Pandemic Influenza. 15

3     EDXL Resource Messaging Model (Normative unless otherwise stated) 16

3.1 Abstract Reference Model (Non-Normative) 16

3.2 Element Reference Model. 18

3.3 Resource Message Types.. 18

3.4 RequestResource Message.. 25

3.4.1 Overview.. 25

3.4.2 Element Reference Model 25

3.4.3 RequestResource Message Rules. 26

3.4.4 Message Flow.. 27

3.4.5 Message Example. 27

3.5 ResponseToRequestResource Message.. 30

3.5.1 Overview.. 30

3.5.2 Element Reference Model 30

3.5.3 ResponseToRequestResource Message Rules. 31

3.5.4 Message Flow.. 32

3.5.5 Message Example. 32

3.6 RequisitionResource Message.. 35

3.6.1 Overview.. 35

3.6.2 Element Reference Model 35

3.6.3 RequisitionResource Message Rules. 36

3.6.4 Message Flow.. 37

3.6.5 Message Example. 37

3.7 CommitResource Message.. 40

3.7.1 Overview.. 40

3.7.2 Element Reference Model 40

3.7.3 CommitResource Message Rules. 41

3.7.4 Message Flow.. 42

3.7.5 Message Example. 42

3.8 RequestInformation Message.. 45

3.8.1 Overview.. 45

3.8.2 Element Reference Model 45

3.8.3 RequestInformation Message rules. 46

3.8.4 Message Flow.. 47

3.8.5 Message Example. 47

3.9 ResponseToRequestInformation Message.. 49

3.9.1 Overview.. 49

3.9.2 Element Reference Model 49

3.9.3 ResponseToRequestInformation Message Rules. 50

3.9.4 Message Flow.. 51

3.9.5 Message Example. 52

3.10 OfferUnsolicitedResource Message.. 55

3.10.1 Overview.. 55

3.10.2 Element Reference Model 55

3.10.3 OfferUnsolicitedResource Message Rules. 56

3.10.4 Message Flow.. 57

3.10.5 Message Example. 57

3.11 ReleaseResource Message.. 60

3.11.1 Overview.. 60

3.11.2 Element Reference Model 60

3.11.3 ReleaseResource Message Rules. 61

3.11.4 Message Flow.. 62

3.11.5 Message Example. 62

3.12 RequestReturn Message.. 65

3.12.1 Overview.. 65

3.12.2 Element Reference Model 65

3.12.3 RequestReturn Message Rules. 66

3.12.4 Message Flow.. 67

3.12.5 Message Example. 67

3.13 ResponseToRequestReturn Message.. 69

3.13.1 Overview.. 69

3.13.2 Element Reference Model 69

3.13.3 ResponseToRequestReturn Message Rules. 70

3.13.4 Message Flow.. 71

3.13.5 Message Example. 71

3.14 RequestQuote Message.. 73

3.14.1 Overview.. 73

3.14.2 Element Reference Model 73

3.14.3 RequestQuote Message Rules. 74

3.14.4 Message Flow.. 75

3.14.5 Message Example. 75

3.15 ResponseToRequestQuote Message.. 78

3.15.1 Overview.. 78

3.15.2 Element Reference Model 78

3.15.3 ResponseToRequestQuote Message Rules. 79

3.15.4 Message Flow.. 80

3.15.5 Message Example. 80

3.16 RequestResourceDeploymentStatus Message.. 83

3.16.1 Overview.. 83

3.16.2 Element Reference Model 83

3.16.3 RequestResourceDeploymentStatus Message Rules. 84

3.16.4 Message Flow.. 85

3.16.5 Message Example. 85

3.17 ReportResourceDeploymentStatus Message.. 87

3.17.1 Overview.. 87

3.17.2 Element Reference Model 87

3.17.3 ReportResourceDeploymentStatus Message Rules. 88

3.17.4 Message Flow.. 89

3.17.5 Message Example. 89

3.18 RequestExtendedDeploymentDuration.. 92

3.18.1 Overview.. 92

3.18.2 Element Reference Model 92

3.18.3 RequestExtendedDeploymentDuration Message Rules. 93

3.18.4 Message Flow.. 94

3.18.5 Message Example. 94

3.19 ResponseToRequestExtendedDeploymentDuration Message.. 96

3.19.1 Overview.. 96

3.19.2 Element Reference Model 96

3.19.3 ResponseToRequestExtendedDeploymentDuration Message Rules. 97

3.19.4 Message Flow.. 98

3.19.5 Message Example. 98

4     Data Dictionary (NORMATIVE) 101

4.1.1 EDXLResourceMessage ElementReferenceType Type. 101

4.1.2 IncidentInformation Element 104

4.1.3 MessageRecall Element 105

4.1.4 Funding Element 106

4.1.5 ResourceInformation Element 107

4.1.6 ResponseInformation Element 107

4.1.7 Resource Element 108

4.1.8 OwnershipInformation Element 112

4.1.9 ResourceStatus Element 114

4.1.10 AssignmentInformation Element 117

4.1.11 AssignmentInstructions Element 120

4.1.12 ScheduleInformation Element 122

4.1.13 Supporting Element Types. 124

4.1.13.1 ContactInformationType. 124

4.1.13.1.1 Radio Element 127

4.1.13.2 LocationType. 127

4.1.13.2.1 Imported Type Definitions. 129

4.1.13.3 ValueListType. 132

5     Conformance.. 133

5.1 Conformance Targets.. 133

5.2 Conformance Levels.. 133

5.3 Conformance as an EDXL-RM Message.. 134

5.3.1 Level-1 EDXL-RM Message. 134

5.3.2 Level-2 EDXL-RM Message. 134

5.4 Conformance as an EDXL-RM Message Producer.. 135

5.4.1 Level-1 EDXL-RM Message Producer 135

5.4.2 Level-2 EDXL-RM Message Producer 135

A.      XML Schema for the EDXL Resource Messaging (NORMATIVE) 136

A.1 Resource Messaging Common Types.. 136

A.2 Resource Messaging Reference Schema.. 140

A.3 RequestResource Message Schema.. 142

A.4 ResponseToRequestResource Message Schema.. 144

A.5 RequisitionResource Message Schema.. 146

A.6 CommitResource Message Schema.. 147

A.7 RequestInformation Message Schema.. 149

A.8 ResponseToRequestInformation Message Schema.. 151

A.9 OfferUnsolicitedResource Message Schema.. 153

A.10 ReleaseResource Message Schema.. 155

A.11 RequestReturn Message Schema.. 157

A.12 ResponseToRequestReturn Message Schema.. 159

A.13 RequestQuote Message Schema.. 161

A.14 ResponseToRequestQuote Message Schema.. 163

A.15 RequestResourceDeploymentStatus Message Schema.. 164

A.16 ReportResourceDeploymentStatus Message Schema.. 166

A.17 Request Extended Deployment Duration Message Schema.. 169

A.18 ResponseToRequestExtendedDeploymentDuration Message Schema   171

A.19 Acknowledgements.. 173

B.      Revision History.. 174

 

 

1.1 Purpose

As detailed in the EDXL-DE Specification, the goal of the EDXL project 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. EDXL will accomplish this goal by focusing on the standardization of specific messages (messaging interfaces) to facilitate emergency communication and coordination particularly when more than one profession or governmental jurisdiction is involved.

The primary purpose of the Emergency Data Exchange Language Resource Messaging (EDXL-RM) Specification is to provide a set of standard formats for XML emergency response messages. These Resource Messages are specifically designed as payloads of Emergency Data Exchange Language Distribution Element- (EDXL-DE)-routed messages. Together EDXL-DE and EDXL-RM are intended to expedite all activities associated with resources needed to respond and adapt to emergency incidents. The Distribution Element may be thought of as a "container". It provides the information to route "payload" message sets (such as Alerts or Resource Messages), by including key routing information such as distribution type, geography, incident, and sender/recipient IDs.

 

The Resource Message is constrained to the set of Resource Message Types contained in this specification. The Resource Message is intended to be the payload or one of the payloads of the Distribution Element which contains it.

 

1.2 History

Disaster Management (DM) is a communications program in the Department of Homeland Security’s (DHS) Office for Interoperability and Compatibility (OIC) and managed by the Science and Technology (S&T) Directorate. The program was initiated as one of the President’s e-government initiatives. DM’s mission is to serve as the program within the Federal Government to help local, tribal, state, and federal public safety and emergency response agencies improve public safety response through more effective and efficient interoperable data sharing. The DHS DM program sponsors a Practitioner Steering Group (PSG).

 

The DM Practitioner Steering Group (PSG) governance was formalized following publication of the EDXL Distribution Element. It plays a key role in the direction, prioritization, definition, and execution of the DHS-DM program. The group is comprised of representatives of major emergency response associations, setting priorities and providing recommendations regarding messaging standards development as well as the other facets of the DM program.

 

The PSG specified messaging standards-based systems interoperability as the top priority for the DHS Disaster Management program. The EDXL Resource Messaging Specification effort was identified as the top priority standard by this group following the EDXL-DE. The requirements and specification effort was initiated by this group in partnership with industry members of the Emergency Interoperability Consortium (EIC) in a Standards Working Group (SWG). That group developed a draft specification which was submitted to the OASIS Emergency Management Technical Committee to begin work on this EDXL-RM specification.

 

The process remained the same as with the EDXL-DE specification with the exception that the Technical Committee requested that the initial candidate specification submitted by the expert group be recast as a formal Requirements Document according to a template that the Technical Committee provided to the expert group. The candidate specification was then resubmitted along with this requested requirements document.

1.3 Structure of the EDXL Resource Message

As stated in Section 1.1, the EDXL Resource Message specification defines 16 separate and specific message types supporting the major communication requirements for allocation of resources across the emergency incident life-cycle. This includes preparedness, pre-staging of resources, initial and ongoing response, recovery and demobilization / release of resources.

The EDXL Resource Message structure is defined using successively more detailed or constrained artifacts in the form of diagrams, figures and tables. The overall structure of the EDXL Resource Message is first represented in a reference model referred to as the Element Reference Model (ERM). This overall model is the foundation from which individual constraint schemas (individual resource message types) are defined. The ERM (Section 3.2) with the Data Dictionary (Section 4) defines the overall structure of Resource Messages including message structure (element cardinality), message element definitions and cardinality which must be adhered to. An overall XML schema is also provided for the ERM.

 

Following overall Resource Message definition, each individual EDXL Resource Message type is defined. Table 2 provides a matrix defining required, optional and conditional message elements for each EDXL Resource Message. A section is then provided for each individual EDXL Resource Message (each message constrains the overall ERM or reference model), providing the normative ERM, element cardinality and optionality, business rules and message flow that defines each individual message type. Message XML and example XML is also provided for each message.

The following descriptions of these artifacts are here only as preparation to better understand how to use these diagrams, figures and tables

The non-normative Abstract Reference Model diagram in Figure 1 shows the abstract structural relationships of the main components or elements. The normative ERM diagram in Figure 2 shows the structural relationships of the main Resource Messaging elements. Elements are logical groupings of message elements for purposes of defining message structure

1. The EDXLResourceMessage element itself is the top level element of this specification as a whole, and contains the message elements that identify and describe the message with information such as ID, DateTime, ContactInformation, MessageDescription and previous message references;
2. An IncidentInformation element identifies and describes the incident with which the message is concerned;
3. A MessageRecall element is needed when a message updates or cancels a previous message;
4. A Funding element specifies applicable codes and specific funding information;
5. A ResourceInformation element specifies the resource information or resource requirement. The ResourceInformation element contains:
1. A Resource element to identify and describe the specific resource or resources with which the message is concerned, such as ID, Name, Type and Description. The Resource element contains the following additional elements:

                                          i.    An OwnershipInformation element; and,

                                         ii.    A ResourceStatus element.

2. A ResponseInformation element that identifies the Resource to which it applies, specifies the ResponseType such as Accept or Decline, a ResponseCode and ResponseReason;
3. An AssignmentInformation element to specify information such as Quantity, PriceQuote and OrderID. The AssignmentInformation element includes:

                                          i.    An AssignmentInstructions element for specifying ModeOfTransportation, NavigationInstructions and ReportingInstructions; and,

4. A ScheduleInformation element to specify a ScheduleType, such as RequestedArrival, RequestedDeparture, ActualArrival and Actual Departure, as well as DateTime and Location;
5. A ContactInformation element is organized separately to be reused in Resource Message Elements as needed, and it reuses the OASIS Customer Information Quality Specifications;
6. A LocationType element is organized separately to be used in Resource Message elements as needed, using the geo-oasis:WhereType;
7. A ValueListType element is organized and specified separately to be used in Resource Message elements as needed.

Table 1 provides a Resource Message Type Summary of the 16 specific types of Resource Message. This is useful for getting a quick overview of the message types contained in the specification.

Figure 3 illustrates the three primary types of behavior which Resource Messages enable:

·         Discovery;

·         Ordering; and

·         Deployment.

Table 2 provides a Resource Message Type – Element Matrix where each row represents a specific message element grouped by element group and each column represents a specif