Emergency Data Exchange Language Resource Messaging (EDXL-RM) 1.0

Committee Draft 01

20 February 2007

Specification URIs:

 

This 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

Previous Version:

N/A

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, IEM, Inc

Rex Brooks, Individual

Tim Grapes, DHS Disaster Management Interoperability Service

Gary Ham, DHS Disaster Management Interoperability Service

Dr. Renato Iannella, National ICT Australia (NICTA)

Dr. Karen Robinson, National ICT Australia (NICTA)

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

 

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/.

 

Notices

Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply.

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 Resource Messaging,” “EDXL,” “EDXL-DE” 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.

Table of Contents

1     Introduction. 7

1.1 Purpose. 7

1.2 History. 7

1.3 Structure of the EDXL Resource Message. 8

1.4 Terminology. 8

1.5 Normative References. 8

1.6 Non-Normative References. 9

2     Design Principles and Concepts (non-normative) 10

2.1 Requirements for Design. 10

EDXL Resource Messaging Standard Requirements Supplement. Error! Bookmark not defined.

2.2 Example Usage Scenarios. 11

2.2.1 Safecom Explosion. 11

2.2.2 Cedar Fire Incident 11

2.2.3 Hurricane. 11

2.2.4 Pandemic Influenza. 12

3     EDXL Resource Messaging Model (normative) 13

3.1 Abstract Reference Model. 13

3.2 Element Reference Model. 14

3.3 Resource Message Types. 14

3.3.1 Request Resource Message. 18

3.3.1.1 Overview.. 18

3.3.1.2 Element Reference Model 18

3.3.1.3 Message Flow.. 20

3.3.1.4 Message Example. 20

3.3.2 Response to Request Resource Message. 23

3.3.2.1 Overview.. 23

3.3.2.2 Element Reference Model 23

3.3.2.3 Message Flow.. 25

3.3.2.4 Message Example. 25

3.3.3 Requisition Resource Message. 27

3.3.3.1 Overview.. 27

3.3.3.2 Element Reference Model 27

3.3.3.3 Message Flow.. 29

3.3.3.4 Message Example. 30

3.3.4 Commit Resource Message. 32

3.3.4.1 Overview.. 32

3.3.4.2 Element Reference Model 32

3.3.4.3 Message Flow.. 34

3.3.4.4 Message Example. 34

3.3.5 Request Information (RFI) Message. 36

3.3.5.1 Overview.. 36

3.3.5.2 Element Reference Model 36

3.3.5.3 Message Flow.. 38

3.3.5.4 Message Example. 38

3.3.6 Response to Request Information Message. 40

3.3.6.1 Overview.. 40

3.3.6.2 Element Reference Model 40

3.3.6.3 Message Flow.. 42

3.3.6.4 Message Example. 42

3.3.7 Offer Unsolicited Resource Message. 45

3.3.7.1 Overview.. 45

3.3.7.2 Element Reference Model 45

3.3.7.3 Message Flow.. 46

3.3.7.4 Message Example. 47

3.3.8 Release Resource Message. 49

3.3.8.1 Overview.. 49

3.3.8.2 Element Reference Model 49

3.3.8.3 Message Flow.. 52

3.3.8.4 Message Example. 52

3.3.9 Request Return Message. 53

3.3.9.1 Overview.. 53

3.3.9.2 Element Reference Model 54

3.3.9.3 Message Flow.. 55

3.3.9.4 Message Example. 56

3.3.10 Response to Request Return Message. 57

3.3.10.1 Overview.. 57

3.3.10.2 Element Reference Model 57

3.3.10.3 Message Flow.. 59

3.3.10.4 Message Example. 59

3.3.11 Request Quote Message. 60

3.3.11.1 Overview.. 60

3.3.11.2 Element Reference Model 60

3.3.11.3 Message Flow.. 62

3.3.11.4 Message Example. 63

3.3.12 Response to Request Quote Message. 65

3.3.12.1 Overview.. 65

3.3.12.2 Element Reference Model 65

3.3.12.3 Message Flow.. 67

3.3.12.4 Message Example. 67

3.3.13 Request Resource Deployment Status Message. 69

3.3.13.1 Overview.. 69

3.3.13.2 Element Reference Model 69

3.3.13.3 Message Flow.. 71

3.3.13.4 Message Example. 72

3.3.14 Report Resource Deployment Status Message. 73

3.3.14.1 Overview.. 73

3.3.14.2 Element Reference Model 73

3.3.14.3 Message Flow.. 75

3.3.14.4 Message Example. 75

3.3.15 Request Extended Deployment Duration. 77

3.3.15.1 Overview.. 77

3.3.15.2 Element Reference Model 77

3.3.15.3 Message Flow.. 79

3.3.15.4 Message Example. 79

3.3.16 Response to Request Extended Deployment Duration Message. 80

3.3.16.1 Overview.. 80

3.3.16.2 Element Reference Model 80

3.3.16.3 Message Flow.. 82

3.3.16.4 Message Example. 82

4     Data Dictionary. 84

4.1.1 ResourceMessage Element 84

4.1.2 IncidentInformation Element 88

4.1.3 MessageRecall Element 88

4.1.4 Funding Element 89

4.1.5 ResourceInformation Element 90

4.1.6 ResponseInformation Element 90

4.1.7 Resource Element 92

4.1.8 OwnershipInformation Element 95

4.1.9 ResourceStatus Element 97

4.1.10 AssignmentInformation Element 100

4.1.11 AssignmentInstructions Element 103

4.1.12 ScheduleInformation Element 104

 Supporting Element Types. 106

4.1.13. 106

4.1.13.1 ContactInformationType. 106

4.1.13.1.1 Radio Element 108

4.1.13.2 LocationType. 109

4.1.13.2.1 Imported Type Definitions. 110

4.1.13.3 ValueListType. 114

5     Distribution of EDXL-RM.. 116

A.       XML Schema for the EDXL Resource Messaging.. 117

A.1 Resource Messaging Common Types. 117

A.2 Resource Messaging Reference Schema. 122

A.3 Request Resource Message Schema. 124

A.4 Response To Request Resource Message Schema. 127

A.5 Requisition Resource Message Schema. 130

A.6 Commit Resource Message Schema. 132

A.7 Request For Information (RFI) Message Schema. 135

A.8 Response To Request For Information Message Schema. 137

A.9 Offer Unsolicited Resource Message Schema. 140

A.10 Release Resource Message Schema. 142

A.11 Request Return Message Schema. 145

A.12 Response To Request Return Message Schema. 148

A.13 Request Quote Message Schema. 151

A.14 Response to Request Quote Message Schema. 153

A.15 Request Resource Deployment Status Message Schema. 156

A.16 Report Resource Deployment Status Message Schema. 159

A.17 Request Extended Deployment Duration Message Schema. 162

A.18 Response to Request Extended Deployment Duration Message Schema. 165

B.       Acknowledgements. 169

C.       Revision History. 170

 

 


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:

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

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

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

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">

    <MessageID>urn:au-qld-eoc:12332</MessageID>

    <SentDateTime>2006-03-21T11:58:00+10:00</SentDateTime>

    <MessageContentType>Request Resource</MessageContentType>

    <OriginatingMessageID>urn:au-qld-eoc:12332</OriginatingMessageID>

    <IncidentInformation>

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

    </IncidentInformation>

    <ContactInformation>

        <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>

    <ResourceInformation>

        <SequenceNumber>001</SequenceNumber>

        <Resource>

            <TypeStructure>

                <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>

            <Quantity>1</Quantity>

        </AssignmentInformation>

        <ScheduleInformation>

            <ScheduleType>RequestedArrival</ScheduleType>

            <DateTime>2006-03-24T09:00:00+10:00</DateTime>

            <Location>

                <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>

        <ScheduleInformation>

            <ScheduleType>EstimatedReturnDeparture</ScheduleType>

            <DateTime>2006-03-30T17:00:00+10:00</DateTime>

        </ScheduleInformation>

    </ResourceInformation>

    <ResourceInformation>

        <SequenceNumber>002</SequenceNumber>

        <Resource>

            <TypeStructure>

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

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

            </TypeStructure>

        </Resource>

        <AssignmentInformation>

            <Quantity>3</Quantity>

            <AnticipatedFunction>Arial surveillance to determine extent of

            flooding</AnticipatedFunction>

        </AssignmentInformation>

        <ScheduleInformation>

            <ScheduleType>RequestedArrival</ScheduleType>

            <DateTime>2006-03-22T09:00:00+10:00</DateTime>

            <Location>

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

            </Location>

        </ScheduleInformation>

    </ResourceInformation>

    <ResourceInformation>

        <SequenceNumber>003</SequenceNumber>

        <Resource>

            <TypeStructure>

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

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

            </TypeStructure>

        </Resource>

        <AssignmentInformation>

            <Quantity>2</Quantity>

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

                Innisfail area </AnticipatedFunction>

        </AssignmentInformation>

        <ScheduleInformation>

            <ScheduleType>RequestedArrival</ScheduleType>

            <DateTime>2006-03-22T08:00:00+10:00</DateTime>

            <Location>

                <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">

    <MessageID>urn:au-qld-eoc:12334</MessageID>

    <SentDateTime>2006-03-21T12:34:00+10:00</SentDateTime>

    <MessageContentType>Response to Request Resource</MessageContentType>

    <OriginatingMessageID>urn:au-qld-eoc:12332</OriginatingMessageID>

    <PrecedingMessageID>urn:au-qld-eoc:12332</PrecedingMessageID>

    <IncidentInformation>

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

    </IncidentInformation>

    <ContactInformation>

        <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>

    <ResourceInformation>

        <SequenceNumber>001</SequenceNumber>

        <ResponseInformation>

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

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

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

        </ResponseInformation>

        <ScheduleInformation>

            <ScheduleType>EstimatedDeparture</ScheduleType>

            <DateTime>2006-03-25T08:10:00</DateTime>

            <Location>

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

            </Location>

        </ScheduleInformation>

        <ScheduleInformation>

            <ScheduleType>EstimatedArrival</ScheduleType>

            <DateTime>2006-03-25T09:00:00+10:00</DateTime>

            <Location>

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

            </Location>

        </ScheduleInformation>

        <ScheduleInformation>

            <ScheduleType>EstimatedArrival</ScheduleType>

            <DateTime>2006-03-25T09:30:00+10:00</DateTime>

            <Location>

                <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>

    <ResourceInformation>

        <SequenceNumber>002</SequenceNumber>

        <ResponseInformation>

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

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

        </ResponseInformation>

    </ResourceInformation>

    <ResourceInformation>

        <SequenceNumber>003</SequenceNumber>

        <ResponseInformation>

            <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">

    <MessageID>urn:au-qld-eoc:987654</MessageID>

    <SentDateTime>2006-03-21T12:39:00+10:00</SentDateTime>

    <MessageContentType>Requisition Resource</MessageContentType>

    <OriginatingMessageID>urn:au-qld-eoc:12332</OriginatingMessageID>

    <IncidentInformation>

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

    </IncidentInformation>

    <Funding>

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

    </Funding>

    <ContactInformation>

        <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>

    <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>

    <ResourceInformation>

        <SequenceNumber>001</SequenceNumber>

        <Resource>

            <TypeStructure>

                <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>

            <Quantity>1</Quantity>

            <AssignmentInstructions>

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

                Refuge</rm:ReportingInstructions>

            </AssignmentInstructions>

        </AssignmentInformation>

        <ScheduleInformation>

            <ScheduleType>EstimatedArrival</ScheduleType>

            <DateTime>2006-03-25T09:30:00+10:00</DateTime>

            <Location>

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

            </Location>

        </ScheduleInformation>

        <ScheduleInformation>

            <ScheduleType>EstimatedReturnDeparture</ScheduleType>

            <DateTime>2006-03-30T17:00:00+10:00</DateTime>

        </ScheduleInformation>

    </ResourceInformation>

    <ResourceInformation>

        <SequenceNumber>002</SequenceNumber>

        <Resource>

            <TypeStructure>

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

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

            </TypeStructure>

        </Resource>

        <AssignmentInformation>

            <Quantity>3</Quantity>

            <AnticipatedFunction>Arial surveillance to determine extent of

            flooding</AnticipatedFunction>

        </AssignmentInformation>

        <ScheduleInformation>

            <ScheduleType>RequestedArrival</ScheduleType>

            <DateTime>2006-03-22T09:00:00+10:00</DateTime>

            <Location>

                <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

Resource

ResourceID, Name, TypeStructure, TypeInfo, Keyword*, Description, Credentials, Certifications, SpecialRequirements, ResponsibleParty, OwnershipInformation, ResourceStatus

OwnerInformation

Owner, OwningJurisdiction, HomeDispatch, HomeUnit

ResourceStatus

InventoryRefreshDateTime, DeploymentStatus

AssigmentInformation

Quantity, Restrictions, AnticipatedFunction, PriceQuote, OrderID, 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 “CommitResource”.

·         If a ResourceMessage:IncidentInformation element is present, then at least one of IncidentInformation:IncidentID and/or IncidentInformation:IncidentDescription element 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 element MUST be present.

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

·         If ResponseInformation:ResponseType has a value of “Accept” or “Conditional”, then the ResourceInformation:Resource element MUST be present. Note: A ResponseInformation element is required for each resource that is accepted or conditionally accepted. If ResponseInformation:ResponseType has a value of “Decline” and all resources in the RequisitionResource message are being declined, then the Resource element is optional.

·         If ResponseInformation:ResponseType has a value of “Accept” or “Conditional”, then the ResourceInformation:AssignmentInformation element MUST be present. If ResponseInformation:ResponseType has a value of “Decline”, then the ResourceInformation:AssignmentInformation is not applicable.

·         If ResponseInformation:ResponseType has a value of “Accept” or “Conditional”, then the ResourceInformation:ScheduleInformation element MUST be present. If ResponseInformation:ResponseType has a value of “Decline”, then the ResourceInformation:ScheduleInformation is not applicable.

·         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.

·         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 a Resource:OwnerInformation is present, then at least one of OwnershipInformation:Owner and/or OwnershipInformation:OwningJurisdiction element MUST be present.

·         If a ResourceInformation:AssignmentInformation element is present, then the AssignmentInformation:Quantity element MUST be present.

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

·         New Schedule Information: “ActualDeparture”, “Committed”,

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

·         New or Carried Forward Schedule Information: “EstimatedArrival “, “EstimatedDeparture”, “RequestedReturnDeparture”, “BeginAvailable”, “EndAvailable”, or “Route”.

 

The schema for a Commit Resource message can be found in Appendix A.6.

3.3.4.3 Message Flow

The Commit Resource message is sent by a Resource Supplier in response to an either a Request Resource or Requisition Resource message sent by the Resource Consumer.

The potential responses to this message include:

·         Acknowledgement

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

 

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

3.3.4.4 Message Example

Below is an example of a Commit Resource Message. This is an example Response to the original Requisition Resource shown in Section 3.3.3.4. In this example, the two requests have different responses:

·         The “Small Animal Sheltering Team” (idref=001) is Accepted. In this case the Schedule information is updated with Committed and Actual Departure dates.

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

 

[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:CommitResource EDXL-RMCommitResource.xsd"

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

    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">

    <MessageID>urn:au-qld-eoc:997754</MessageID>

    <SentDateTime>2006-03-21T12:46:00+10:00</SentDateTime>

    <MessageContentType>Commit Resource</MessageContentType>

    <OriginatingMessageID>urn:au-qld-eoc:12332</OriginatingMessageID>

    <PrecedingMessageID>urn:au-qld-eoc:987654</PrecedingMessageID>

    <IncidentInformation>

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

    </IncidentInformation>

    <Funding>

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

    </Funding>

    <ContactInformation>

        <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>

        </rm:AdditionalContactInformation>

    </ContactInformation>

    <ResourceInformation>

        <SequenceNumber>001</SequenceNumber>

        <ResponseInformation>

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

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

        </ResponseInformation>

        <Resource>

            <TypeStructure>

                <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>

            <Quantity>1</Quantity>

        </AssignmentInformation>

        <ScheduleInformation>

            <ScheduleType>Committed</ScheduleType>

            <DateTime>2006-03-21T12:46:00+10:00</DateTime>

        </ScheduleInformation>

    </ResourceInformation>

    <ResourceInformation>

        <SequenceNumber>002</SequenceNumber>

        <ResponseInformation>

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

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

        </ResponseInformation>

    </ResourceInformation>

</EDXLResourceMessage>

 

3.3.5 Request Information (RFI) Message

3.3.5.1 Overview

One use of the “Request Information” message is to ask questions about specific resources.  In this case, the message can be the initial message sent from the Resource Consumer to the Resource Suppliers, or it can be a follow up message seeking further information after the Resource Consumer has sent a Request Resource or other resource messages.  A Request Information can be used in this manner even after a resource has been committed and/or deployed; however, if the request is related to the status of a deployed resource, the Request Resource Deployment Status message MUST be used instead.

A second use of this message type is to provide a general description of the sender’s situation and needs, with the expectation of receiving responses suggesting suitable resources.  This is useful when the Resource Consumer is not able to issue a specific Request Resource message because of a lack of knowledge about the resources that would be most appropriate for the situation.

3.3.5.2 Element Reference Model

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

Figure 8: EDXL-RM ERM for Request for Information (RFI) Message

 

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

 

Table 9: Request Information 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, ResourceStatus

OwnerInformation

Owner, OwningJurisdiction, HomeDispatch, HomeUnit

ResourceStatus

InventoryRefreshDateTime, DeploymentStatus, Availability

AssigmentInformation

Quantity, Restrictions, AnticipatedFunction, PriceQuote, OrderID, 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:MessageDescription, ResourceMessage:OriginatingMessageID, and ResourceMessage:ContactInformation elements MUST be present.

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

·         If a ResourceMessage:IncidentInformation element is present, then at least one of IncidentInformation:IncidentID and/or IncidentInformation:IncidentDescription element 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 element MUST be present.

·         If a ResourceMessage:ResourceInformation element is present, then the ResourceInformation:SequenceNumber 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 a Resource:OwnerInformation is present, then at least one of OwnershipInformation:Owner and/or OwnershipInformation:OwningJurisdiction element MUST be present.

·         If the ResourceInformation:ScheduleInformation element is present, then the  ScheduleInformation:ScheduleType MUST be present.

 

The schema for a Request Information message can be found in Appendix A.7.

3.3.5.3 Message Flow

The Request Resource message is sent by the Resource Consumer to any number of Resource Suppliers, and may follow earlier resource messages.

The potential responses to this message include:

·         Response to Request for Information (See 0)

·         This includes Accept, Decline, and Conditional responses

·         Report Resource Deployment Status

·         Acknowledgement

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

3.3.5.4 Message Example

Below are two example Request Information messages.  The first is intended as a follow up message to the Request Resource and Response to Request Resource messages shown in Sections 3.3.1.4 and 3.3.2.4, requesting further information about the third resource that was requested (two electrical power restoration teams).  The second message is a general request for assistance with assessing and repairing a damaged bridge.

 

[Note: The XML examples shown in this section are 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:RequestInformation EDXL-RMRequestInformation.xsd"

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

    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">

    <MessageID>urn:au-qld-eoc:12338</MessageID>

    <SentDateTime>2006-03-21T12:35:00+10:00</SentDateTime>

    <MessageContentType>Request Information</MessageContentType>

    <MessageDescription>Could you please advise the size (personnel and equipment) of each power

        restoration team? </MessageDescription>

    <OriginatingMessageID>urn:au-qld-eoc:12332</OriginatingMessageID>

    <PrecedingMessageID>urn:au-qld-eoc:12332</PrecedingMessageID>

    <IncidentInformation>

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

    </IncidentInformation>

    <ContactInformation>

        <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>

        </rm:AdditionalContactInformation>

    </ContactInformation>

    <ResourceInformation>

        <SequenceNumber>001</SequenceNumber>

        <Resource>

            <TypeStructure>

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

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

            </TypeStructure>

        </Resource>

        <AssignmentInformation>

            <Quantity>2</Quantity>

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

                Innisfail area </AnticipatedFunction>

        </AssignmentInformation>

    </ResourceInformation>

</EDXLResourceMessage>

 

<?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:RequestInformation EDXL-RMRequestInformation.xsd"

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

    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">

    <MessageID>urn:au-qld-eoc:77388</MessageID>

    <SentDateTime>2006-03-21T19:35:00+10:00</SentDateTime>

    <MessageContentType>Request Information</MessageContentType>

    <MessageDescription>Cracks have been reported in the Centenary Bridge in Innisfail. This is a

        major bridge over the South Johnstone River, and appropriate resources are needed urgently

        to assess/repair the cracks. </MessageDescription>

    <OriginatingMessageID>urn:au-qld-eoc:77388</OriginatingMessageID>

    <IncidentInformation>

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

    </IncidentInformation>

    <ContactInformation>

        <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>

</EDXLResourceMessage>

 

3.3.6 Response to Request Information Message

3.3.6.1 Overview

The “Response to Request Information” message is used by Resource Suppliers to respond to an original Request Information message from Resource Consumers.  If the original Request Information message contained one or more ResourceSummary elements, the response MUST Accept or Decline each ResourceSummary element with a separate ResponseSummary element; however, accepting here only entails agreeing to supply the requested information, not agreeing to supply resources.  If the original request did not contain any ResourceSummary elements, one or more ResponseSummary elements MAY be included in the response message (and, in this case, each ResponseSummary element MUST contain the “Accept” element).

3.3.6.2 Element Reference Model

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

Figure 9: EDXL-RM ERM for Response to Request Information Message

 

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

 

Table 10: Response to Request Information 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[1], 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, OrderID, 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, and ResourceMessage:ContactInformation elements MUST be present.

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

·         If a ResourceMessage:IncidentInformation element is present, then at least one of IncidentInformation:IncidentID and/or IncidentInformation:IncidentDescription element 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 element MUST be present.

·         If a ResourceMessage:ResourceInformation element is present, then the ResourceInformation:SequenceNubmer element MUST be present.

·         If the ResourceInformation:ResponseInformation element is present, then the ResponseInformation:PrecedingSequenceNumber and ResponseInformation: ResponseType elements MUST be present.

·         If If the ResourceInformation:ResponseInformation element is present and the ResponseInformation:ResponseType has a value of “Conditional”, then at least one of ResponseInformation:ReasonCode and/or ResponseInformation:ResponseReason elements 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 a Resource:OwnerInformation element is present, then at least one of OwnershipInformation:Owner and/or OwnershipInformation:OwningJurisdiction element MUST be present.

·         If the ResourceInformation:ScheduleInformation element is present, then the  ScheduleInformation:ScheduleType MUST be present.

 

The schema for a Response to Request Information message can be found in Appendix A.8.

3.3.6.3 Message Flow

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

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.

3.3.6.4 Message Example

Below are two example Response to Request Information messages.  These are example responses to the Request Information messages shown in Section 3.3.5.4.

 

[Note: The XML examples shown in this section are 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:ResponseToRequestInformation EDXL-RMResponseToRequestInformation.xsd"

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

    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">

    <MessageID>urn:au-qld-eoc:12346</MessageID>

    <SentDateTime>2006-03-21T12:37:00+10:00</SentDateTime>

    <MessageContentType>Response to Request Information</MessageContentType>

    <MessageDescription>Team consists of 5 overhead (2 person) crews with material handlers; 1

        overhead (2 person) crew; 2 designers; 1 team leader; 1 safety specialist and fleet services

        support. Each team is additionally equipped with digger derrick/pole trailer and auxiliary

        bucket (material handler or 36' bucket). </MessageDescription>

    <OriginatingMessageID>urn:au-qld-eoc:12332</OriginatingMessageID>

    <PrecedingMessageID>urn:au-qld-eoc:12338</PrecedingMessageID>

    <IncidentInformation>

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

    </IncidentInformation>

    <ContactInformation>

        <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>

</EDXLResourceMessage>

 

<?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:ResponseToRequestInformation EDXL-RMResponseToRequestInformation.xsd"

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

    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">

    <MessageID>urn:au-qld-eoc:77397</MessageID>

    <SentDateTime>2006-03-22T08:22:00+10:00</SentDateTime>

    <MessageContentType>Response to Request Information</MessageContentType>

    <MessageDescription>QBuild can send a damage assessment team from Cairns this afternoon. </MessageDescription>

    <OriginatingMessageID>urn:au-qld-eoc:77388</OriginatingMessageID>

    <PrecedingMessageID>urn:au-qld-eoc:77388</PrecedingMessageID>

    <IncidentInformation>

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

    </IncidentInformation>

    <ContactInformation>

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

        <rm:AdditionalContactInformation>

            <xnl:PartyName>

                <xnl:PersonName>

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

                    <xnl:NameElement xnl:ElementType="LastName">James</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

                    4329</xpil:ContactNumberElement>

                </xpil:ContactNumber>

            </xpil:ContactNumbers>

        </rm:AdditionalContactInformation>

    </ContactInformation>

    <ContactInformation>

        <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>

        </rm:AdditionalContactInformation>

    </ContactInformation>

    <ResourceInformation>

        <SequenceNumber>001</SequenceNumber>

        <Resource>

            <TypeStructure>

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

                <rm:Value>Engineering Services: Damage Assessment Team</rm:Value>

            </TypeStructure>

        </Resource>

        <AssignmentInformation>

            <Quantity>1</Quantity>

            <AnticipatedFunction>Preliminary assessment of cracks in Centenary Bridge,

            Innisfail.</AnticipatedFunction>

        </AssignmentInformation>

        <ScheduleInformation>

            <ScheduleType>EstimatedDeparture</ScheduleType>

            <DateTime>2006-03-22T15:00:00</DateTime>

            <Location>

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

            </Location>

        </ScheduleInformation>

        <ScheduleInformation>

            <ScheduleType>EstimatedArrival</ScheduleType>

            <DateTime>2006-03-25T16:00:00+10:00</DateTime>

            <Location>

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

            </Location>

        </ScheduleInformation>

    </ResourceInformation>

</EDXLResourceMessage>

 

3.3.7 Offer Unsolicited Resource Message

3.3.7.1 Overview

The “Offer Unsolicited Resource” message is used to offer available resources (that have not been requested) to assist with an emergency response.

3.3.7.2 Element Reference Model

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

Figure 10: EDXL-RM ERM for Offer Unsolicited Resource Message

 

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

 

Table 11: Offer Unsolicited Resource Message Elements

Parent Element

Sub-Elements

ResourceMessage

MessageID, SentDateTime, MessageContentType^, MessageDescription,  OriginatingMessageID,  IncidentInformation*, MessageRecall, ContactInformation*, ResourceInformation*

IncidentInformation

IncidentID, IncidentDescription

MessageRecall

RecalledMessageID, RecallType

ResourceInformation

SequenceNumber, Resource, AssignmentInformation, ScheduleInformation*

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:ContactInformation, and ResourceMessage:ResourceInformation elements MUST be present.

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

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

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

·          A SequenceNumber and at least one ResourceInformation:Resource 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 and/or OwnershipInformation:OwningJurisdiction element MUST be present.

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

·         New Schedule Information: “EstimatedArrival”, “EstimatedDeparture”, “RequestedReturnDeparture”, “RequestedReturnArrival”, “BeginAvailable”, “EndAvailable”, or “Route”.

 

The schema for a Offer Unsolicited Resource message can be found in Appendix A.9.

3.3.7.3 Message Flow

The Offer Unsolicited Resource message is an initial message created and sent by the Resource Supplier to any number of Resource Consumers.

The potential responses to this message include:

·         Request Information

·         Requisition Resource

·         Acknowledgement

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

3.3.7.4 Message Example

Below is an example Offer Unsolicited Resource message.  This message offers a donation of 100 large and 100 small tarpaulins.

 

[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:OfferUnsolicitedResource EDXL-RMOfferUnsolicitedResource.xsd"

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

    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">

    <MessageID>urn:au-qld-eoc:84313</MessageID>

    <SentDateTime>2006-03-22T10:34:00+10:00</SentDateTime>

    <MessageContentType>Offer Unsolicited Resource</MessageContentType>

    <MessageDescription>We would like to donate 100 small and 100 large tarps for use by residents

        whose homes have been damaged by the cyclone. </MessageDescription>

    <OriginatingMessageID>urn:au-qld-eoc:84313</OriginatingMessageID>

    <IncidentInformation>

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

    </IncidentInformation>

    <ContactInformation>

        <rm:ContactRole>Owner</rm:ContactRole>

        <rm:AdditionalContactInformation>

            <xnl:PartyName>

                <xnl:PersonName>

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

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

                </xnl:PersonName>

                <xnl:OrganisationName>

                    <xnl:NameElement>Hardware Megastore Cairns</xnl:NameElement>

                </xnl:OrganisationName>

            </xnl:PartyName>

            <xpil:Addresses>

                <xal:Address>

                    <xal:Country>

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

                    </xal:Country>

                    <xal:AdministrativeArea>

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

                    </xal:AdministrativeArea>

                    <xal:Locality>

                        <xal:Name>Cairns</xal:Name>

                    </xal:Locality>

                    <xal:Thoroughfare>

                        <xal:NameElement>Spence St</xal:NameElement>

                    </xal:Thoroughfare>

                    <xal:PostCode>

                        <xal:Identifier>4870</xal:Identifier>

                    </xal:PostCode>

                </xal:Address>

            </xpil:Addresses>

            <xpil:ContactNumbers>

                <xpil:ContactNumber xpil:MediaType="Telephone" xpil:ContactHours="8:00AM - 6:00PM">

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

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

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

                    0378</xpil:ContactNumberElement>

                </xpil:ContactNumber>

            </xpil:ContactNumbers>

        </rm:AdditionalContactInformation>

    </ContactInformation>

    <ResourceInformation>

        <SequenceNumber>001</SequenceNumber>

        <Resource>

            <TypeStructure>

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

                <rm:Value>Large tarpaulin</rm:Value>

            </TypeStructure>

            <Description> 30 x 40 ft, 800 denier blue tarp </Description>

        </Resource>

        <AssignmentInformation>

            <Quantity>100</Quantity>

            <AssignmentInstructions>

                <rm:ModeOfTransportation>We have a truck available to deliver to Innisfail (or other

                    preferred location). </rm:ModeOfTransportation>

            </AssignmentInstructions>

        </AssignmentInformation>

        <ScheduleInformation>

            <ScheduleType>BeginAvailable</ScheduleType>

            <DateTime>2006-03-22T12:00:00+10:00</DateTime>

            <Location>

                <rm:LocationDescription>Hardware Megastore Cairns</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>Cairns</xal:Name>

                    </xal:Locality>

                    <xal:Thoroughfare>

                        <xal:NameElement>Spence St</xal:NameElement>

                    </xal:Thoroughfare>

                    <xal:PostCode>

                        <xal:Identifier>4870</xal:Identifier>

                    </xal:PostCode>

                </rm:Address>

            </Location>

        </ScheduleInformation>

    </ResourceInformation>

    <ResourceInformation>

        <SequenceNumber>002</SequenceNumber>

        <Resource>

            <TypeStructure>

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

                <rm:Value>Small tarpaulin</rm:Value>

            </TypeStructure>

            <Description> 8 x 10 ft, 800 denier blue tarp </Description>

        </Resource>

        <AssignmentInformation>

            <Quantity>100</Quantity>

            <AssignmentInstructions>

                <rm:ModeOfTransportation>We have a truck available to deliver to Innisfail (or other

                    preferred location). </rm:ModeOfTransportation>

            </AssignmentInstructions>

        </AssignmentInformation>

        <ScheduleInformation>

            <ScheduleType>BeginAvailable</ScheduleType>

            <DateTime>2006-03-22T12:00:00+10:00</DateTime>

            <Location>

                <rm:LocationDescription>Hardware Megastore Cairns</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>Cairns</xal:Name>

                    </xal:Locality>

                    <xal:Thoroughfare>

                        <xal:NameElement>Spence St</xal:NameElement>

                    </xal:Thoroughfare>

                    <xal:PostCode>

                        <xal:Identifier>4870</xal:Identifier>

                    </xal:PostCode>

                </rm:Address>

            </Location>

        </ScheduleInformation>

    </ResourceInformation>

</EDXLResourceMessage>

 

3.3.8 Release Resource Message

3.3.8.1 Overview

The “Release Resouce” message is used by authorities at the incident to “release” (demobilize) a resource back to its original point of assignment or to another location / assignment.

3.3.8.2 Element Reference Model

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

 

Figure 11: EDXL-RM ERM for Release Resource Message

 

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

 

Table 12: Release 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

ResponseType, ReferenceID, ReasonCode, ResponseReason

Resource

ResourceID, Name, TypeStructure, TypeInfo, Keyword*, Description, Credentials, Certifications, SpecialRequirements, ResponsibleParty, OwnershipInformation, ResourceStatus

OwnerInformation

Owner, OwningJurisdiction, HomeDispatch, HomeUnit

ResourceStatus

DeploymentStatus, Availability

AssigmentInformation

Quantity, Restrictions, AnticipatedFunction, PriceQuote, OrderID, 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:ContactInformation, and ResourceMessage:ResourceInformation elements MUST be present.

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

·         If a ResourceMessage:IncidentInformation element is present, then at least one of IncidentInformation:IncidentID and/or IncidentInformation:IncidentDescription element 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 element MUST be present.

·         A ResourceInformation: SequenceNumber and at least one ResourceInformation:Resource elements MUST be present.

·         If the ResourceInformation:ResponseInformation element is present, then the ResponseInformation:ResponseType and ResponseInformation:ReferenceID elements MUST be present.

·         If a ResourceInformation:ResponseInformation element is present, then the ResponseInformation:OriginationSequenceNumber and ResponseInformation:ResponseType elements MUST be present.

·         If a ResourceInformation:ResponseInformation element is present and the 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 Resource:OwnerInformation is present, then at least one of OwnershipInformation:Owner and/or OwnershipInformation:OwningJurisdiction element MUST be present.

·         If the ResourceInformation:AssignmentInformation element is present, then the AssignmentInformation:Quantity element MUST be present.

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

·         New Schedule Information: “ActualReturnDeparture”

·         Carried Forward Schedule Information: “RequestedArrival”, “EstimatedArrival”, “ActualArrival”, “RequestedDeparture” , EstimatedDeparture”, “ActualDeparture”, “RequestedReturnDeparture”, “RequestedReturnArrival”, “BeginAvailable”, “EndAvailable”, “Committed”, “ReportTo”

·         New or Carried Forward Schedule Information: “EstimatedReturnDeparture”, “EstimatedReturnArrival”, or “Route”.

 

The schema for a Release Resource message can be found in Appendix A.10.

3.3.8.3 Message Flow

The Release Resource message is sent by the Resource Consumer to the Resource Supplier, and typically follows an earlier sequence of messages (e.g., Requisition Resource and Commit Resource messages).

The potential responses to this message include:

·         Request Information

·         Requisition Resource

·         Acknowledgement

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

3.3.8.4 Message Example

Below is an example Release Resource message.  This message releases the Small Animal Sheltering Team committed in the example in Section 3.3.4.4.

 

[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:ReleaseResource EDXL-RMReleaseResource.xsd"

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

    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">

    <MessageID>urn:au-qld-eoc:997985</MessageID>

    <SentDateTime>2006-03-29T10:17:00+10:00</SentDateTime>

    <MessageContentType>Release Resource</MessageContentType>

    <MessageDescription>Small Animal Sheltering Team will be flying back to Cairns this evening. </MessageDescription>

    <OriginatingMessageID>urn:au-qld-eoc:12332</OriginatingMessageID>

    <IncidentInformation>

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

    </IncidentInformation>

    <ContactInformation>

        <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>

    <ResourceInformation>

        <SequenceNumber>001</SequenceNumber>

        <Resource>

            <TypeStructure>

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

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

            </TypeStructure>

        </Resource>

        <AssignmentInformation>

            <Quantity>1</Quantity>

        </AssignmentInformation>

        <ScheduleInformation>

            <ScheduleType>Current</ScheduleType>

            <Location>

                <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>

        <ScheduleInformation>

            <ScheduleType>EstimatedReturnDeparture</ScheduleType>

            <DateTime>2006-03-29T19:05:00+10:00</DateTime>

            <Location>

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

            </Location>

        </ScheduleInformation>

        <ScheduleInformation>

            <ScheduleType>EstimatedReturnArrival</ScheduleType>

            <DateTime>2006-03-29T19:55:00+10:00</DateTime>

            <Location>

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

            </Location>

        </ScheduleInformation>

    </ResourceInformation>

</EDXLResourceMessage>

 

3.3.9 Request Return Message

3.3.9.1 Overview

The “Request Return” message is used to request release (demobilization) of resource(s) back to its original owning jurisdiction and location or to another location / assignment.

3.3.9.2 Element Reference Model

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

 

Figure 12: EDXL-RM ERM for Request Return Message

 

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

 

Table 13: Request Return 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, ResourceStatus

OwnerInformation

Owner, OwningJurisdiction, HomeDispatch, HomeUnit

ResourceStatus

DeploymentStatus, Availability

AssigmentInformation

Quantity, Restrictions, AnticipatedFunction, PriceQuote, OrderID, 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:ContactInformation, and ResourceMessage:ResourceInformation elements MUST be present.

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

·         If a ResourceMessage:IncidentInformation element is present, then at least one of IncidentInformation:IncidentID and/or IncidentInformation:IncidentDescription element 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 element 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 element MUST be present for each ResourceInformation:Resource element present.

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

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

·         Carried Forward Schedule Information: “RequestedArrival”, “EstimatedArrival”, “ActualArrival”, “RequestedDeparture”, “EstimatedDeparture”, “ActualDeparture”, “RequestedReturnDeparture”, “RequestedReturnArrival”, “BeginAvailable”, “EndAvailable”, “Committed”, “ReportTo”,

·         Either New or Carried Forward Schedule Information: “RequestedReturnDeparture”, “RequestedReturnArrival”, “EndAvailable”, or “Route”.

 

The schema for a Request Return message can be found in Appendix A.11.

3.3.9.3 Message Flow

The Release Resource message is sent by the Resource Supplier to the Resource Consumer, and typically follows an earlier sequence of messages (e.g., Requisition Resource and Commit Resource messages).

The potential responses to this message include:

·         Response to Request Return

·         This includes Accept, Decline, and any Conditional response

·         Release Resource

·         Acknowledgement

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

3.3.9.4 Message Example

Below is an example of a Request Return Message, in which one request return is shown:

·         Small Animal Sheltering Team (id=001)

 

[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:RequestReturn EDXL-RMRequestReturn.xsd"

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

    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">

    <MessageID>urn:au-qld-eoc:997821</MessageID>

    <SentDateTime>2006-03-28T14:48:00+10:00</SentDateTime>

    <MessageContentType>Request Return</MessageContentType>

    <OriginatingMessageID>urn:au-qld-eoc:12332</OriginatingMessageID>

    <IncidentInformation>

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

    </IncidentInformation>

    <ContactInformation>

        <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>

        </rm:AdditionalContactInformation>

    </ContactInformation>

    <ResourceInformation>

        <SequenceNumber>001</SequenceNumber>

        <Resource>

            <TypeStructure>

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

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

            </TypeStructure>

        </Resource>

        <AssignmentInformation>

            <Quantity>1</Quantity>

        </AssignmentInformation>

        <ScheduleInformation>

            <ScheduleType>RequestedReturnArrival</ScheduleType>

            <DateTime>2006-03-29T20:00:00+10:00</DateTime>

            <Location>

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

            </Location>

        </ScheduleInformation>

    </ResourceInformation>

</EDXLResourceMessage>

 

3.3.10 Response to Request Return Message

3.3.10.1 Overview

The “Response to Request Return” message is used by Resource Consumers to respond to a Request  Return Resource message from Resource Suppliers.  The response identifies the resources in the original request message and how the Resource Consumer has responded.

3.3.10.2 Element Reference Model

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

Figure 13: EDXL-DE ERM for Response to Request Return Message

 

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

 

Table 14: Response to Request Return 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, ResourceType, ReasonCode, ResponseReason

Resource

ResourceID, Name, TypeStructure, TypeInfo, Keyword*, Description, Credentials, Certifications, SpecialRequirements, ResponsibleParty, OwnershipInformation, ResourceStatus

OwnerInformation

Owner, OwningJurisdiction, HomeDispatch, HomeUnit

ResourceStatus

DeploymentStatus, Availability

AssigmentInformation

Quantity, Restrictions, AnticipatedFunction, PriceQuote, OrderID, 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 “ResponseToRequestReturn”.

·         If a ResourceMessage:IncidentInformation element is present, then at least one of IncidentInformation:IncidentID and/or IncidentInformation:IncidentDescription element 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 element MUST be present.

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

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

·         If the ResponseInformation:ResponseType element 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 for each ResourceInformation:Resource element present.

·         The Resource:ResourceStatus element MUST be present for each ResourceInformation:Resource element present.

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

·         The ResourceStatus:DeploymentStatus and ResourceStatus:Availability elements MUST be present.

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

·         New Schedule Information: “ActualReturnDeparture”,

·         Carried Forward Schedule Information: “RequestedArrival”, EstimatedArrival”, “ActualArrival”, “RequestedDeparture”, “EstimatedDeparture”, “ActualDeparture”, “RequestedReturnDeparture”, “RequestedReturnArrival”, “BeginAvailable”, “EndAvailable”, “Committed”, “ReportTo”

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

 

The schema for a Response to Request Return message can be found in Appendix A.12.

3.3.10.3 Message Flow

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

The potential responses to this message include:

·         Request Return

·         Acknowledgement

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

The message will typically be followed by a Release Resource message (see 3.3.8) when the Resource Consumer is ready to return the resource to the Resource Supplier.

3.3.10.4 Message Example

Below is an example of a Response to Request Return message. This is an example response to the Request Return message shown in Section 3.3.1.4.  The sender of the message is the original resource requester (Resource Consumer).  The response is an “Accept” (i.e., the Resource Consumer agrees to return the resource according to the specified schedule).

 

[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:ResponseToRequestReturn EDXL-RMResponseToRequestReturn.xsd"

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

    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">

    <MessageID>urn:au-qld-eoc:997981</MessageID>

    <SentDateTime>2006-03-28T16:17:00+10:00</SentDateTime>

    <MessageContentType>Response to Request Return</MessageContentType>

    <OriginatingMessageID>urn:au-qld-eoc:12332</OriginatingMessageID>

    <PrecedingMessageID>urn:au-qld-eoc:997821</PrecedingMessageID>

    <IncidentInformation>

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

    </IncidentInformation>

    <ContactInformation>

        <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>

        </rm:AdditionalContactInformation>

    </ContactInformation>

    <ResourceInformation>

        <SequenceNumber>001</SequenceNumber>

        <ResponseInformation>

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

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

        </ResponseInformation>

    </ResourceInformation>

</EDXLResourceMessage>

 

3.3.11 Request Quote Message

3.3.11.1 Overview

The “Request Quote” message is used by the Resource Consumer to request a price quote from the Resource Supplier.

3.3.11.2 Element Reference Model

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

Figure 14: EDXL-RM ERM for Request Quote Message

 

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

 

Table 15: Request Quote 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

Resource

ResourceID, Name, TypeStructure, TypeInfo, Keyword*, Description, Credentials, Certifications, SpecialRequirements, ResponsibleParty, OwnershipInformation

OwnerInformation

Owner, OwningJurisdiction, HomeDispatch, HomeUnit

AssigmentInformation

Quantity, Restrictions, AnticipatedFunction, 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:ContactInformation, and ResourceMessage:ResourceInformation elements MUST be present.

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

·         If a ResourceMessage:IncidentInformation element is present, then at least one of IncidentInformation:IncidentID and/or IncidentInformation:IncidentDescription element 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 element MUST be present.

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

·         If the ResourceInformation:ResponseInformation element is present, then the ResponseInformation:ResponseType and ResponseInformation:ReferenceID 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 for each ResourceInformation:Resource element present.

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

·         If the ResourceInformation:ScheduleInformation element is present, then the  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 Quote message can be found in Appendix A.13.

3.3.11.3 Message Flow

The Request Quote message is usually 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 Request Quote (See 3.3.12)

·         This includes Accept, Decline, and any Conditional response

·         Acknowledgement

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

3.3.11.4 Message Example

Below is an example Request Quote message.  This message requests quotes for a “Debris Management Team” (id=001) and two “All Terrain Cranes” (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:RequestQuote EDXL-RMRequestQuote.xsd"

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

    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">

    <MessageID>urn:au-qld-eoc:77388</MessageID>

    <SentDateTime>2006-03-30T10:45:00+10:00</SentDateTime>

    <MessageContentType>Request Quote</MessageContentType>

    <OriginatingMessageID>urn:au-qld-eoc:77388</OriginatingMessageID>

    <IncidentInformation>

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

    </IncidentInformation>

    <ContactInformation>

        <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>

    <ResourceInformation>

        <SequenceNumber>001</SequenceNumber>

        <Resource>

            <TypeStructure>

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

                <rm:Value>Debris Management Team</rm:Value>

            </TypeStructure>

            <Description>5 person team to clear roads of debris incl. fallen trees. </Description>

            <SpecialRequirements> Team to supply own equipment, such as trucks and chainsaws

            </SpecialRequirements>

        </Resource>

        <AssignmentInformation>

            <Quantity>1</Quantity>

            <AssignmentInstructions>

                <rm:ModeOfTransportation>Team's own trucks</rm:ModeOfTransportation>

            </AssignmentInstructions>

        </AssignmentInformation>

        <ScheduleInformation>

            <ScheduleType>ReportTo</ScheduleType>

            <DateTime>2006-04-01T09:00:00+10:00</DateTime>

            <Location>

                <rm:LocationDescription>Johnstone Shire Council</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>Rankin St</xal:NameElement>

                        <xal:Number>70</xal:Number>

                    </xal:Thoroughfare>

                </rm:Address>

            </Location>

        </ScheduleInformation>

        <ScheduleInformation>

            <ScheduleType>EstimatedReturnDeparture</ScheduleType>

            <DateTime>2006-04-21T09:00:00+10:00</DateTime>

        </ScheduleInformation>

    </ResourceInformation>

    <ResourceInformation>

        <SequenceNumber>002</SequenceNumber>

        <Resource>

            <TypeStructure>

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

                <rm:Value>All Terrain Crane</rm:Value>

            </TypeStructure>

            <Description> Crane with minimum boom reach of 150 feet. </Description>

        </Resource>

        <AssignmentInformation>

            <Quantity>2</Quantity>

        </AssignmentInformation>

        <ScheduleInformation>

            <ScheduleType>ReportTo</ScheduleType>

            <DateTime>2006-04-01T09:00:00+10:00</DateTime>

            <Location>

                <rm:LocationDescription>Johnstone Shire Council</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>Rankin St</xal:NameElement>

                        <xal:Number>70</xal:Number>

                    </xal:Thoroughfare>

                </rm:Address>

            </Location>

        </ScheduleInformation>

        <ScheduleInformation>

            <ScheduleType>EstimatedReturnDeparture</ScheduleType>

            <DateTime>2006-04-21T09:00:00+10:00</DateTime>

        </ScheduleInformation>

    </ResourceInformation>

</EDXLResourceMessage>

 

3.3.12 Response to Request Quote Message

3.3.12.1 Overview

The “Response to Request Quote” message is used by the Resource Supplier to respond with pricing information to a “Request Quote” message.  The Resource Supplier may provide quotes for several alternative resources that match a single resource request.

3.3.12.2 Element Reference Model

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

Figure 15: EDXL-RM ERM for Response to Request Quote Message

 

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

 

Table 16: Response to Request Quote 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,  ResourceType, ReasonCode, ResponseReason

Resource

ResourceID, Name, TypeStructure, TypeInfo, Keyword*, Description, Credentials, Certifications, SpecialRequirements, Responsible Party, 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 “ResponseToRequestQuote”.

·         If a ResourceMessage:IncidentInformation element is present, then at least one of IncidentInformation:IncidentID and/or IncidentInformation:IncidentDescription element 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 element MUST be present.

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

·         If the ResponseInformation:ResponseType has a value of “Accept” or “Conditional”, then at least one  ResourceInformation:Resource element MUST be present.

·         The ResponseInformation: OriginatingSequence and ResponseInformation:ResponseType elements MUST be present.

·         If ResponseInformation:ResponseType has a value of “Conditional”, at least one of ResponseInformation:ReasonCode and/or ResponseInformation:ResponseReason elements 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 for each ResourceInformatino:Resource element present.

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

·         If a ResourceInformation:AssignmentInformation element is present, then the AssignmentInformation:PriceQuote element MUST be present.

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

·         New Schedule Information: “EstimatedArrival”, “EstimatedDeparture”, “RequestedReturnDeparture”, “RequestedReturnArrival”, “BeginAvailable”, EndAvailable”,

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

·         New or Carried Forward Information: “Route”.

 

The schema for a Response to Request Quote message can be found in Appendix A.14.

3.3.12.3 Message Flow

The Response to Request Quote message is sent by the Resource Supplier to the Resource Consumer in response to a Request Quote message.

The potential responses to this message include:

·         Request for Information (RFI)

·         RequisitionResource

·         Acknowledgement

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

The Response to Request Quote message can potentially be followed by a Request Resource or Requisition Resource message from the Resource Consumer.

3.3.12.4 Message Example

Below is an example Response to Request Quote message.  The message is a possible response to the Request Quote message shown in Section 3.3.11.4.  The first quote request (“Debris Management Team”, idref=001) is accepted, while the second (“All Terrain Crane”, id=002) is declined.

 

[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:ResponseToRequestQuote EDXL-RMResponseToRequestQuote.xsd"

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

    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">

    <MessageID>urn:au-qld-eoc:77396</MessageID>

    <SentDateTime>2006-03-28T14:48:00+10:00</SentDateTime>

    <MessageContentType>Response to Request Quote</MessageContentType>

    <MessageDescription>This message provides a quote for the services of a debris management team

        for the requested period of 3 weeks. We do not have any all-terrain cranes, and therefore

        are unable to quote on this part of the request. </MessageDescription>

    <OriginatingMessageID>urn:au-qld-eoc:77388</OriginatingMessageID>

    <PrecedingMessageID>urn:au-qld-eoc:77388</PrecedingMessageID>

    <IncidentInformation>

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

    </IncidentInformation>

    <ContactInformation>

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

        <rm:AdditionalContactInformation>

            <xnl:PartyName>

                <xnl:PersonName>

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

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

                </xnl:PersonName>

                <xnl:OrganisationName>

                    <xnl:NameElement>QBuild</xnl:NameElement>

                </xnl:OrganisationName>

            </xnl:PartyName>

        </rm:AdditionalContactInformation>

    </ContactInformation>

    <ContactInformation>

        <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>

        </rm:AdditionalContactInformation>

    </ContactInformation>

    <ResourceInformation>

        <SequenceNumber>001</SequenceNumber>

        <ResponseInformation>

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

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

        </ResponseInformation>

        <Resource>

            <TypeStructure>

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

                <rm:Value>Debris Management Team</rm:Value>

            </TypeStructure>

            <Description>5 person team to clear roads of debris incl. fallen trees. </Description>

            <SpecialRequirements> Team to supply own equipment, such as trucks and chainsaws

            </SpecialRequirements>

        </Resource>

        <AssignmentInformation>

            <Quantity>1</Quantity>

            <PriceQuote>

                Daily rate: $2100

                Total before tax: $31500

                Tax: $3150

                Total including tax: $34650

                NOTES: Accommodation for the team will be organised and paid by us. Team will

                work Mon-Fri for 3 weeks. </PriceQuote>

        </AssignmentInformation>

        <ScheduleInformation>

            <ScheduleType>BeginAvailable</ScheduleType>

            <DateTime>2006-03-31T15:00:00+10:00</DateTime>

        </ScheduleInformation>

        <ScheduleInformation>

            <ScheduleType>ReportTo</ScheduleType>

            <DateTime>2006-04-01T09:00:00+10:00</DateTime>

            <Location>

                <rm:LocationDescription>Johnstone Shire Council</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>Rankin St</xal:NameElement>

                        <xal:Number>70</xal:Number>

                    </xal:Thoroughfare>

                </rm:Address>

            </Location>

        </ScheduleInformation>

        <ScheduleInformation>

            <ScheduleType>EstimatedReturnDeparture</ScheduleType>

            <DateTime>2006-04-21T09:00:00+10:00</DateTime>

        </ScheduleInformation>

    </ResourceInformation>

    <ResourceInformation>

        <SequenceNumber>002</SequenceNumber>

        <ResponseInformation>

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

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

        </ResponseInformation>

    </ResourceInformation>

</EDXLResourceMessage>

 

3.3.13 Request Resource Deployment Status Message

3.3.13.1 Overview

The “Request Resource Deployment Status” message is used to request the current status of one or more deployed resources. It can be sent by the Resource Supplier to the Resource Consumer (e.g., to check the status of the resource after a “Release Resource” message) or by the Resource Consumer to the Resource Supplier (e.g., to track the progress of a resource after a “Requisition Resource” message).

3.3.13.2 Element Reference Model

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

Figure 16: EDXL-RM ERM for Request Resource Deployment Status Message

 

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

 

Table 17: Resource Deployment Status 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, Responsible Party, OwnershipInformation

OwnerInformation

Owner, OwningJurisdiction, HomeDispatch, HomeUnit

AssigmentInformation

Quantity, Restrictions, AnticipatedFunction, PriceQuote, OrderID, 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:ContactInformation, and ResourceMessage:ResourceInformation elements MUST be present.

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

·         If a ResourceMessage:IncidentInformation element is present, then at least one of IncidentInformation:IncidentID and/or IncidentInformation:IncidentDescription element 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 element 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 element MUST be present for each ResourceInformation:Resource element present.

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

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

·         Carried Forward Schedule Information: “RequestedArrival”, “EstimatedArrival”, “ActualArrival”, “RequestedDeparture”, “EstimatedDeparture”, “ActualDeparture”, “RequestedReturnDeparture”, “EstimatedReturnDeparture”, “ActualReturnDeparture”, “RequestedReturnArrival”, “EstimatedReturnArrival”, “ActualReturnArrival”, “BeginAvailable”, EndAvailable”, “Committed”, “ReportTo”, or “Route”.

 

The schema for a Request Resource Deployment Status message can be found in Appendix A.15.

3.3.13.3 Message Flow

The Request Resource Deployment Status message can be sent from the Resource Supplier to the Resource Consumer, or from the Resource Consumer to the Resource Supplier, any time after a resource is requisitioned or committed.

The potential responses to this message include:

·         Report Resource Deployment Status

·         Acknowledgement

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

3.3.13.4  Message Example

Below is an example Request Resource Deployment Status message.  This message requests the deployment status of the “Small Animal Sheltering Team”; it follows on from the example Commit message in Section 3.3.4.4, and precedes the Release Resource message in Section 3.3.8.4.

 

[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:RequestResourceDeploymentStatus EDXL-RMRequestResourceDeploymentStatus.xsd"

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

    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">

    <MessageID>urn:au-qld-eoc:997958</MessageID>

    <SentDateTime>2006-03-25T09:05:00+10:00</SentDateTime>

    <MessageContentType>Request Resource Deployment Status</MessageContentType>

    <OriginatingMessageID>urn:au-qld-eoc:12332</OriginatingMessageID>

    <IncidentInformation>

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

    </IncidentInformation>

    <ContactInformation>

        <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>

        </rm:AdditionalContactInformation>

    </ContactInformation>

    <ResourceInformation>

        <SequenceNumber>001</SequenceNumber>

        <Resource>

            <TypeStructure>

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

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

            </TypeStructure>

        </Resource>

        <AssignmentInformation>

            <Quantity>1</Quantity>

        </AssignmentInformation>

        <ScheduleInformation>

            <ScheduleType>EstimatedArrival</ScheduleType>

            <DateTime>2006-03-25T09:30:00+10:00</DateTime>

            <Location>

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

            </Location>

        </ScheduleInformation>

        <ScheduleInformation>

            <ScheduleType>EstimatedReturnDeparture</ScheduleType>

            <DateTime>2006-03-30T17:00:00+10:00</DateTime>

        </ScheduleInformation>

        <ScheduleInformation>

            <ScheduleType>Committed</ScheduleType>

            <DateTime>2006-03-21T12:46:00+10:00</DateTime>

        </ScheduleInformation>

    </ResourceInformation>

</EDXLResourceMessage>

 

3.3.14 Report Resource Deployment Status Message

3.3.14.1 Overview

The “Report Resource Deployment Status” message is used to report on the current status of any deployed resource.  The message can be sent from the Resource Supplier to the Resource Consumer, or from the Resource Consumer to the Resource Supplier.

3.3.14.2 Element Reference Model

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

Figure 17: EDXL-RM ERM for Report Resource Deployment Status Message

 

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

 

Table 18: Report Resource Deployment Status 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, ResourceType, ReasonCode, ResponseReason

Resource

ResourceID, Name, TypeStructure, TypeInfo, Keyword*, Description, Credentials, Certifications, SpecialRequirements, Responsible Party, OwnershipInformation, ResourceStatus

OwnerInformation

Owner, OwningJurisdiction, HomeDispatch, HomeUnit

ResourceStatus

InventoryRefreshDateTime, DeploymentStatus, Availability

AssigmentInformation

Quantity, Restrictions, AnticipatedFunction, PriceQuote, OrderID, 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:ContactInformation, and ResourceMessage:ResourceInformation elements MUST be present.

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

·         If a ResourceMessage:IncidentInformation element is present, then at least one of IncidentInformation:IncidentID and/or IncidentInformation:IncidentDescription element 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 element MUST be present.

·         If the ResourceInformation:ResponseInformation element is present, the ResponseInformation:ResponseType and ResponseInformatino:ReferenceID elements MUST be present.

·         If the ResponseInformation:ResponseType element has a value of “Conditional”, at least one of ResponseInformation:ReasonCode and/or ResponseInformation:ResponseReason elements 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 for each ResourceInformation:Resource element present.

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

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

·         Either New or Carried Forward Schedule Information: “RequestedArrival”, “EstimatedArrival”, “ActualArrival”, “RequestedDeparture”, “EstimatedDeparture”, “ActualDeparture”, “RequestedReturnDeparture”, “EstimatedReturnDeparture”, “ActualReturnDeparture”, “RequestedReturnArrival”, “EstimatedReturnArrival”, “ActualReturnArrival”, “BeginAvailable”, EndAvailable”, “Committed”, “ReportTo”, or “Route”.

 

The schema for a Report Resource Deployment Status message can be found in Appendix A.16.

3.3.14.3 Message Flow

The Report Resource Deployment Status message can be sent from the Resource Supplier to the Resource Consumer, or from the Resource Consumer to the Resource Supplier, any time after a resource is requisitioned or committed.  The message MAY be sent in response to an earlier Request Resource Deployment Status message.

The potential responses to this message include:

·         Acknowledgement

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

3.3.14.4 Message Example

Below is an example Report Resource Deployment Status message.  This message shows a possible response to the Request Resource Deployment Status message in Section Error! Reference source not found..

 

[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:ReportResourceDeploymentStatus EDXL-RMReportResourceDeploymentStatus.xsd"

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

    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">

    <MessageID>urn:au-qld-eoc:997967</MessageID>

    <SentDateTime>2006-03-25T09:16:00+10:00</SentDateTime>

    <MessageContentType>Report Resource Deployment Status</MessageContentType>

    <OriginatingMessageID>urn:au-qld-eoc:12332</OriginatingMessageID>

    <PrecedingMessageID>urn:au-qld-eoc:997958</PrecedingMessageID>

    <IncidentInformation>

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

    </IncidentInformation>

    <ContactInformation>

        <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>

        </rm:AdditionalContactInformation>

    </ContactInformation>

    <ContactInformation>

        <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>

        </rm:AdditionalContactInformation>

    </ContactInformation>

    <ResourceInformation>

        <SequenceNumber>001</SequenceNumber>

        <ResponseInformation>

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

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

        </ResponseInformation>

        <Resource>

            <TypeStructure>

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

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

            </TypeStructure>

            <ResourceStatus>

                <DeploymentStatus>

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

                    <rm:Value>In Transit</rm:Value>

                </DeploymentStatus>

            </ResourceStatus>

        </Resource>

        <AssignmentInformation>

            <Quantity>1</Quantity>

        </AssignmentInformation>

        <ScheduleInformation>

            <ScheduleType>ActualDeparture</ScheduleType>

            <DateTime>2006-03-25T08:20:00+10:00</DateTime>

            <Location>

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

            </Location>

        </ScheduleInformation>

        <ScheduleInformation>

            <ScheduleType>ActualArrival</ScheduleType>

            <DateTime>2006-03-25T09:00:00+10:00</DateTime>

            <Location>

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

            </Location>

        </ScheduleInformation>

        <ScheduleInformation>

            <ScheduleType>EstimatedArrival</ScheduleType>

            <DateTime>2006-03-25T09:40:00+10:00</DateTime>

            <Location>

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

            </Location>

        </ScheduleInformation>

    </ResourceInformation>

</EDXLResourceMessage>

 

3.3.15 Request Extended Deployment Duration

3.3.15.1 Overview

The “Request Extended Deployment Duration” message is sent by the Resource Consumer to the Resource Supplier when the Consumer wishes to retain one or more resources longer than previously agreed (e.g., in the orginial Requisition Resource and Commit Resource messages).

3.3.15.2 Element Reference Model

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

Figure 18: EDXL-RM ERM for Request Extended Deployment Duration Message

 

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

 

Table 19: Request Extended Deployment Duration Message Elements

Parent Element

Sub-Elements

ResourceMessage

MessageID, SentDateTime, MessageContentType^, OriginatingMessageID, MessageDescription, 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, Responsible Party, OwnershipInformation, ResourceStatus

OwnerInformation

Owner, OwningJurisdiction, HomeDispatch, HomeUnit

ResourceStatus

DeploymentStatus, Availability

AssignmentInformation

Quantity, Restriction, AnticipatedFunction, PriceQuote, OrderID

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 “RequestExtendedDeploymentDuration”.

·         If a ResourceMessage:IncidentInformation element is present, then at least one of IncidentInformation:IncidentID and/or IncidentInformation:IncidentDescription element 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 element 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 element MUST be present for each ResourceInformation:Resource elements present for each ResourceInformation:Resource element.

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

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

·         Carried Forward Schedule Information: “RequestedArrival”, “EstimatedArrival”, “ActualArrival”, “RequestedDeparture”, “EstimatedDeparture”, “ActualDeparture”, “RequestedReturnArrival”, “Committed”, “ReportTo”,

·         Either New or Carried Forward Schedule Information: “RequestedReturnDeparture”, “EstimatedReturnDeparture”,  “EstimatedReturnArrival”, or “Route”.

 

The schema for a Request Extended Deployment Duration message can be found in Appendix A.17.

3.3.15.3 Message Flow

The Request Extended Deployment Duration message is sent from the Resource Consumer to the Resource Supplier after the Commit Resource message and prior to the Release Resource message. 

The potential responses to this message include:

·         Response to Request Extended Deployment Duration (see 3.3.16)

·         This includes Accept, Decline and Conditional responses

·         Acknowledgement

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

3.3.15.4 Message Example

Below is an example Request Extended Deployment Duration message.  This message follows on from the Commit Resource message in Section 3.3.4.4 and preceeds the Request Return and Release Resource messages in Sections 3.3.9.4 and 3.3.8.4 respectively.

 

[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:RequestExtendedDeploymentDuration EDXL-RMRequestExtendedDeploymentDuration.xsd"

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

    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">

    <MessageID>urn:au-qld-eoc:997814</MessageID>

    <SentDateTime>2006-03-22T16:38:00+10:00</SentDateTime>

    <MessageContentType>Request Extended Deployment Duration</MessageContentType>

    <OriginatingMessageID>urn:au-qld-eoc:12332</OriginatingMessageID>

    <IncidentInformation>

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

    </IncidentInformation>

    <ContactInformation>

        <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>

        </rm:AdditionalContactInformation>

    </ContactInformation>

    <ResourceInformation>

        <SequenceNumber>001</SequenceNumber>

        <Resource>

            <TypeStructure>

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

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

            </TypeStructure>

        </Resource>

        <AssignmentInformation>

            <Quantity>1</Quantity>

        </AssignmentInformation>

        <ScheduleInformation>

            <ScheduleType>RequestedReturnArrival</ScheduleType>

            <DateTime>2006-04-07T17:00:00+10:00</DateTime>

            <Location>

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

            </Location>

        </ScheduleInformation>

    </ResourceInformation>

</EDXLResourceMessage>

 

3.3.16 Response to Request Extended Deployment Duration Message

3.3.16.1 Overview

The “Response to Request Extended Deployment Duration” message is used as the response to a “Request Extended Deployment Duration”. It allows the sender to accept, decline, or offer conditions upon which deployment duration of resources may be extended.

3.3.16.2 Element Reference Model

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

Figure 19: EDXL-RM ERM Response to Request Extended Deployment Duration  Message

 

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

 

Table 20: Response to Request Extended Deployment Duration 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

Resource

ResourceID, Name, TypeStructure, TypeInfo, Keyword*, Description, Credentials, Certifications, SpecialRequirements, OwnershipInformation, ResourceStatus

OwnerInformation

Owner, OwningJurisdiction, HomeDispatch, HomeUnit

ResourceStatus

DeploymentStatus, Availability

AssigmentInformation

Quantity, Restrictions, AnticipatedFunction, PriceQuote, OrderID, 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 “ResponseToRequestExtendedDeploymentDuration”.

·         If a ResourceMessage:IncidentInformation element is present, then at least one of IncidentInformation:IncidentID and/or IncidentInformation:IncidentDescription element 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 element MUST be present.

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

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

·         If the ResponseElement:ResponseType element has a value of “Accept” or “Conditional”, then at least one ResourceInformation.Resource element MUST be present. Otherwise, the ResourceInformation.Resource element is optional.

·         If ResponseInformation:ResponseType has a value of “Conditional”, at least one of ResponseInformation:ReasonCode and/or ResponseInformation:ResponseReason elements 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 a Resource:OwnerInformation is present, then at least one of OwnershipInformation:Owner and/or OwnershipInformation:OwningJurisdiction element MUST be present.

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

·         New Schedule Information: “EndAvailable”,

·         Carried Forward Schedule Information: “RequestedArrival”, “EstimatedArrival”, “ActualArrival”, “RequestedDeparture”, “EstimatedDeparture”, “ActualDeparture”, “RequestedReturnDeparture”,

·         Either New or Carried Forward Schedule Information: “EstimatedReturnDeparture”, “RequestedReturnArrival”, “EstimatedReturnArrival”, “Committed”, “ReportTo”, or “Route”.

 

The schema for a Response to Request Extended Deployment Duration message can be found in Appendix A.18.

3.3.16.3 Message Flow

The Response to Request Extended Deployment Duration message is sent from the Resource Supplier to the Resource Consumer in response to a Request Extended Deployment Duration message. 

The potential responses to this message include:

·         Acknowledgement (See ??)

3.3.16.4 Message Example

Below is an example Resonse to Request Extended Deployment Duration message.  This message follows on from the example Request Extended Deployment Duration message shown in Section 3.3.15.4 (declining the request).

 

[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:ResponseToRequestExtendedDeploymentDuration EDXL-RMResponseToRequestExtendedDeploymentDuration.xsd"

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

    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">

    <MessageID>urn:au-qld-eoc:997816</MessageID>

    <SentDateTime>2006-03-22T17:02:00+10:00</SentDateTime>

    <MessageContentType>Response to Request Extended Deployment Duration</MessageContentType>

    <OriginatingMessageID>urn:au-qld-eoc:12332</OriginatingMessageID>

    <PrecedingMessageID>urn:au-qld-eoc:997814</PrecedingMessageID>

    <IncidentInformation>

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

    </IncidentInformation>

    <ContactInformation>

        <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>

        </rm:AdditionalContactInformation>

    </ContactInformation>

    <ContactInformation>

        <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>

        </rm:AdditionalContactInformation>

    </ContactInformation>

    <ResourceInformation>

        <SequenceNumber>001</SequenceNumber>

        <ResponseInformation>

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

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

            <rm:ResponseReason>Team is already committed elsewhere for the period of 4 to 7 April.</rm:ResponseReason>

        </ResponseInformation>

        <Resource>

            <TypeStructure>

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

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

            </TypeStructure>

        </Resource>

        <AssignmentInformation>

            <Quantity>1</Quantity>

        </AssignmentInformation>

        <ScheduleInformation>

            <ScheduleType>RequestedReturnArrival</ScheduleType>

            <DateTime>2006-04-07T17:00:00+10:00</DateTime>

            <Location>

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

            </Location>

        </ScheduleInformation>

    </ResourceInformation>

</EDXLResourceMessage>

 

4        Data Dictionary (NORMATIVE)

4.1.1 ResourceMessage Element

Element

MessageID

Type

xsd:string [Identified in the RMCommonTypes schema as MessageIDType]

Usage

REQUIRED, MUST be used once and only once

Definition

Each EDXL resource message contains an identifier that uniquely identifies each resource message.

Comments

·         The EDXL Distribution Element contains the "Distribution ID", which identifies the "container" for the distribution message information.

Requirements

 Supported

20

 

Element

SentDateTime

Type

xsd:dateTime [Identified in the RMCommonTypes schema as DateTimeType]

Usage

REQUIRED, MUST be used once and only once

Definition

The system stamped date and time the resource message was sent.  (1) The date and time is represented in [dateTime] format (e. g., "2002-05-24T16:49:00-07:00" for 24 May 2002 at 16: 49 PDT).  (2) Alphabetic timezone designators such

as “Z” MUST NOT be used. The timezone for UTC MUST be represented as “-00:00”

or “+00:00.

Comments

  • Original requirement = ICS "Request Date/Time"

Requirements

 Supported

21

 

Element

MessageContentType

Type

xsd:string enumeration  [Identified in the RMCommonTypes schema as MessageContentTypeType]

Usage

REQUIRED, MUST be used once and only once

Definition

Specifies the purpose / type of resource content / payload being sent within the Resource Reference Model

Comments

  • Value must be one of the following: 

1.       Request Resource

2.       Response to Request Resource

3.       Requisition Resource

4.       Commit Resource

5.       Request Information

6.       Response to Request Information

7.       Offer Unsolicited Resource

8.       Release Resource

9.       Request Return

10.   Request Quote

11.   Response to Request Return

12.   Response to Request Quote

13.   Request Resource Deployment Status

14.   Report Resource Deployment Status

15.   Request Extended Deployment Duration

16.   Response to Request Extended Deployment Duration

Requirements

 Supported

2,3,4,5,6,7,8,9,10,11,12,17

 

Element

MessageDescription

Type

xsd:string [Identified in the RMCommonTypes schema as MessageDescriptionType]

Usage

CONDITIONAL, MAY be used once and only once

Definition

Text field used to specify the information requested in a request for information and the response to a request for information. May also be used to include additional information in other message types.

Comments

  • Conditional Usage:
    • Required:
      • ResourceMessage:MessageContentType = “Request Information”
    • Optional:
      • Otherwise

Requirements

 Supported

20

 

Element

OriginatingMessageID

Type

xsd:string [Identified in the RMCommonTypes schema as MessageIDType]

Usage

REQUIRED, MUST be used once and only once

Definition

Each EDXL resource message contains a MessageID that uniquely identifies each resource message. InitialMessageID identifies the MessageID of the first message in the sequence to which the message belongs.  If the message is itself the initial message in a new sequence, InitialMessageID will have the same value as the MessageID element. In some other cases, the InitialMessageID element will have the same value as the OriginatingMessageID element.  The InitialMessageID value essentially forms a unique identifier for a group of related messages, linking them together so that the relationship between the messages is made explicit and unambiguous (and threads of messages can be tracked by resource management software).

Comments

  • This Message ID is an EDXL-RM Message ID, not an EDXL-Distribution Element Message ID.
  • The OriginatingMessageID of an originating message will be the MessageID of that message.

 

Requirements Supported

20

 

Element

PrecedingMessageID

Type

xsd:string [Identified in the RMCommonTypes schema as MessageIDType]

Usage

CONDITIONAL, MAY be used once and only once

Definition

Each EDXL resource message contains a MessageID that uniquely identifies each resource message. OriginatingMessageID identifies the MessageID of the original message to which this message refers. This element is most commonly used in Response messages to refer back to the corresponding Request message. This Message ID is an EDXL-RM Message ID, not an EDXL-Distribution Element Message ID.

Comments

  • The PrecedingMessageID of an originating message will be the MessageID of that message.
  • Conditional Usage:
    • Required:
      •  ResourceMessage:MessageContentType = “Response To Request Resource”
      • ResourceMessage:MessageContentType = “Commit Resource”
      • ResourceMessage:MessageContentType = “Response to Request Information”
      • ResourceMessage:MessageContentType = “Response to Request Return”
      • ResourceMessage:MessageContentType = “Response to Request Quote”
      • ResourceMessage:MessageContentType = “Response to Request Extended Deployment Duration”
    • Optional:
      • ResourceMessage:MessageContentType = “Requisition Resource”
      • ResourceMessage:MessageContentType = “Request for Information”
      • ResourceMessage:MessageContentType = “Release Resource”
      • ResourceMessage:MessageContentType = “Request Return”
      • ResourceMessage:MessageContentType = “Request Quote”
      • ResourceMessage:MessageContentType = “Request Resource Deployment Status”
      • ResourceMessage:MessageContentType = “Report Resource Deployment Status”
    • Not Applicable:
      • Otherwise

Requirements Supported

 

 

Element

ContactInformation

Type

XML structure [Identified in the RMCommonTypes schema as ContactInformationType]

Usage

REQUIRED, MUST be used at least once

Definition

The contact associated with the resource message.

Comments

 

Requirements Supported

 

4.1.2 IncidentInformation Element

Element

IncidentID

Type

xsd:string [Identified in the RMCommonTypes schema as IncidentIDType]

Usage

CONDITIONAL, MAY be used once and only once. 

Definition

The name or other identifer of the incident to which the current message refers.

Comments

§         If an IncidentInformation element is present, then at least one of IncidentInformation:IncidentID or IncidentInformation:IncidentDescription MUST be present

Requirements Supported

19

 

Element

IncidentDescription

Type

xsd:string [Identified in the RMCommonTypes schema as IncidentDescriptionType]

Usage

CONDITIONAL, MAY be used once and only once. 

Definition

A free form description of the incident to which the current message refers.

Comments

§         If an IncidentInformation element is present, then at least one of IncidentInformation:IncidentID or IncidentInformation:IncidentDescription MUST be present

Requirements Supported

19

4.1.3 MessageRecall Element

Element

RecalledMessageID

Type

xsd:string [Identified in the RMCommonTypes schema as MessageIDType]

Usage

REQUIRED, MAY be used once and only once. 

Definition

The identifer of the previously sent message that is to be recalled.  MessageRecall is used to replace a previously sent message by updating or canceling it.

Comments

§         The MessageRecall element is Optional.

Requirements Supported

14, 15

 

Element

RecallType

Type

xsd:string enumeration [Identified in the RMCommonTypes as an element within RecallTypeType]

Usage

REQUIRED, MAY be used once and only once. 

Definition

Specifies the recall type as either an update or a cancel of the previously sent message.  MessageRecall is used to replace a previously sent message which is then updated or cancelled.

Comments

§         The Message Recall element is Optional.

§         Value must be one of the following:

1.       Update

2.       Cancel

 

Requirements Supported

14,15

4.1.4 Funding Element

Element

FundCode

Type

xsd:string [Identified in the RMCommonTypes schema as FundCodeType]

Usage

CONDITIONAL, MAY be used once and only once. 

Definition

Identifies the funds that will pay for the resource

Comments

  • The Funding element is Required ONLY in a Requisition Resource message. 
  • If a funding element is present, then at least one of Funding:FundCode or Funding:FundingInfo MUST be present
  • Identified in support of NIMS Resource Management Guide NIC-GDL0004
  • This field may be used as a comma separated list of fund codes (e.g. “HP4347,RT45S”

Requirements Supported

18,24

 

Element

FundingInfo

Type

xsd:string [Identified in the RMCommonTypes schema as FundingInfoType]

Usage

CONDITIONAL, MAY be used once and only once. 

Definition

Provides additional information on the funds that will pay for the resource

Comments

  • A textual description of funding sources or distribution
  • The Funding element is Required ONLY in a Requisition Resource message. 
  • If a funding element is present, then at least one of Funding:FundCode or Funding:FundingInfo MUST be present

Requirements Supported

18, 24

4.1.5 ResourceInformation Element

Element

SequenceNumber

Type

xsd:string [Identified in the RMCommonTypes schema as SequenceNumberType]

Usage

REQUIRED, MUST be used once and only once

Definition

This element identifies the instance of ResourceInformation within the message. It does not identify the Resource.

Comments

  • The purpose of this element is to uniquely identify the ResourceInformation element in future messages that refer to this message.
  • The Resource is identified by a combination of one or more of ResourceID, Name and/or ResourceTypeStructure.

Requirements Supported

 

4.1.6 ResponseInformation Element

Element

PrecedingSequenceNumber

Type

xsd:string [Identified in the RMCommonTypes schema as SequenceNumberType]

Usage

REQUIRED, MUST be used once and only once

Definition

This element identifies the instance of ResourceInformation within the message specified in the ResourceMessage:OriginatingMessageID element.

Comments

  •  

Requirements Supported

 

 

Element

ResponseType

Type

xsd:string enumeration [Identified in the RMCommonTypes schema as ResponseTypeType]

Usage

REQUIRED, MUST be used once and only once

Definition

Used to accept or decline a Request, Response, Unsolicited Offer, or a Request Return.  "Decline" indicates the request, response or offer is not accepted. “Conditional” means that the request is accepted pending certain specified conditions.

Comments

·         The “ResponseReason” is associated with a “decline” value.

·         Value must be one of the following:

1.       Accept

2.       Decline

3.       Conditional

Requirements Supported

6,29

 

Element

ReasonCode

Type

ValueListUrnType [Identified in the RMCommonTypes schema as ReasonCodeType]

Usage

CONDITIONAL, MAY be used once and only once

Definition

Code from a managed list that offers an explanation for a declined or conditional response to a Request, Response, Unsolicited Offer, or a Request Return.

Comments

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

Requirements Supported

6,29

 

Element

ResponseReason

Type

xsd:string [Identified in the RMCommonTypes schema as ResponseReasonType]

Usage

CONDITIONAL, MAY be used once and only once

Definition

Explanation for a declined or conditional response to a Request, Response, Unsolicited Offer, or a Request Return.

Comments

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

Requirements Supported

6,29

4.1.7 Resource Element

Element

ResourceID

Type

xsd:string [Identified in the RMCommonTypes schema as ResourceIDType]

Usage

CONDITIONAL, MAY be used once and only once. 

Definition

This identifier (if available) is used to identify and track.a resource. 

Comments

  • At least one of Resource:ResourceID, Resource:Name or Resource:TypeStructure MUST be present and used throughout a exchange of messages.
  • May be selected via the <Resource Keyword> if available.

Requirements Supported

3,16,26

 

Element

Name

Type

xsd:string [Identified in the RMCommonTypes schema as ResourceNameType]

Usage

CONDITIONAL, MAY be used once and only once. 

Definition

A name or title of the resource used for identification and tracking.

Comments

  • At least one of Resource:ResourceID, Resource:Name or Resource:TypeStructure MUST be present and used throughout a exchange of messages.
  • May be selected via the <ResourceKeyword> if available.

Requirements Supported

3,16,18,26

 

Element

TypeStructure

Type

ValueListType [Identified in the RMCommonTypes schema as TypeStructureType]

Usage

CONDITIONAL, MAY be used once and only once

Definition

Uniform Resource Name of a certified list of resources maintained by the Community of Interest (COI) for the value referenced.  Facilitates link to ARMS and other managed lists

Comments

  • At least one of Resource:ResourceID, Resource:Name or Resource:TypeStructure MUST be contained in each Resource element present.

 

Requirements Supported

3,16,25, 26

 

Element

TypeInfo

Type

xsd: schema [Identified in the RMCommonTypes schema as TypeInfoType]

Usage

OPTIONAL, MAY be used once and only once

Definition

The resource type as defined by either a Keyword structure or a validatable schema.

Comments

§         This is xsd:any in the TypeInfoType that is dependent on the value of TypeStructure above.

Requirements Supported

3,16,25,26

 

Element

Keyword

Type

ValueListType [Identified in the RMCommonTypes schema as KeywordType]

Usage

OPTIONAL, MAY be used one to many

Definition

Any value from a discrete managed list, used to specify a keyword.

Comments

  • Allows reference to a separate schema for enumerations.  Example:  valueListUrn= "http://www.dhs.gov/NiemEquipmentResources" and value="Portable Radio",
    or valueListUrn= "http://www.eic.org/Package" and value="DMAT – burn"

Requirements Supported

3,16,25,26

 

Element

Description

Type

xsd:string [Identified in the RMCommonTypes schema as DescriptionType]

Usage

OPTIONAL, MAY be used once and only once

Definition

Free Text description of resource or resource characteristics, situation requiring resource assistance, or statement of mission resource must satisfy.

Comments

  •  

Requirements Supported

3,7,16,18,26

 

Element

Credentials

Type

xsd:string [Identified in the RMCommonTypes schema as CredentialsType]

Usage

OPTIONAL, MAY be used once and only once

Definition

Statements of resource qualifications showing that a person or role has a right to exercise official power

Comments

  •  

Requirements Supported

 

 

Element

Certifications

Type

xsd:string [Identified in the RMCommonTypes schema as CertificationsType]

Usage

OPTIONAL, MAY be used once and only once

Definition

Statements of recognition that a resource has met specia requirements orl qualifications within a field

Comments

  •  

Requirements Supported

 

 

Element

SpecialRequirements

Type

xsd:string [Identified in the RMCommonTypes schema as SpecialRequirementsType]

Usage

OPTIONAL, MAY be used once and only once

Definition

A description of any special needs related to the requested resource (e.g. must carry protective equipment)

Comments

  • Not intended to carry certifications or capabilities.

Requirements Supported

3,7,16,27

 

Element

ResponsibleParty

Type

XML Structure [Identified in the RMCommonTypes schema as ContactInformationType.]

Usage

CONDITIONAL, MAY be used once and only once

Definition

Contact Info for person currently responsible for resource

Comments

§         Conditional Usage:

o        Not Applicable:

§         ResourceMessage:MessageContentType = “Request Resource”

o        Optional, otherwise

Requirements Supported

3,7,16,27

4.1.8 OwnershipInformation Element

Element

Owner

Type

xsd:string [Identified in the RMCommonTypes schema as OwnerType]

Usage

CONDITIONAL, MAY be used once and only once

Definition

The name of an agency or supplier that owns the resource (which may not be the home unit or dispatch).  Also referred to as home agency.

 

Comments

  • At least one of OwnershipInformation:Owner or OwnershipInformation:OwningJurisdiction each OwnershipInformation element.

Requirements Supported

3,16,18

 

Element

OwningJurisdiction

Type

xsd:string [Identified in the RMCommonTypes schema as OwningJurisdictionType]

Usage

CONDITIONAL, MAY be used once and only once

Definition

A geopolitical area in which an organization, person, or object has a specific range of authority for specified resources.

Comments

  • At least one of OwnershipInformation:Owner or OwnershipInformation:OwningJurisdiction each OwnershipInformation element.
  • Can be a code

Requirements Supported

3, 16, 18

 

Element

HomeDispatch

Type

xsd:string [Identified in the RMCommonTypes schema as HomeDispatchType]

Usage

CONDITIONAL, MAY be used once and only once

Definition

Resource home agency dispatch center name.  This identifies the dispatch unit that has primary responsibility for maintaining information on the resource (e.g., Ft. Collins Dispatch Center, Rocky Mountain Area Coordination Center). 

Comments

§         Conditional Usage:

o        Not Applicable:

§         ResourceMessage:MessageContentType = “Request Resource”

      • Optional, otherwise

Requirements Supported

18

 

Element

HomeUnit

Type

xsd:string [Identified in the RMCommonTypes schema as HomeUnitType]

Usage

OPTIONAL, MAY be used once and only once

Definition

The unit (office, district, organization, etc.) from which the resource typically works or is used (e.g., Manti-Lasal National Forest/Sanpete District).  When released from an assignment, the location to which the resource is released will usually be determined by the home unit.

Comments

§         Conditional Usage:

o        Not Applicable:

§         ResourceMessage:MessageContentType = “Request Resource”

o        Optional, otherwise

Requirements Supported

18

4.1.9 ResourceStatus Element

Element

InventoryRefreshDateTime

Type

xsd:dateTime [Identified in the RMCommonTypes schema as InventoryRefreshDateTimeType]

Usage

CONDITIONAL, MAY be used once and only once

Definition

Date and time that resource inventory counts were last updated

Comments

§         Conditional Usage:

o        Optional:

§         ResourceMessage:MessageContentType = “Response to Request Resource”

§         ResourceMessage:MessageContentType = “Commit Resource”

§         ResourceMessage:MessageContentType = “Request Information”

§         ResourceMessage:MessageContentType = “Response to Request Information”

§         ResourceMessage:MessageContentType = “Offer Unsolicited Resource”

§         ResourceMessage:MessageContentType = “Response to Request Quote”

§         ResourceMessage:MessageContentType = “Report Resource Deployment Status”

o        Not Applicable, otherwise

Requirements Supported

2,12’

 

Element

DeploymentStatus

Type

ValueListType [Identified in the RMCommonTypes schema as DeploymentStatusType]

Usage

CONDITIONAL, MAY be used once and only once

Definition

Any value from a discrete managed list, used to specify the general state of a resource if known.

Comments

§         Conditional Usage:

o        Required

§         ResourceMessage:MessageContentType = “Response to Request Return”

o        Optional:

§         ResourceMessage:MessageContentType = “Response to Request Resource”

§         ResourceMessage:MessageContentType = “Commit Resource”

§         ResourceMessage:MessageContentType = “Request Information”

§         ResourceMessage:MessageContentType = “Response to Request Information”

§         ResourceMessage:MessageContentType = “Offer Unsolicited Resource”

§         ResourceMessage:MessageContentType = “Release Resource”

§         ResourceMessage:MessageContentType = “Request Return”

§         ResourceMessage:MessageContentType = “Response to Request Quote”

§         ResourceMessage:MessageContentType = “Report Resource Deployment Status”

§         ResourceMessage:MessageContentType = “Request Extended Deployment Duration”

§         ResourceMessage:MessageContentType = “Response to Request Extended Deployment Duration”

o        Not Applicable, otherwise

·         Allows reference to a separate schema for enumerations.  Example:  valueListUrn= "http://www.dhs.gov/NIMSResourceStatus" and value="Available”.  Example values include:

o        atBase-available

o        enroute-Unavailable

o        on-scene-unavailable

o        returning-unavailable

o        Resource maintenance

o        Out of Service

o        Depleted

o        Available

o        Committed

o        In transit

o        At incident (ROSS)

o        Assigned

o        In Camp

o        Reassignment

o        Return transit

o        Returned

o        Demobilized

o        Etc.

 

Requirements Supported

18

 

Element

Availability

Type

xsd:string [Identified in the RMCommonTypes schema as AvailabilityType]

Usage

CONDITIONAL, MAY be used once and only once

Definition

Text to describe availability and limitations on availability.  Resource availability refers to resource that it is present or ready for immediate use,or otherwise accessable or obtainable, or is qualified or willing to do something or to assume a responsibility. 

Comments

§         Conditional Usage:

o        Required

§         ResourceMessage:MessageContentType = “Response to Request Return”

o        Optional:

§         ResourceMessage:MessageContentType = “Response to Request Resource”

§         ResourceMessage:MessageContentType = “Request Information”

§         ResourceMessage:MessageContentType = “Response to Request Information”

§         ResourceMessage:MessageContentType = “Offer Unsolicited Resource”

§         ResourceMessage:MessageContentType = “Release Resource”

§         ResourceMessage:MessageContentType = “Request Return”

§         ResourceMessage:MessageContentType = “Response to Request Quote”

§         ResourceMessage:MessageContentType = “Report Resource Deployment Status”

§         ResourceMessage:MessageContentType = “Request Extended Deployment Duration”

§         ResourceMessage:MessageContentType = “Response to Request Extended Deployment Duration”

o        Not Applicable, otherwise

Requirements Supported

3,16

 

4.1.10 AssignmentInformation Element

Element

Quantity

Type

xsd:string [Identified in the RMCommonTypes schema as QuantityType]

Usage

CONDITIONAL, MAY be used once and only once

Definition

Description of amount of resource needed in both quantity and units of measure.

Comments

·         Value must be non-negative.

·         Conditional Usage:

o        Required

§         ResourceMessage:MessageContentType = “Response to Request Resource” and ResponseInformation:ResponseType = “Accept”

§         ResourceMessage:MessageContentType = “Response to Request Resource” and ResponseInformation:ResponseType = “Conditional”

§         ResourceMessage:MessageContentType = “Requisition Resource”

§         ResourceMessage:MessageContentType = “Commit Resource”

§         ResourceMessage:MessageContentType = “Release Resource”

o        Optional, otherwise.

Requirements Supported

3,16,18,26

 

Element

Restrictions

Type

xsd:string [Identified in the RMCommonTypes schema as RestrictionsType]

Usage

OPTIONAL, MAY be used one to many

Definition

Description of a condition governing the availability of resources.  E.g. condition for number of beds available may be "if patents have insurance".  This may be thought of as a term/condition or a restriction on availability.

Comments

§          

Requirements Supported

28

 

Element

AnticipatedFunction

Type

xsd:string [Identified in the RMCommonTypes schema as AnticipatedFunctionType]

Usage

OPTIONAL, MAY be used once and only once

Definition

Anticipated function, task, job, or role to be provided by the requested resource.

Comments

§          

 

Requirements Supported

18,28

 

Element

PriceQuote [Identified in the RMCommonTypes schema as PriceQuoteType]

Type

xsd:string

Usage

CONDITIONAL, MAY be used once and only once

Definition

Description of quoted cost to acquire desired resource including currency, if the distinction is appropriate. 

Comments

  •  
  • Completed in response to a “Request Quote”
  • Conditional Usage:
    • Required
      • ResourceMessage:MessageContentType = “Response to Request Quote”
    • Not Applicable
      • ResourceMessage:MessageContentType = “Request Resource”
      • ResourceMessage:MessageContentType = “Request Quote”
    • Optional, otherwise

Requirements Supported

10,30

 

Element

OrderID

Type

xsd:string [Identified in the RMCommonTypes schema as OrderIDType]

Usage

CONDITIONAL, MAY be used once and only once

Definition

Reference to the external system number or ID assigned by the ordering system or personnel meeting the request for resources that has been made.

Comments

  •  
  • There is no assurance of uniqueness between various external systems.
  • Conditional Usage:
    • Optional
      • ResourceMessage:MessageContentType = “Commit Resource”
      • ResourceMessage:MessageContentType = “Request Information”
      • ResourceMessage:MessageContentType = “Response to Request Information”
      • ResourceMessage:MessageContentType = “Release Resource”
      • ResourceMessage:MessageContentType = “Request Return”
      • ResourceMessage:MessageContentType = “Response to Request Return”
      • ResourceMessage:MessageContentType = “Request Resource Deployment Status”
      • ResourceMessage:MessageContentType = “Report Resource Deployment Status”
      • ResourceMessage:MessageContentType = “Request Extended Deployment Duration”
      • ResourceMessage:MessageContentType = “Response to Request Extended Deployment Duration”
    • Not Applicable, otherwise

Requirements Supported

18,30

4.1.11 AssignmentInstructions Element

Element

ModeOfTransportation

Type

xsd:string [Identified in the RMCommonTypes schema as ModeOfTransportationType]

Usage

CONDITIONAL, MAY be used once and only once

Definition

Method or mode used to transport the resource to or from the incident.

Comments

  • Conditional Usage:
    • Not Applicable
      • ResourceMessage:MessageContentType = “Request Resource”
      • ResourceMessage:MessageContentType = “Request Extended Deployment Duration”
    • Optional, otherwise

Requirements Supported

18,30

 

Element

NavigationInstructions

Type

xsd:string [Identified in the RMCommonTypes schema as NavigationInstructionsType]

Usage

CONDITIONAL, MAY be used once and only once

Definition

Instructions that define how to get to the “report to location”

Comments

  • Conditional Usage:
    • Not Applicable
      • ResourceMessage:MessageContentType = “Request Resource”
      • ResourceMessage:MessageContentType = “Request Extended Deployment Duration”
    • Optional, otherwise

Requirements Supported

28

 

Element

ReportingInstructions

Type

xsd:string [Identified in the RMCommonTypes schema as ReportingInstructionsType]

Usage

CONDITIONAL, MAY be used once and only once

Definition

The name of the party that the requested item is to report to when they arrive at the incident.

Comments

  • Conditional Usage:
    • Not Applicable
      • ResourceMessage:MessageContentType = “Request Resource”
      • ResourceMessage:MessageContentType = “Request Extended Deployment Duration”
    • Optional, otherwise

Requirements Supported

30

4.1.12 ScheduleInformation Element

Element

ScheduleType

Type

xsd:string enumeration [Identified in the RMCommonTypes schema as ScheduleTypeType]

Usage

REQUIRED, MUST be used once and only once

Definition

A scheduled event that occurs at a particular time and/or at a particular location.

Comments

  • Value must be one of the following: 

1.       ResourceRequestedArrivalDateTime

§         When the resource is needed.  Completed for Resource requests, returns, etc.

§         ICS uses the term "delivery" vs. "arrival".  “Arrival" used here because this applies to Human Resources also

2.       ResourceEstimatedDepartureDateTime

§         When the resource is expected to depart from its current location for transit to a “Report-to Location”

3.       ResourceActualDepartureDateTime

§         Actual date and time when the resource departs from its current location for transit to a “Report To Location”.  

4.       ResourceEstimatedArrivalDateTime

§         When the resource is expected to arrive at its “Report To Location”.

5.       Committed

§         When specified resource is committed to a request or requisition.  Completed in response to a resource request message.  Specified resource is no longer available to be applied to other resource requests

§         “Dispatch” is a commitment of resources in the Distribution Element

6.       ResourceActualArrivalDateTime

§         Actual date and time of arrival of the resource a “Report To Location”.

7.       ResourceEstimatedDepartureDateTime

§         When the resource is expected to depart from its current location for transit to a “Report-to Location”

8.       ResourceEstimatedArrivalDateTime

§         When the resource is expected to arrive at its “Report To Location”.

9.       ResourceActualDepartureDateTime

§         Actual date and time when the resource departs from its current location for transit to a “Report To Location”.  

10.   ResourceActualArrivalDateTime

§         Actual date and time of arrival of the resource a “Report To Location”.  

11.   ResourceAnticipatedReturnDateTime

§         When the resource is expected to be returned or demobilized.  Completed for a “Request Resource”.  This element with the “Requested Arrival Date / Time” provides the estimated duration of resource deployment.

Requirements Supported

2, 11, 12, 28, 30

 

Element

DateTime

Type

xsd:dateTime [Identified in the RMCommonTypes schema as DateTimeType]

Usage

OPTIONAL, MAY be used once and only once

Definition

The date and time that a scheduled event takes place.

Comments

·          

Requirements Supported

2, 11, 12, 28, 30

 

Element

Location

Type

XML structure [Identified in the RMCommonTypes schema as LocationType]

Usage

OPTIONAL, MAY be used once and only once

Definition

The location in which a scheduled event takes place.

Comments

·          

Requirements Supported

 

4.1.13 Supporting Element Types

4.1.13.1 ContactInformationType

 

Element

ContactDescription

Type

xsd:string [Identified in the RMCommonTypes schema as ContactDescriptionType]

Usage

CONDITIONAL, MAY be used once and only once. 

Definition

Description of the contact associated with the resource message.

Comments

§         If a ContactInformation element is present, then at least one of ContactInformation:ContactDescription or ContactInformation:ContactRole MUST be present

Requirements Supported

18,23,24

 

Element

ContactRole

Type

xsd:string enumeration [Identified in the RMCommonTypes schema as ContactRoleType]

Usage

CONDITIONAL, MAY be used once and only once. 

Definition

Role of the contact associated with the resource message.

Comments

  • If a ContactInformation element is present, then at least one of ContactInformation:ContactDescription or ContactInformation:ContactRole MUST be present
  • Value must be one of the following:

1.       "Sender" (who sent the message)

2.       ”Requester" (authorization for the message / request)

3.       "Subject Matter Expert" (answer questions or provide details)

4.       "Approver"

5.       "RespondingOrg" (who responded to the message)

6.       “Owner”

Requirements Supported

18,23,24

 

Element

ContactLocation

Type

XML Structure [Identified in the RMCommonTypes schema as LocationType]

Usage

OPTIONAL, MAY be used once and only once. 

Definition

The geophysical location of the contact.

Comments

 

Requirements Supported

18,23,24

 

Element

AdditionalContactInformation

Type

xpil:PartyType [Identified in the RMCommonTypes schema as AdditionalContactInformationType]

Usage

OPTIONAL, MAY be used once and only once. 

Definition

Any other contact information including name and other party information.

Comments

  • .

Requirements Supported

18,23,24

4.1.13.1.1 Radio Element

Element

RadioType

Type

xsd:string [Identified in the RMCommonTypes schema as RadioTypeType]

Usage

REQUIRED, Must be used once and only once

Definition

Contact radio type of the person or organization referred to in ContactRole

Comments

§         .

Requirements Supported

18,23

 

Element

RadioChannel

Type

xsd:string [Identified in the RMCommonTypes schema as RadioChannelType]

Usage

REQUIRED, MUST be used once and only once

Definition

Contact radio channel of the person or organization referred to in ContactRole

Comments

§         “Channel” and “Frequency” are synonyms for purposes of this standard

Requirements Supported

18,23

4.1.13.2 LocationType

Element

LocationDescription

Type

 xsd:string [Identified in the RMCommonTypes schema as LocationDescriptionType]

Usage

CONDITIONAL, MAY be used once and only once. 

Definition

A free-form textual description of a location.

Comments

  • At least one of the Description, Address or TargetArea elements must be present.

Requirements Supported

 

 

Element

Address

Type

 xal:AddressType [Identified in the RMCommonTypes schema as AddressType]

Usage

CONDITIONAL, MAY be used zero to many. 

Definition

The identifier of an explicit address.

Comments

§         At least one of the Description, Address or TargetArea elements must be present.

Requirements Supported

 

 

Element

TargetArea

Type

geo-oasis:WhereType [Identified in the RMCommonTypes schema as TargetAreaType]

Usage

CONDITIONAL, MAY be used once and only once. 

Definition

The container element for location information. This element is structured to import the specific “WhereType” from the proprosed geo:oasis GML specification.  It allows the target Area to be defined a choice that includes:

  • Point – WGS84 lat long
  • Line – a series of points
  • Circle  - a point and radius
  • Polygon – a set of connected non-crossing points
  • Envelope – two points used to define a bounding rectangle

It also allows the use of a set of attributes defined for “WhereType.” More detailed definitions for geo-oasis:WhereType and its components can be found in the geo:oasis proposed specification. Specific usage of those types for RM are found in the section “Imported Type Definitions” below.

Comments

§         At least one of the Description, ExplicitAddress or TargetArea elements must be present.

Requirements Supported

§          

4.1.13.2.1 Imported Type Definitions

Type

geo-oasis:WhereType

Usage

Used for as the type value for TargetArea elements

Definition

WhereType provides a mechanism for defining location.  It allows the target Area to be defined as a choice of one of the following:

  • gml:Point
  • gml:LineString
  • gml:CircleByCenterPoint
  • gml:Ploygon
  • gml:Envelope

It also allows the use of a set of attributes (oasis:whereAttrGroup) defined for “WhereType.” More detailed definitions for geo:oasis:WhereType can be found in the geo:oasis proposed specification

Comments

§         Specific usage structures for the choices above to be used in the RM specification are found in definitions included later in this section.

§         Use of the oasis:whereAttrGroup is not covered by this standard. While oasis:whereAttrGroup can be used, its particular use should  be regarded as a proprietary extension of the Resource Messaging standard, meaning that an understanding of its use cannot be guaranteed by implementation instances of the standard.

 

Requirements Supported

§          

 

Type

geo-oasis:WhereType using GML:Point

Usage

Where TargetAreaType is best represented as a WGS84 point.

Definition

The use of gml:Point within TargetArea provides location using a specific WGS-84 point value that is compatible with compatible with GML compliant geospatial information systems.  The following example applies:

    <oasis:where>
         <gml:Point>
            <gml:pos>45.256 -71.92</gml:pos>
         </gml:Point>
      </oasis:where>

More detailed definitions for geo:oasis:WhereType can be found in the geo:oasis proposed specification.

Comments

§         The geo-oasis proposal offers the use of an attribute within the Point tag to indicate an alternate Coordinate Reference System (other than WGS-84). The Resource Messaging Standard requires the use of WGS-84 only.

 

Requirements Supported

§          

 

Type

geo-oasis:WhereType using GML:LineString

Usage

Where TargetAreaType is best represented as a route along a series of WGS84 points.

Definition

The use of gml:LineString within TargetArea provides location along a line represented by a specific list of WGS-84 point values that is compatible with GML compliant geospatial information systems.  The following example applies:

<oasis:where>
      <gml:LineString>
         <gml:posList>
            45.256 -110.45 46.46 -109.48 43.84 -109.86
         </gml:posList>
      </gml:LineString>
   </oasis:where >

More detailed definitions for geo:oasis:WhereType can be found in the geo:oasis proposed specification.

Comments

§         The geo-oasis proposal offers the use of an attribute within the Point tag to indicate an alternate Coordinate Reference System (other than WGS-84). The Resource Messaging Standard requires the use of WGS-84 only.

 

Requirements Supported

§