1 Introduction

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 jor 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 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 Presidents e-gov 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) made up of represenations of major emergency response associations.

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, and 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 interoperatility as the #1 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

The EDXL Resource Message specification applies to 16 separate specific message types related to the major communication purposes involved in the allocation of resources pertaining to preparation for, response to and remediation of emergency incidents.

The non-normative abstract reference model diagram in Figure 1 in Section 3.1 shows the abstract structural relationships of the main components:

· Resource Message: The overall Type of EDXL Payload;

· Message: The specific message, primarily of Request or Response general types, but with signficant other subtypes;

· Party: Organizations and Individuals connected with the message;

· Resource: the actual referrent of the message, which can be equipment, material substances such as water, people with certain skills, etc;

· Schedule: Temporal information such as when requested, when needed, when arrived, etc., associated with the message;

· Assignment: Instructions relative to the displosition of Resource or Resources referred to in the message usually related to geospatial and jurisdictional information.

The Element Reference Model in Figure 2 in Section 3.2 gives a more concrete view of the structure common to all Resource Messages.

Table 1 in Section 3.3 provides a Resource Message Type Summary of the 16 specific types of Resource Message.

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

· Discovery;

· Ordering; and

· Deployment.

Table 1: in Section 3.3 provides a Resource Message Type – Element Matrix where each row represents a specific message element grouped by functional categories and each column represents a specific message type. Thus one can determine whether any combination of message element and message type is Required, Conditional, or Optional.

Each specific message type is fully described in Sections 3.3.1 through 3.3.16

1.4 Terminology

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in Error! Reference source not found..

1.5 Normative References

[RFC2046] N. Freed, Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types, http://www.ietf.org/rfc/rfc2046.txt, IETF RFC 2046, November 1996.

[RFC2119] S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, http://www.ietf.org/rfc/rfc2119.txt, IETF RFC 2119, March 1997.

[RFC3066] H. Alvestrand, Tags for the Identification of Languages, http://www.ietf.org/rfc/rfc3066.txt, IETF RFC 3066, January 2001.

[WGS 84] National Geospatial Intelligence Agency, Department of Defense World Geodetic System 1984, http://earth-info.nga.mil/GandG/tr8350_2.html, NGA Technical Report TR8350.2, January 2000.

[XML 1.0] T. Bray, Extensible Markup Language (XML) 1.0 (Third Edition), http://www.w3.org/TR/REC-xml/, W3C REC-XML-20040204, February 2004.

[namespaces] T. Bray, Namespaces in XML, http://www.w3.org/TR/REC-xml-names/, W3C REC-xml-names-19990114, January 1999.

[dateTime] N. Freed, XML Schema Part 2: Datatypes Second Edition, http://www.w3.org/TR/xmlschema-2/#dateTime, W3C REC-xmlschema-2, October 2004.

1.6 Non-Normative References

[EDXL GFR] EDXL General Functional Requirements, http://www.oasis-open.org/committees/download.php/10031/EDXL%20General%20Functional%20Requirements.doc, November 2004

[EDXL-DE IG] EDXL Distribution Element Implementer's Guide, http://www.oasis-open.org/committees/download.php/14120/EDXL_Implementer%27sGuide.doc, August 2005

[EDXL-RM SRS] EDXL Resource Messaging Standard Requirements Supplement, workgroup http://www.oasis-open.org/committees/download.php/14981/EDXLRqmtsSupplement101905.doc, October 19, 2005

[EDXL-RM SF] EDXL Resource Messaging Standard Format for Resource Messaging (candidate specification) http://www.oasis-open.org/committees/download.php/13690/EDXL_ResourceDraft07152005.doc, July 15, 2005

2 Design Principles and Concepts (non-normative)

Below are some of the guiding principles of the Resource Message:

Provide a standard message format for the Resource Message
Provide separate specific formats for the discrete, distinct Resource Message Types
Enable dissemination of messages based on geographic delivery area
Use and re-use of data content and models developed by other initiatives
Business process-driven specific messaging needs across emergency professions
Supporting everyday events and incident preparedness, as well as disasters
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

2.1 Requirements for Design

The initial requirements submitted to the Technical Committee by the EDXL Standards Working Group described in Section 1.2 can be reviewed :

EDXL Resource Messaging Standard Requirements Supplement, workgroup

http://www.oasis-open.org/committees/download.php/14981/EDXLRqmtsSupplement101905.doc, October 19, 2005

In summary, the EDXL Resource Messaging specification should

1. Define a detailed message formet structure for the following specific EDXL Resource Message Types: (Note that requirements that are self-evident from Message Type names are not separately listed)

a. RequestResource

b. Response to Request Resource

c. Requisition Resource

d. Commit Resource

e. Request Information (RFI)

f. Response to Request Information

g. Offer Unsolicited Resource

h. ReleaseResource

i. Request Return

j. Response to Request Return

k. Request Quote

l. Response to Request Quote

m. Request Resource Deployment Status

n. Report Resource Deployment Status

o. Request Extended Deployment Duration

p. Response to Request Extended Deployment Duration

2. Explicitly specify use of EDXL_DE as the routing mechanism for the EDXL Resource Message

3. Provide the ability to specify a desired geographic Resource delivery area, provide for notice of Resource demobilization and the ability to communicate information to provide for returning Resource

4. Provide ability to accept or decline a Response to Request Resource that indicates requested Resource is available or to accept or decline an Offer of Unsolicited Resource

5. Provide the ability to cancel any Resource Message (actual method is Message Recall)

6. Provide the ability to reference specific incidents in Resource Message

7. Provide unique identifier for each message as well as the ability to reference previous messages, including but not limited to originating message in a given sequence

8. Provide the ability to specify Date and Time of Resource Message, referenced messages, scheduling information, assignment information and specific instructions

9. Provide the ability to report Disposition of referenced Resource Message(s)

10. Provide the ability to specify contact information of individuals responsible for Resource Message(s) and/or Resource(s)

11. Provide the ability to specify funding information for Resources

12. Provide the ability to reference external lists for Resource Message content

13. Provide the ability to fully describe Resource(s)

14. Provide the ability to specify Special Requirements such as protective equipment or specific skill credentials, e.g. certifications, licenses

15. Provide the ability to specify Resource Information for purposes beyond identification and qualification such as scheduling and assignment.

2.2 Example Usage Scenarios

Note: The following examples of use scenarios were used as a basis for design and review of the EDXL Resource Messaging Specification. These scenarios are non-normative and not intended to be exhaustive or to reflect actual practices.

2.2.1 Safecom Explosion

This scenario follows the detection of a noxious aerosol substance leak at a demical plant that produces toxic materials, including evacuations, requests for hazmat teams and the evolution of the incident into an explosion that destroys the leak sit and an adjacent building with casualties requiring emergency healthcare teams, full incident command establishment, responses of various kinds and clean up

Full use case available: http://www.oasis-open.org/committees/download.php/14410/EDXL_use_example_SafecomExplosion%20060805.doc

2.2.2 Cedar Fire Incident

This is an actual use case that follows the events of the “Cedar” fire incident inlate October and November 2003 in San Diego County, California. Operation Center (EOC) has been activated, and requests the agencies to be on alert. This follows the lack of radio interoperability and poor coordination of mutual aid in the area due to several other fires during the period and previously

Full use case available: http://www.oasis-open.org/committees/download.php/14411/EDXL_use_example_Fire061005.doc

2.2.3 Hurricane

This scenario modeled a category 5 hurricance several months prior to the start of the 2005 hurricane season in earnest, and follows many different kinds of resource requests and evolving situations as a widespread incident with mass casualties and damage occurs.

Full use case available: http://www.oasis-open.org/committees/download.php/14412/EDXL_use_example_Hurricane061005.doc

2.2.4 Pandemic Influenza

This scenario models an Influenza Pandemic outbreak at Phase 6 (Increased and pre-sustained transmission in general population) as determined by the State Health Agency/Public Health Department. It includes such activities as requesting medical facilities to take stock and determine what resources are readily available and on hand (inventory of available supplies). It includes a wide range of resource messages such as requests for vaccines and anti-.virals.

Full use case available: http://www.oasis-open.org/committees/download.php/14411/EDXL_use_example_Influenza_06152005%20LaniGrahmRev.doc

3 EDXL Resource Messaging Model (Non-normative)

3.1 Abstract Reference Model

Figure 1 below shows the Resource Messaging Abstract Reference Model (RM-ARM). The purpose of the RM-ARM is to highlight the high-level structure of the RM framework and the relationships between the main entities.

The Resource Message contains either one of two major message categories: a Request or a Response message; or a minor message category type, a Report message;.These two major and one minor message categories form the underlying framework for all messages. The Resource Message also contains information on the Party (person or organisation) that plays a significant Role in the message transaction. Funding information can also be specified.

Figure 1: Resource Messaging – Abstract Reference Model

The core of any message is the Resource. A Resource contains information about its Identity, Description and its Status. A Resource owner can also be identified.

A Resource may also have a schedule which includes Temporal and Spatial details. For example, the expected arrival time and place for a specific resource. There are a number of types for Schedules.

A Resource may also have information about its Assignment including the identified Incident and Instructions related to the incident assignment.

3.2 Element Reference Model

Figure 2 below shows the EDXL–RM Element Reference Model (ERM). The purpose of the ERM is to highlight the low-level structure of the RM framework and the relationships between the main entities and their elements.

It is important to note that the ERM should not be used as an implementation model as the exact semantics and structure is captured in the subsequent sections on the Resource Message Types.

Figure 2: Resource Messaging – Element Reference Model

The RM-ERM shows the element-level details for the main entities in the RM. The semantics for each of the elements is defined in Section Error! Reference source not found..

3.3 Resource Message Types

The general RM framework is based on a Request/Response model. Most of the Request messages expect a Response, and in some cases, messages are used to notify others of changes or offers of resources.

This two-way communication is characterised by two classes of primary actors. The Resource Consumer is an actor that needs or requires resources to undertake response to an incident. The Resource Supplier is an owner, or distributor, or manager of resources that can meet the needs of Resource Consumers. There may be more than one actor of each class for a given sequence of message exchanges, and there may also be other classes of actors besides these two primary types.

There are 16 resource messages defined in this specification, which are summarized in Table 2 below.

Table 2: Resource Message Type Summary

Message Type	Description	Message Sender
Request Resource	Message used to request needed resources from one or many recipients, possibly spawning multiple responses. [RequestResource]	Resource Consumer
Response to Request Resource	Message used as the response to a “Request Resource”. Allows sender to list resource(s) which they feel represent suitable match with a resource request. [ResponseToRequestResource]	Resource Supplier
Requisition Resource	Message used to “order” specific resource, or to confirm specific resource to be “ordered” relating to one or more responses to a “Request Resource”. RequisitionResource]	Resource Consumer
Commit Resource	Message used to agree or commit specific resource in response to a Resource Request or Requisition, or to a "Request Return”. [CommitResource]	Resource Supplier
Request Information (RFI)	Message used to ask resource questions or provide general description of situation and general resources needs. [RequestInformation]	Resource Consumer
Response to Request Information	Message used as the response to an RFI message providing general information or to list resource that may meet the specified need. [ResponseToRequestInformation]	Resource Supplier
Offer Unsolicited Resource	Message used to offer available resources (that have not been requested) to assist with an emergency response. [OfferUnsolicitedResource]	Resource Supplier
Release Resource	Message used at the incident to “release” (demobilize) resource back to its original Supplier. [ReleaseResource]	Resource Consumer
Request Return	Message used to request release (demobilize) of resources back to its original point of assignment or to another location / assignment ("I want my stuff back"). [RequestReturn]	Resource Supplier
Response to Request Return	Message used as the response to a "Request Return" indicating whether the resource may be released, with relevant time-line information. [ResponseToRequestReturn]	Resource Consumer
Request Quote	Message used to request a price quote from a seller or supplier. [RequestQuote]	Resource Consumer
Response to Request Quote	Message used as the response to a “Request Quote”. Allows sender to list resource(s) which they feel represent suitable match with the request, with pricing information. [ResponseToRequestQuote]	Resource Supplier
Request Resource Deployment Status	Message used to request current “status” of resource. [RequestResourceDeploymentStatus]	Both
Report Resource Deployment Status	Message used to report on the current “status” of any resource. [ReportResourceDeploymentStatus]	Both
Request Extended Deployment Duration	A request initiated by the requester / receiver of resource, “I want to extend how long I need to keep this resource” [RequestExtendedDeploymentDuration]	Resource Consumer
Response to Request Extended Deployment Duration	Message used as the response to “Request Extended Deployment Duration”. [ResponseToRequestExtendedDeploymentDuration]	Resource Supplier

The remainder of this section is informative only. It is included to show how the resource messages might flow between the Resource Consumer and Resource Supplier during resource management. Note, however, that this specification does not prescribe the sequence of message exchanges, except for some dependencies between messages which are described in Section 3.3.1.

The Resource Messages can be used in three phases of resource management:

· Discovery,

· Ordering, and

· Deployment, as shown in Figure 3.

The Discovery phase enables Resource Consumers to find out about available resources, including their costs, and offers of resources from Resource Suppliers.

The Ordering phase enables Resource Consumers to explicitly requisition Resources from Resource Suppliers.

The Deployment phase enables both actors to find about the current status of resources in the field, request extensions and returns.

It is important to note that this specification does not mandate an exact order and workflow of Resoruce Messages. For example, the Ordering phase may actually only require the Commit Resource message for some actors.

Figure 3: Resource Message Phases

Table 3 summarises all the Message Types and their element contents. The specific details on each of the Message Types are outlined in the following sections.

Table 3: Resource Message Type – Element Matrix (Key: R = Required, C = Conditional, O = Optional, N/A – Not Applicable to the message type)

*Schema Segment*	*Message Element*	Request Resource	Response to Request Resource	Requisition Resource	Commit Resource	Request Information (RFI)	Response to Request Information	Offer Unsolicited Resource	Release Resource	Request Return	Response to Request Return	Request Quote	Response to Request Quote	Request Resource Deployment Status	Report Resource Deployment Status	Request Extended Deployment Duration	Response to Request Extended Deployment Duration
Resource Message	MessageID	R	R	R	R	R	R	R	R	R	R	R	R	R	R	R	R
	SentDateTime	R	R	R	R	R	R	R	R	R	R	R	R	R	R	R	R
	MessageContentType	R	R	R	R	R	R	R	R	R	R	R	R	R	R	R	R
	MessageDescription	O	O	O	O	R	O	O	O	O	O	O	O	O	O	O	O
	OriginatingMessageID	R	R	R	R	R	R	R	R	R	R	R	R	R	R	R	R
	PrecedingMessageID	N/A	R	O	R	O	R	N/A	O	O	R	O	R	O	O	N/A	R
	*Incident Information*	O	O	O	O	O	O	O	O	O	O	O	O	O	O	O	O
	*MessageRecall*	O	O	O	O	O	O	O	O	O	O	O	O	O	O	O	O
	*Funding*	O	O	R	O	O	O	N/A	O	O	O	O	O	O	O	O	O
	ContactInformation	R	R	R	R	R	R	R	R	R	R	R	R	R	R	R	R
	*Resource Information*	R	R	R	R	O	O	R	R	R	R	R	R	R	R	R	R
Incident Information	IncidentID	C	C	C	C	C	C	C	C	C	C	C	C	C	C	C	C
Incident Information	IncidentDescription	C	C	C	C	C	C	C	C	C	C	C	C	C	C	C	C
Message Recall	RecalledMessageID	R	R	R	R	R	R	R	R	R	R	R	R	R	R	R	R
Message Recall	RecallType	R	R	R	R	R	R	R	R	R	R	R	R	R	R	R	R
Funding	FundCode	C	C	C	C	C	C	N/A	C	C	C	C	C	C	C	C	C
Funding	FundingInfo	C	C	C	C	C	C	N/A	C	C	C	C	C	C	C	C	C
Resource Information	SequenceNumber	R	R	R	R	R	R	R	R	R	R	R	R	R	R	R	R
	*Response Information*	N/A	R	N/A	R	N/A	O	N/A	O	N/A	R	O	R	N/A	O	N/A	R
	*Resource*	R	O	R	C	O	O	R	R	R	O	R	C	R	O	R	C
	*AssignmentInformation*	O	O	R	C	O	O	O	O	O	O	O	O	O	O	O	O
	*Schedule Information*	O	O	O	C	O	O	O	O	O	O	O	O	O	O	O	O
Response Information	PrecedingSequenceNumber	N/A	R	N/A	R	N/A	R	N/A	R	N/A	R	R	R	N/A	R	N/A	R
	ResponseType	N/A	R	N/A	R	N/A	R	N/A	R	N/A	R	R	R	N/A	R	N/A	R
	ReasonCode	N/A	C	N/A	C	N/A	C	N/A	C	N/A	C	C	C	N/A	C	N/A	C
	ResponseReason	N/A	C	N/A	C	N/A	C	N/A	C	N/A	C	C	C	N/A	C	N/A	C
Resource	ResourceID	C	C	C	C	C	C	C	C	C	C	C	C	C	C	C	C
	Name	C	C	C	C	C	C	C	C	C	C	C	C	C	C	C	C
	TypeStructure	C	C	C	C	C	C	C	C	C	C	C	C	C	C	C	C
	TypeInfo	O	O	O	O	O	O	O	O	O	O	O	O	O	O	O	O
	Keyword	O	O	O	O	O	O	O	O	O	O	O	O	O	O	O	O
	Description	O	O	O	O	O	O	O	O	O	O	O	O	O	O	O	O
	Credentials	O	O	O	O	O	O	O	O	O	O	O	O	O	O	O	O
	Certifications	O	O	O	O	O	O	O	O	O	O	O	O	O	O	O	O
	SpecialRequirements	O	O	O	O	O	O	O	O	O	O	O	O	O	O	O	O
	ResponsibleParty	N/A	O	O	O	O	O	O	O	O	O	O	O	O	O	O	O
	*OwnershipInformation*	N/A	O	O	O	O	O	O	O	O	O	O	O	O	O	O	O
	*Resource Status*	N/A	O	N/A	O	O	O	O	O	O	R	N/A	O	NA	O	O	O
Ownership Information	Owner	N/A	C	C	C	C	C	C	C	C	C	C	C	C	C	C	C
	OwningJurisdiction	N/A	C	C	C	C	C	C	C	C	C	C	C	C	C	C	C
	HomeDispatch	N/A	O	O	O	O	O	O	O	O	O	O	O	O	O	O	O
	HomeUnit	N/A	O	O	O	O	O	O	O	O	O	O	O	O	O	O	O
Resource Status	InventoryRefreshDateTime	N/A	O	N/A	O	O	O	O	N/A	N/A	N/A	N/A	O	N/A	O	N/A	N/A
	DeploymentStatus	N/A	O	N/A	O	O	O	O	O	O	R	N/A	O	N/A	O	O	O
	Availability	N/A	O	N/A	N/A	O	O	O	O	O	R	N/A	O	N/A	O	O	O
Assignment Information	Quantity	O	C	R	R	O	O	O	R	O	O	O	O	O	O	O	O
	Restrictions	O	O	O	O	O	O	O	O	O	O	O	O	O	O	O	O
	AnticipatedFunction	O	O	O	O	O	O	O	O	O	O	O	O	O	O	O	O
	PriceQuote	N/A	O	O	O	O	O	O	O	O	O	N/A	R	O	O	O	O
	OrderID	N/A	N/A	N/A	O	O	O	N/A	O	O	O	N/A	N/A	O	O	O	O
	*Assignment Instructions*	N/A	O	O	O	O	O	O	O	O	O	O	O	O	O	N/A	O
Assignment Instructions	ModeOfTransportation	N/A	O	O	O	O	O	O	O	O	O	O	O	O	O	N/A	O
	NavigationInstructions	N/A	O	O	O	O	O	O	O	O	O	O	O	O	O	N/A	O
	ReportingInstructions	N/A	O	O	O	O	O	O	O	O	O	O	O	O	O	N/A	O
Schedule Information	ScheduleType	R	R	R	R	R	R	R	R	R	R	R	R	R	R	R	R
	DateTime	O	O	O	O	O	O	O	O	O	O	O	O	O	O	O	O
	Location	O	O	O	O	O	O	O	O	O	O	O	O	O	O	O	O

Table 4: Resource Message Type – Element Matrix (Key: R = Required, C = Conditional, O = Optional, N/A – Not Applicable to the message type)

3.3.1 Request Resource Message

3.3.1.1 Overview

The Request Resource message is used as a broad area announcement for resource needs. Emergency Managers, Incident Commanders, First Responders use this message to request information on availability of resources that they need.

3.3.1.2 Element Reference Model

Figure 4 below shows the EDXL–RM Element Reference Model (ERM) tailored for the Request Resource Message. The ERM shows the element-level details for the main entities in the RM.

Figure 4: EDXL-RM ERM for Request Resource Message

The following table outlines the element and attribute cardinalities for this message type, as follows:

– bold indicates an element/attribute that is required

– italics indicate an element/attribute that is conditional (the applicable rules for these elements appear below the table)

– an asterisk (*) indicates that an element/attribute can appear multiple times

– a caret symbol (^) indicates that the values of an element/attribute are constrained, as per the rules shown below the table.

All elements/attributes that are not shown in bold or italics are optional.

Table 5: Request Resource Message Elements

Parent Element	Sub-Elements
ResourceMessage	MessageID, SentDateTime, MessageContentType^, MessageDescription, OriginatingMessageID, IncidentInformation, MessageRecall, Funding ContactInformation, ResourceInformation
IncidentInformation	IncidentID, IncidentDescription
MessageRecall	RecalledMessageID, RecallType
Funding	FundCode, FundingInfo
ResourceInformation	SequenceNumber, Resource, AssignmentInformation, ScheduleInformation*
Resource	ResourceID, Name, TypeStructure, TypeInfo, Keyword*, Description, Credentials, Certifications, SpecialRequirements
AssignmentInformation	Quantity, Restrictions, AnticipatedFunction
ScheduleInformation	ScheduleType^, DateTime, Location

The following rules apply to the above elements/attributes:

· The ResourceMessage:MessageID, ResourceMessage:SentDateTime ResourceMessage:MessageContentType, ResourceMessage:OriginatingMessageID, ResourceMessage:ContactInformation, and ResourceMessage:ResourceInformation elements MUST be present.

· The value of ResourceMessage:MessageContentType MUST be “RequestResource”.

· If a ResourceMessage:IncidentInformation element is present, then at least one of IncidentInformation:IncidentID and/or IncidentInformation:IncidentDescription MUST be present.

· If the ResourceMessage:MessageRecall element is present, then the MessageRecall:RecalledMessageID and MessageRecall:RecallType elements MUST be present.

· If a ResourceMessage:Funding element is present, then at least one of Funding:FundCode and/or Funding:FundingInfo MUST be present.

· The ResourceInformation:SequenceNumber and ResourceInformation:Resource elements MUST be present.

· At least one of Resource:ResourceID, Resource:Name and/or ResourceType:TypeStructure MUST be present.

· If the ResourceInformation:ScheduleInformation element is present, then the value of ScheduleInformation:ScheduleType MUST be present and contain one of the following values:

· New Schedule Information: ”RequestedArrival”, “RequestedDeparture”, “EstimatedReturnDeparture”, “EstimatedReturnArrival”, “ReportTo”, or “Route”.

The schema for a Request Resource message can be found in Appendix A.3.

3.3.1.3 Message Flow

The Request Resource message is an initial message created and sent by the Resource Consumer to any number of Resource Suppliers.

The potential responses to this message include:

· Response to Resource Request (See 0)

· Response may include Accept, Decline, and any Conditional response.

· Acknowledgement

· The EDXL-DE is used for a message acknowledgement.

The message may be canceled or updated through the ResourceMessage:MessageRecall element.

3.3.1.4 Message Example

Below is an example of a Request Resource Message, in which three resource requests are shown:

· Small Animal Sheltering Team (id=001)

· Patrol and Surveillance Helicopters (id=002)

· Electrical Power Restoration Team (id=003)

[Note: The XML example shown in this section is informative only.]

<?xml version="1.0" encoding="UTF-8"?>

<EDXLResourceMessage xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="urn:oasis:names:tc:emergency:EDXL:RM:1.0:RequestResource EDXL-RMRequestResource.xsd"

xmlns="urn:oasis:names:tc:emergency:EDXL:RM:1.0:RequestResource"

xmlns:rm="urn:oasis:names:tc:emergency:EDXL:RM:1.0" xmlns:xpil="urn:oasis:names:tc:ciq:xpil:3"

xmlns:xnl="urn:oasis:names:tc:ciq:xnl:3" xmlns:xal="urn:oasis:names:tc:ciq:xal:3"

xmlns:geo-oasis="http://www.oasis-open.org/oasis/10" xmlns:gml="http://www.opengis.net/gml">

<MessageContentType>Request Resource</MessageContentType>

<rm:IncidentDescription>Cyclone Larry</rm:IncidentDescription>

</IncidentInformation>

<rm:ContactRole>Sender</rm:ContactRole>

<rm:AdditionalContactInformation>

<xnl:PartyName>

<xnl:PersonName>

<xnl:NameElement xnl:ElementType="FirstName">Alex</xnl:NameElement>

<xnl:NameElement xnl:ElementType="LastName">Jones</xnl:NameElement>

</xnl:PersonName>

<xnl:OrganisationName>

<xnl:NameElement>Dept of Emergency Services</xnl:NameElement>

</xnl:OrganisationName>

</xnl:PartyName>

<xpil:ContactNumbers>

<xpil:ContactNumber xpil:MediaType="Telephone" xpil:ContactHours="9:00AM - 5:00PM">

<xpil:ContactNumberElement xpil:ElementType="CountryCode">61</xpil:ContactNumberElement>

<xpil:ContactNumberElement xpil:ElementType="AreaCode">7</xpil:ContactNumberElement>

<xpil:ContactNumberElement xpil:ElementType="LocalNumber">3000

1234</xpil:ContactNumberElement>

</xpil:ContactNumber>

</xpil:ContactNumbers>

<xpil:EmailAddresses>

<xpil:EmailAddress>alexj@emergencyservices.gov.au</xpil:EmailAddress>

</xpil:EmailAddresses>

</rm:AdditionalContactInformation>

</ContactInformation>

<rm:ValueListUrn>urn:x-hazard:vocab:resourceTypes</rm:ValueListUrn>

<rm:Value>Small Animal Sheltering Team</rm:Value>

</TypeStructure>

<Description> 5-person response team to advise and support local efforts to set up a

small animal shelter </Description>

<SpecialRequirements>A qualified vetinary surgeon</SpecialRequirements>

</Resource>

</AssignmentInformation>

<ScheduleType>RequestedArrival</ScheduleType>

<rm:LocationDescription>Innisfail Animal Refuge</rm:LocationDescription>

<rm:Address>

<xal:Country>

<xal:Name>Australia</xal:Name>

</xal:Country>

<xal:AdministrativeArea>

<xal:Name>QLD</xal:Name>

</xal:AdministrativeArea>

<xal:Locality>

<xal:Name>Innisfail</xal:Name>

</xal:Locality>

<xal:Thoroughfare>

<xal:NameElement>Downing St</xal:NameElement>

<xal:Number>27</xal:Number>

</xal:Thoroughfare>

<xal:PostCode>

<xal:Identifier>4860</xal:Identifier>

</xal:PostCode>

</rm:Address>

</Location>

</ScheduleInformation>

<ScheduleType>EstimatedReturnDeparture</ScheduleType>

</ScheduleInformation>

</ResourceInformation>

<rm:ValueListUrn>urn:x-hazard:vocab:resourceTypes</rm:ValueListUrn>

<rm:Value>Patrol and Surveillance Helicopters</rm:Value>

</TypeStructure>

</Resource>

<AnticipatedFunction>Arial surveillance to determine extent of

flooding</AnticipatedFunction>

</AssignmentInformation>

<ScheduleType>RequestedArrival</ScheduleType>

<rm:LocationDescription>Innisfail airport</rm:LocationDescription>

</Location>

</ScheduleInformation>

</ResourceInformation>

<rm:ValueListUrn>urn:x-hazard:vocab:resourceTypes</rm:ValueListUrn>

<rm:Value>Electrical Power Restoration Team</rm:Value>

</TypeStructure>

</Resource>

<AnticipatedFunction> Restore power to critical infrastructure in and around the

Innisfail area </AnticipatedFunction>

</AssignmentInformation>

<ScheduleType>RequestedArrival</ScheduleType>

<rm:TargetArea>

<gml:Point>

<gml:pos> 146.03 -17.53 </gml:pos>

</gml:Point>

</rm:TargetArea>

</Location>

</ScheduleInformation>

</ResourceInformation>

</EDXLResourceMessage>

3.3.2 Response to Request Resource Message

3.3.2.1 Overview

The Response to Request Resource message is used by potential resource suppliers (e.g. mutual aid partners, equipment suppliers, etc.) to respond to Request Resource messages from Logistics Coordinators or others with logistics responsibilities. The response may identify availability, limitations and other pertinent information related to resources in the original request.

3.3.2.2 Element Reference Model

Figure 5 below shows the EDXL–RM Element Reference Model (ERM) tailored for the Response to Request Resource Message. The ERM shows the element-level details for the main entities in the RM.

Figure 5: EDXL-RM ERM for Response to Request Resource Message

The following table outlines the element and attribute cardinalities for this message type.

Table 6: Response to Request Resource Message Elements

Parent Element	Sub-Elements
ResourceMessage	MessageID, SentDateTime, MessageContentType^, MessageDescription, OriginatingMessageID, PrecedingMessageID, PrecedingMessageID, IncidentInformation, MessageRecall, Funding ContactInformation, ResourceInformation
IncidentInformation	IncidentID, IncidentDescription
MessageRecall	RecalledMessageID, RecallType
Funding	FundCode, FundingInfo
ResourceInformation	SequenceNumber, ResponseInformation, Resource, AssignmentInformation, ScheduleInformation*
ResponseInformation	PrecedingSequenceNumber, ResponseType, ReasonCode, ResponseReason
Resource	ResourceID, Name, TypeStructure, TypeInfo, Keyword*, Description, Credentials, Certifications, SpecialRequirements, ResponsibleParty, OwnershipInformation, ResourceStatus
OwnerInformation	Owner, OwningJurisdiction, HomeDispatch, HomeUnit
ResourceStatus	InventoryRefreshDateTime, DeploymentStatus, Availability
AssigmentInformation	Quantity^, Restrictions, AnticipatedFunction, PriceQuote, AssignmentInstructions
AssignmentInstructions	ModeOfTransportation, NavigationInstructions, ReportingInstructions
ScheduleInformation	ScheduleType^, DateTime, Location

The following rules apply to the above elements/attributes:

· The ResourceMessage:MessageID, ResourceMessage:SentDateTime ResourceMessage:MessageContentType, ResourceMessage:OriginatingMessageID, ResourceMessage:PrecedingMessageID, ResourceMessage:ContactInformation, and ResourceMessage:ResourceInformation elements MUST be present.

· The value of ResourceMessage:MessageContentType MUST be “RequestResourceResponse”.

· If a ResourceMessage:IncidentInformation element is present, then at least one of IncidentInformation:IncidentID and/or IncidentInformation:IncidentDescription MUST be present.

· If the ResourceMessage:MessageRecall element is present, then the MessageRecall:RecalledMessageID and MessageRecall:RecallType elements must be present.

· If a ResourceMessage:Funding element is present, then at least one of Funding:FundCode or Funding:FundingInfo MUST be present.

· The ResourceInformation:SequenceNumber and ResourceInformation:ResponseInformation elements must be present.

· The ResponseInformation:PrecedingSequenceNumber and ResponseInformation:ResponseType elements must be present.

· If ResponseInformation:ResponseType has a value of “Conditional”, then at least one of ResponseInformation:ReasonCode and/or ResponseInformation:ResponseReason elements MUST be present.

· At least one of Resource:ResourceID, Resource:Name, and/or ResourceType:TypeStructure element MUST be present.

· If a ResourceInformation:Resource element is present, then at least one of Resource:ResourceID, Resource:Name, and/or ResourceType:TypeStructure element MUST be present.

· If Resource:OwnerInformation is present, then at least one of OwnershipInformation:Owner and/or OwnershipInformation:OwningJurisdiction element MUST be present.

· If the ResourceInformation:AssignementInformation element is present and the ResponseInformation:ResponseType contains a values of “Accept” or “Conditional”, then the AssignmentInformation:Quantity element must be present.

· If ResourceInformation:ScheduleInformation is present then ScheduleInformation:ScheduleType MUST be present and contain one of the the following values:

· New Schedule Information: “EstimatedArrival”, “Estimated Departure”, “RequestedReturnDeparture”, “RequestedReturnArrival”, “BeginAvailable”, and “EndAvailable”,

· Carried Forward Schedule Information: “RequestedArrival”, “RequestedDeparture”, “EstimatedReturnDeparture”, “EstimatedReturnDeparture” or “ReportTo”,

· Either New or Carried Forward Schedule Information: “Route”.

The schema for a Response to Request Resource message can be found in Appendix A.4.

3.3.2.3 Message Flow

The Response to Request Resource message is sent by a Resource Supplier in response to an original Request Resource message.

The potential responses to this message include:

· Acknowledgement

· The EDXL-DE is used for a message acknowledgement.

A Response to Request Resource message MAY be followed by a Requisition message from the Resource Consumer.

The message may be canceled or updated through the ResourceMessage:MessageRecall element.

3.3.2.4 Message Example

Below is an example of a Response to Request Resource Message. This is an example response to the original request shown in Section 3.3.1.4 . In this example, the three requests have different responses:

· The “Small Animal Sheltering Team” (idref=001) has Conditional changes to the request. In this case the Schedule information is different from that requested.

· The “Patrol and Surveillance Helicopters” (idref=002) is Declined.

· The “Electrical Power Restoration Team” (idref=003) is Accepted.

[Note: The XML example shown in this section is informative only.]

<?xml version="1.0" encoding="UTF-8"?>

<EDXLResourceMessage xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="urn:oasis:names:tc:emergency:EDXL:RM:1.0:ResponseToRequestResource EDXL-RMResponseToRequestResource.xsd"

xmlns="urn:oasis:names:tc:emergency:EDXL:RM:1.0:ResponseToRequestResource"

xmlns:rm="urn:oasis:names:tc:emergency:EDXL:RM:1.0" xmlns:xpil="urn:oasis:names:tc:ciq:xpil:3"

xmlns:xnl="urn:oasis:names:tc:ciq:xnl:3" xmlns:xal="urn:oasis:names:tc:ciq:xal:3"

xmlns:geo-oasis="http://www.oasis-open.org/oasis/10" xmlns:gml="http://www.opengis.net/gml">

<MessageContentType>Response to Request Resource</MessageContentType>

<rm:IncidentDescription>Cyclone Larry</rm:IncidentDescription>

</IncidentInformation>

<rm:ContactRole>Sender</rm:ContactRole>

<rm:AdditionalContactInformation>

<xnl:PartyName>

<xnl:PersonName>

<xnl:NameElement xnl:ElementType="FirstName">Charlotte</xnl:NameElement>

<xnl:NameElement xnl:ElementType="LastName">Ryan</xnl:NameElement>

</xnl:PersonName>

<xnl:OrganisationName>

<xnl:NameElement>EMA</xnl:NameElement>

</xnl:OrganisationName>

</xnl:PartyName>

<xpil:ContactNumbers>

<xpil:ContactNumber xpil:MediaType="Telephone">

<xpil:ContactNumberElement xpil:ElementType="CountryCode">61</xpil:ContactNumberElement>

<xpil:ContactNumberElement xpil:ElementType="AreaCode">2</xpil:ContactNumberElement>

<xpil:ContactNumberElement xpil:ElementType="LocalNumber"> 9864

4321</xpil:ContactNumberElement>

</xpil:ContactNumber>

</xpil:ContactNumbers>

</rm:AdditionalContactInformation>

</ContactInformation>

<rm:PrecedingSequenceNumber>001</rm:PrecedingSequenceNumber>

<rm:ResponseType>Conditional</rm:ResponseType>

<rm:ResponseReason>Earliest arrival date is 2006-03-25</rm:ResponseReason>

</ResponseInformation>

<ScheduleType>EstimatedDeparture</ScheduleType>

<rm:LocationDescription>Cairns Airport</rm:LocationDescription>

</Location>

</ScheduleInformation>

<ScheduleType>EstimatedArrival</ScheduleType>

<rm:LocationDescription>Innisfail Airport</rm:LocationDescription>

</Location>

</ScheduleInformation>

<ScheduleType>EstimatedArrival</ScheduleType>

<rm:LocationDescription>Innisfail Animal Refuge</rm:LocationDescription>

<rm:Address>

<xal:Country>

<xal:Name>Australia</xal:Name>

</xal:Country>

<xal:AdministrativeArea>

<xal:Name>QLD</xal:Name>

</xal:AdministrativeArea>

<xal:Locality>

<xal:Name>Innisfail</xal:Name>

</xal:Locality>

<xal:Thoroughfare>

<xal:NameElement>Downing St</xal:NameElement>

<xal:NameElement>27</xal:NameElement>

</xal:Thoroughfare>

<xal:PostCode>

<xal:Identifier>4860</xal:Identifier>

</xal:PostCode>

</rm:Address>

</Location>

</ScheduleInformation>

</ResourceInformation>

<rm:PrecedingSequenceNumber>002</rm:PrecedingSequenceNumber>

<rm:ResponseType>Accept</rm:ResponseType>

</ResponseInformation>

</ResourceInformation>

<rm:PrecedingSequenceNumber>003</rm:PrecedingSequenceNumber>

<rm:ResponseType>Decline</rm:ResponseType>

</ResponseInformation>

</ResourceInformation>

</EDXLResourceMessage>

3.3.3 Requisition Resource Message

3.3.3.1 Overview

The “Requisition Resource” message is used by Resource Consumers to order resources from Resource Suppliers. These may relate to one or more responses to a previous Request Resource message.

3.3.3.2 Element Reference Model

Figure 6 below shows the EDXL–RM Element Reference Model (ERM) tailored for the Requisition Resource Message. The ERM shows the element-level details for the main entities in the RM.

Figure 6: EDXL-RM ERM Requisition Resource Message

The following table outlines the element and attribute cardinalities for this message type.

Table 7: Requisition Resource Message Elements

Parent Element	Sub-Elements
ResourceMessage	MessageID, SentDateTime, MessageContentType^, MessageDescription, OriginatingMessageID, PrecedingMessageID, IncidentInformation, MessageRecall, Funding** ContactInformation, ResourceInformation
IncidentInformation	IncidentID, IncidentDescription
MessageRecall	RecalledMessageID, RecallType
Funding	FundCode, FundingInfo
ResourceInformation	SequenceNumber, Resource, AssignmentInformation, ScheduleInformation*
Resource	ResourceID, Name, TypeStructure, TypeInfo, Keyword*, Description, Credentials, Certifications, SpecialRequirements, ResponsibleParty, OwnershipInformation
OwnershipInformation	Owner, OwningJurisdiction, HomeDispatch, HomeUnit
AssigmentInformation	Quantity, Restrictions, AnticipatedFunction, PriceQuote, AssignmentInstructions
AssignmentInstructions	ModeOfTransportation, NavigationInstructions, ReportingInstructions
ScheduleInformation	ScheduleType^, DateTime, Location

The following rules apply to the above elements/attributes:

· The ResourceMessage:MessageID, ResourceMessage:SentDateTime, ResourceMessage:MessageContentType, ResourceMessage:OriginatingMessageID, ResourceMessage: Funding, ResourceMessage: ContactInformation, and ResourceMessage: ResourceInformation elements MUST be present.

· The value of ResourceMessage:MessageContentType MUST be “RequisitionResource”.

· If a ResourceMessage:IncidentInformation element is present, then at least one of IncidentInformation:IncidentID and/or IncidentInformation:IncidentDescription elements MUST be present.

· If the ResourceMessage:MessageRecall element is present, then the MessageRecall:RecalledMessageID and MessageRecall:RecallType elements must be present.

· If a ResourceMessage:Funding element is present, then at least one of Funding:FundCode and/or Funding:FundingInfo elements MUST be present.

· The ResourceInformation:SequenceNumber, ResourceInformation:Resource and ResourceInformation:AssignmentInformation elements MUST be present

· At least one of Resource:ResourceID, Resource:Name, and/or ResourceType:TypeStructure element MUST be present.

· If a Resource:OwnerInformation is present, then at least one of OwnershipInformation:Owner or/or OwnershipInformation:OwningJurisdiction elements MUST be present.

· The AssignmentInformation:Quantity element MUST be present.

· If ResourceInformation:ScheduleInformation is present, then the ScheduleInformation:ScheduleType MUST be present and contain one of the the following values:

· Carried Forward Schedule Information: “EstimatedArrival”, “EstimatedDeparture”, “EstimatedReturnDeparture”, “EstimatedReturnArrival”, “ReportTo”,

· New or Carried Forward Schedule Information: “RequestedArrival”, “RequestedDeparture”, “EstimatedReturnDeparture”, “EstimatedReturnArrival”, “ReportTo”, or “Route”

The schema for a Requisition Resource message can be found in Appendix A.5.

3.3.3.3 Message Flow

The Requisition Resource message is a message created and sent by the Resource Consumer to any number of Resource Suppliers.

The potential responses to this message include:

· Commit Resource

· This includes Accept, Decline and Conditional responses

· Acknowledgement

· The EDXL-DE is used for a message acknowledgement.

The message may be canceled or updated through the ResourceMessage:MessageRecall element.

3.3.3.4 Message Example

Below is an example of a Requisition Resource Message, in which two resource requisitions are shown:

· Small Animal Sheltering Team (id=001)

· Patrol and Surveillance Helicopters (id=002)

[Note: The XML example shown in this section is informative only.]

<?xml version="1.0" encoding="UTF-8"?>

<EDXLResourceMessage xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="urn:oasis:names:tc:emergency:EDXL:RM:1.0:RequisitionResource EDXL-RMRequisitionResource.xsd"

xmlns="urn:oasis:names:tc:emergency:EDXL:RM:1.0:RequisitionResource"

xmlns:rm="urn:oasis:names:tc:emergency:EDXL:RM:1.0" xmlns:xpil="urn:oasis:names:tc:ciq:xpil:3"

xmlns:xnl="urn:oasis:names:tc:ciq:xnl:3" xmlns:xal="urn:oasis:names:tc:ciq:xal:3"

xmlns:geo-oasis="http://www.oasis-open.org/oasis/10" xmlns:gml="http://www.opengis.net/gml">

<MessageContentType>Requisition Resource</MessageContentType>

<rm:IncidentDescription>Cyclone Larry</rm:IncidentDescription>

</IncidentInformation>

<rm:FundCode>HP4347</rm:FundCode>

</Funding>

<rm:ContactRole>Requester</rm:ContactRole>

<rm:AdditionalContactInformation>

<xnl:PartyName>

<xnl:PersonName>

<xnl:NameElement xnl:ElementType="FirstName">Alex</xnl:NameElement>

<xnl:NameElement xnl:ElementType="LastName">Jones</xnl:NameElement>

</xnl:PersonName>

<xnl:OrganisationName>

<xnl:NameElement>Dept of Emergency Services</xnl:NameElement>

</xnl:OrganisationName>

</xnl:PartyName>

<xpil:ContactNumbers>

<xpil:ContactNumber xpil:MediaType="Telephone" xpil:ContactHours="9:00AM - 5:00PM">

<xpil:ContactNumberElement xpil:ElementType="CountryCode">61</xpil:ContactNumberElement>

<xpil:ContactNumberElement xpil:ElementType="AreaCode">7</xpil:ContactNumberElement>

<xpil:ContactNumberElement xpil:ElementType="LocalNumber">3000

1234</xpil:ContactNumberElement>

</xpil:ContactNumber>

</xpil:ContactNumbers>

<xpil:EmailAddresses>

<xpil:EmailAddress>alexj@emergencyservices.gov.au</xpil:EmailAddress>

</xpil:EmailAddresses>

</rm:AdditionalContactInformation>

</ContactInformation>

<rm:ContactRole>Approver</rm:ContactRole>

<rm:AdditionalContactInformation>

<xnl:PartyName>

<xnl:PersonName>

<xnl:NameElement xnl:ElementType="FirstName">Michelle</xnl:NameElement>

<xnl:NameElement xnl:ElementType="LastName">Yates</xnl:NameElement>

</xnl:PersonName>

<xnl:OrganisationName>

<xnl:NameElement>QLD Police</xnl:NameElement>

</xnl:OrganisationName>

</xnl:PartyName>

<xpil:ContactNumbers>

<xpil:ContactNumber xpil:MediaType="Mobile">

<xpil:ContactNumberElement xpil:ElementType="NationalNumber">0422 877

665</xpil:ContactNumberElement>

</xpil:ContactNumber>

</xpil:ContactNumbers>

<xpil:Occupations>

<xpil:Occupation>

<xpil:OccupationElement xpil:ElementType="Role">District Disaster

Coordinator</xpil:OccupationElement>

</xpil:Occupation>

</xpil:Occupations>

</rm:AdditionalContactInformation>

</ContactInformation>

<rm:ValueListUrn>urn:x-hazard:vocab:resourceTypes</rm:ValueListUrn>

<rm:Value>Small Animal Sheltering Team</rm:Value>

</TypeStructure>

<Description> 5-person response team to advise and support local efforts to set up a

small animal shelter </Description>

<SpecialRequirements>A qualified vetinary surgeon</SpecialRequirements>

</Resource>

<rm:ReportingInstructions>Report to Mark Darcy, Innisfail Animal

Refuge</rm:ReportingInstructions>

</AssignmentInstructions>

</AssignmentInformation>

<ScheduleType>EstimatedArrival</ScheduleType>

<rm:LocationDescription>Innisfail Animal Refuge</rm:LocationDescription>

</Location>

</ScheduleInformation>

<ScheduleType>EstimatedReturnDeparture</ScheduleType>

</ScheduleInformation>

</ResourceInformation>

<rm:ValueListUrn>urn:x-hazard:vocab:resourceTypes</rm:ValueListUrn>

<rm:Value>Patrol and Surveillance Helicopters</rm:Value>

</TypeStructure>

</Resource>

<AnticipatedFunction>Arial surveillance to determine extent of

flooding</AnticipatedFunction>

</AssignmentInformation>

<ScheduleType>RequestedArrival</ScheduleType>

<rm:LocationDescription>Innisfail airport</rm:LocationDescription>

</Location>

</ScheduleInformation>

</ResourceInformation>

</EDXLResourceMessage>

3.3.4 Commit Resource Message

3.3.4.1 Overview

The “Commit Resource” message is used by a Resource Supplier to confirm that resources have been committed to a Resource Consumer request. Usually, the Commit Resource is in response to a Requistion Resource, or even a Request Resource. In some (rarer) cases, the Commit Resource may be the first message sent to confirm a resource allocation from Resource Suppliers to Resource Consumers. The Commit Resource is the only message used to indicate the resources have been allocated to an assignment/incident.

3.3.4.2 Element Reference Model

Figure 7 below shows the EDXL–RM Element Reference Model (ERM) tailored for the Commit Resource Message. The ERM shows the element-level details for the main entities in the RM.

Figure 7: EDXL-RM ERM for Commit Resource Message

The following table outlines the element and attribute cardinalities for this message type.

Table 8: Commit Resource Message Elements

Parent Element	Sub-Elements
ResourceMessage	MessageID, SentDateTime, MessageContentType^, MessageDescription, OriginatingMessageID, PrecedingMessageID, IncidentInformation, MessageRecall, Funding ContactInformation, ResourceInformation
IncidentInformation	IncidentID, IncidentDescription
MessageRecall	RecalledMessageID, RecallType
Funding	FundCode, FundingInfo
ResourceInformation	SequenceNumber, ResponseInformation, Resource^, AssignmentInformation^, ScheduleInformation*^
ResponseInformation	*PrecedingSequenceNumber, ResponseType*, ReasonCode, ResponseReason