Emergency Data Exchange Language Resource Messaging (EDXL-RM)
1.0
Committee Specification 01
14 September 2008
Specification URIs:
This Version:
http://docs.oasis-open.org/emergency/edxl-rm/v1.0/cs01/EDXL-RM-v1.0-CS01.doc
(Authoritative)
http://docs.oasis-open.org/emergency/edxl-rm/v1.0/cs01/EDXL-RM-v1.0-CS01.pdf
http://docs.oasis-open.org/emergency/edxl-rm/v1.0/cs01/EDXL-RM-v1.0-CS01.html
Previous
Version:
http://docs.oasis-open.org/emergency/edxl-rm/v1.0/pr03/EDXL-RM-v1.0-PR03.pdf
http://docs.oasis-open.org/emergency/edxl-rm/v1.0/pr03/EDXL-RM-v1.0-PR03.html
Latest Version:
http://docs.oasis-open.org/emergency/edxl-rm/v1.0/EDXL-RM-SPEC-V1.0.doc
http://docs.oasis-open.org/emergency/edxl-rm/v1.0/EDXL-RM-SPEC-V1.0.pdf
http://docs.oasis-open.org/emergency/edxl-rm/v1.0/EDXL-RM-SPEC-V1.0.html
Technical Committee:
Emergency Management
Chair(s):
Elysa Jones, Warning Systems, Inc.
Editor(s):
Dr. Patti Aymond, Individual
Rex Brooks, Individual
Tim Grapes, DHS Disaster Management Interoperability
Service
Gary Ham, Individual
Dr. Renato Iannella, National
ICT Australia (NICTA)
Dr. Karen Robinson, National ICT Australia (NICTA)
Werner Joerg, IEM, Inc
Alessandro Triglia, OSS Nokalva, Inc
Related work:
This specification is related to:
·
Emergency Data Exchange Language (EDXL) Distribution
Element, v. 1.0
Declared XML Namespace(s):
urn:oasis:names:tc:emergency:EDXL:RM:1.0
urn:oasis:names:tc:emergency:EDXL:RM:1.0:Reference
urn:oasis:names:tc:emergency:EDXL:RM:1.0:RequestResource
urn:oasis:names:tc:emergency:EDXL:RM:1.0:ResponseToRequestResource
urn:oasis:names:tc:emergency:EDXL:RM:1.0:RequisitionResource
urn:oasis:names:tc:emergency:EDXL:RM:1.0:CommitResource
urn:oasis:names:tc:emergency:EDXL:RM:1.0:RequestInformation
urn:oasis:names:tc:emergency:EDXL:RM:1.0:ResponseToRequestInformation
urn:oasis:names:tc:emergency:EDXL:RM:1.0:OfferUnsolicitedResource
urn:oasis:names:tc:emergency:EDXL:RM:1.0:ReleaseResource
urn:oasis:names:tc:emergency:EDXL:RM:1.0:RequestReturn
urn:oasis:names:tc:emergency:EDXL:RM:1.0:ResponseToRequestReturn
urn:oasis:names:tc:emergency:EDXL:RM:1.0:RequestQuote
urn:oasis:names:tc:emergency:EDXL:RM:1.0:ResponseToRequestQuote
urn:oasis:names:tc:emergency:EDXL:RM:1.0:RequestResourceDeploymentStatus
urn:oasis:names:tc:emergency:EDXL:RM:1.0:ReportResourceDeploymentStatus
urn:oasis:names:tc:emergency:EDXL:RM:1.0:RequestExtendedDeploymentDuration
urn:oasis:names:tc:emergency:EDXL:RM:1.0:ResponseToRequestExtendedDeploymentDuration
Abstract:
This XML-based
Emergency Data Exchange Language (EDXL) Resource Messaging specification
describes a suite of standard messages for data sharing among emergency and
other information systems that deal in requesting and providing emergency
equipment, supplies, people and teams. This format may be used over any data
transmission system, including but not limited to the SOAP HTTP binding.
Status:
This document was last revised or approved by the Emergency
Management Technical Committee on the above date. The level of approval is also
listed above. Check the current location noted above for possible later
revisions of this document.
Technical Committee members should send comments on this
specification to the Technical Committee’s email list. Others should send
comments to the Technical Committee by using the “Send A Comment” button on the
Emergency Management TC web page at http://www.oasis-open.org/committees/emergency/.
For information on whether any patents have been disclosed
that may be essential to implementing this specification, and any offers of
patent licensing terms, please refer to the Intellectual Property Rights
section of the Technical Committee web page at http://www.oasis-open.org/committees/emergency/ipr.php
The non-normative errata page for this specification is
located at http://www.oasis-open.org/committees/emergency/.
Copyright © OASIS® 1993–2007.
All capitalized terms in the following text have the
meanings assigned to them in the OASIS Intellectual Property Rights Policy (the
"OASIS IPR Policy"). The full Policy may be found at the OASIS
website.
This document and translations of it may be copied and
furnished to others, and derivative works that comment on or otherwise explain
it or assist in its implementation may be prepared, copied, published, and
distributed, in whole or in part, without restriction of any kind, provided
that the above copyright notice and this section are included on all such
copies and derivative works. However, this document itself may not be modified
in any way, including by removing the copyright notice or references to OASIS,
except as needed for the purpose of developing any document or deliverable
produced by an OASIS Technical Committee (in which case the rules applicable to
copyrights, as set forth in the OASIS IPR Policy, must be followed) or as
required to translate it into languages other than English.
The limited permissions granted above are perpetual and will
not be revoked by OASIS or its successors or assigns.
This document and the information contained herein is
provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
OASIS requests that any OASIS Party or any other Party that
believes it has patent claims that would necessarily be infringed by
implementations of this OASIS Committee Specification or OASIS Standard, to
notify OASIS TC Administrator and provide an indication of its willingness to
grant patent licenses to such patent claims in a manner consistent with the IPR
Mode of the OASIS Technical Committee that produced this specification.
OASIS invites any Party to contact the OASIS TC
Administrator if it is aware of a claim of ownership of any patent claims that
would necessarily be infringed by implementations of this specification by a
patent holder that is not willing to provide a license to such patent claims in
a manner consistent with the IPR Mode of the OASIS Technical Committee that
produced this specification. OASIS may include such claims on its website, but
disclaims any obligation to do so.
OASIS takes no position regarding the validity or scope of
any intellectual property or other rights that might be claimed to pertain to
the implementation or use of the technology described in this document or the
extent to which any license under such rights might or might not be available;
neither does it represent that it has made any effort to identify any such
rights. Information on OASIS' procedures with respect to rights in any document
or deliverable produced by an OASIS Technical Committee can be found on the
OASIS website. Copies of claims of rights made available for publication and
any assurances of licenses to be made available, or the result of an attempt
made to obtain a general license or permission for the use of such proprietary
rights by implementers or users of this OASIS Committee Specification or OASIS
Standard, can be obtained from the OASIS TC Administrator. OASIS makes no
representation that any information or list of intellectual property rights
will at any time be complete, or that any claims in such list are, in fact,
Essential Claims.
The names "OASIS", “Emergency Data Exchange
Language,” “Emergency Data Exchange Language Distribution Element,” “Emergency
Data Exchange Language Hospital Availability Exchange,” “Emergency Data
Exchange Language Resource Messaging,” “EDXL,” “EDXL-DE,” “EDXL-HAVE” and “EDXL-RM”
are trademarks of OASIS, the owner and developer of this specification, and
should be used only to refer to the organization and its official outputs.
OASIS welcomes reference to, and implementation and use of, specifications,
while reserving the right to enforce its marks against misleading uses. Please
see http://www.oasis-open.org/who/trademark.php
for above guidance.
1 Introduction.. 8
1.1 Purpose. 8
1.2 History. 8
1.3 Structure of the EDXL Resource Message. 9
1.4 Terminology. 10
1.5 Normative References. 10
1.6 Non-Normative References. 11
2 Design
Principles and Concepts (non-normative) 12
2.1 Requirements for Design.. 12
2.2 Distribution of EDXL-RM.. 13
2.2.1 EDXL DISTRIBUTION ELEMENT (EDXL-DE) 13
2.2.2 EDXL RESOURCE MESSAGING (EDXL-RM) DISTRIBUTION.. 13
2.3 Example Usage Scenarios. 13
2.3.1 Safecom Explosion.. 14
2.3.2 Cedar Fire Incident 14
2.3.3 Hurricane. 15
2.3.4 Pandemic Influenza. 15
3 EDXL
Resource Messaging Model (Normative unless otherwise stated) 16
3.1 Abstract Reference Model
(Non-Normative) 16
3.2 Element Reference Model 18
3.3 Resource Message Types. 18
3.4 RequestResource Message. 25
3.4.1 Overview.. 25
3.4.2 Element Reference Model 25
3.4.3 RequestResource Message Rules. 26
3.4.4 Message Flow.. 27
3.4.5 Message Example. 27
3.5 ResponseToRequestResource Message. 30
3.5.1 Overview.. 30
3.5.2 Element Reference Model 30
3.5.3 ResponseToRequestResource Message Rules. 31
3.5.4 Message Flow.. 32
3.5.5 Message Example. 32
3.6 RequisitionResource Message. 35
3.6.1 Overview.. 35
3.6.2 Element Reference Model 35
3.6.3 RequisitionResource Message Rules. 36
3.6.4 Message Flow.. 37
3.6.5 Message Example. 37
3.7 CommitResource Message. 40
3.7.1 Overview.. 40
3.7.2 Element Reference Model 40
3.7.3 CommitResource Message Rules. 41
3.7.4 Message Flow.. 42
3.7.5 Message Example. 42
3.8 RequestInformation Message. 45
3.8.1 Overview.. 45
3.8.2 Element Reference Model 45
3.8.3 RequestInformation Message rules. 46
3.8.4 Message Flow.. 47
3.8.5 Message Example. 47
3.9 ResponseToRequestInformation Message. 49
3.9.1 Overview.. 49
3.9.2 Element Reference Model 49
3.9.3 ResponseToRequestInformation Message Rules. 50
3.9.4 Message Flow.. 51
3.9.5 Message Example. 52
3.10 OfferUnsolicitedResource Message. 55
3.10.1 Overview.. 55
3.10.2 Element Reference Model 55
3.10.3 OfferUnsolicitedResource Message Rules. 56
3.10.4 Message Flow.. 57
3.10.5 Message Example. 57
3.11 ReleaseResource Message. 60
3.11.1 Overview.. 60
3.11.2 Element Reference Model 60
3.11.3 ReleaseResource Message Rules. 61
3.11.4 Message Flow.. 62
3.11.5 Message Example. 62
3.12 RequestReturn Message. 65
3.12.1 Overview.. 65
3.12.2 Element Reference Model 65
3.12.3 RequestReturn Message Rules. 66
3.12.4 Message Flow.. 67
3.12.5 Message Example. 67
3.13 ResponseToRequestReturn Message. 69
3.13.1 Overview.. 69
3.13.2 Element Reference Model 69
3.13.3 ResponseToRequestReturn Message Rules. 70
3.13.4 Message Flow.. 71
3.13.5 Message Example. 71
3.14 RequestQuote Message. 73
3.14.1 Overview.. 73
3.14.2 Element Reference Model 73
3.14.3 RequestQuote Message Rules. 74
3.14.4 Message Flow.. 75
3.14.5 Message Example. 75
3.15 ResponseToRequestQuote Message. 78
3.15.1 Overview.. 78
3.15.2 Element Reference Model 78
3.15.3 ResponseToRequestQuote Message Rules. 79
3.15.4 Message Flow.. 80
3.15.5 Message Example. 80
3.16 RequestResourceDeploymentStatus
Message. 83
3.16.1 Overview.. 83
3.16.2 Element Reference Model 83
3.16.3 RequestResourceDeploymentStatus Message Rules. 84
3.16.4 Message Flow.. 85
3.16.5 Message Example. 85
3.17 ReportResourceDeploymentStatus Message. 87
3.17.1 Overview.. 87
3.17.2 Element Reference Model 87
3.17.3 ReportResourceDeploymentStatus Message Rules. 88
3.17.4 Message Flow.. 89
3.17.5 Message Example. 89
3.18 RequestExtendedDeploymentDuration.. 92
3.18.1 Overview.. 92
3.18.2 Element Reference Model 92
3.18.3 RequestExtendedDeploymentDuration Message Rules. 93
3.18.4 Message Flow.. 94
3.18.5 Message Example. 94
3.19
ResponseToRequestExtendedDeploymentDuration Message. 96
3.19.1 Overview.. 96
3.19.2 Element Reference Model 96
3.19.3 ResponseToRequestExtendedDeploymentDuration
Message Rules. 97
3.19.4 Message Flow.. 98
3.19.5 Message Example. 98
4 Data
Dictionary (NORMATIVE) 101
4.1.1 EDXLResourceMessage
ElementReferenceType Type. 101
4.1.2 IncidentInformation Element 104
4.1.3 MessageRecall Element 105
4.1.4 Funding Element 106
4.1.5 ResourceInformation Element 107
4.1.6 ResponseInformation Element 107
4.1.7 Resource Element 108
4.1.8 OwnershipInformation Element 112
4.1.9 ResourceStatus Element 114
4.1.10 AssignmentInformation Element 117
4.1.11 AssignmentInstructions Element 120
4.1.12 ScheduleInformation Element 122
4.1.13 Supporting Element Types. 124
4.1.13.1 ContactInformationType. 124
4.1.13.1.1 Radio Element 127
4.1.13.2 LocationType. 127
4.1.13.2.1 Imported Type Definitions. 128
4.1.13.3 ValueListType. 131
5 Conformance.. 133
5.1 Conformance Targets. 133
5.2 Conformance Levels. 133
5.3 Conformance as an EDXL-RM Message. 134
5.3.1 Level-1 EDXL-RM Message. 134
5.3.2 Level-2 EDXL-RM Message. 134
5.4 Conformance as an EDXL-RM Message Producer. 135
5.4.1 Level-1 EDXL-RM Message Producer. 135
5.4.2 Level-2 EDXL-RM Message Producer. 135
A. XML
Schema for the EDXL Resource Messaging (NORMATIVE) 136
A.1 Resource Messaging Common Types. 136
A.2 Resource Messaging Reference Schema. 140
A.3 RequestResource Message Schema. 142
A.4 ResponseToRequestResource Message
Schema. 144
A.5 RequisitionResource Message Schema. 146
A.6 CommitResource Message Schema. 147
A.7 RequestInformation Message Schema. 149
A.8 ResponseToRequestInformation Message
Schema. 151
A.9 OfferUnsolicitedResource Message Schema. 153
A.10 ReleaseResource Message Schema. 155
A.11 RequestReturn Message Schema. 157
A.12 ResponseToRequestReturn Message Schema. 159
A.13 RequestQuote Message Schema. 161
A.14 ResponseToRequestQuote Message Schema. 162
A.15 RequestResourceDeploymentStatus
Message Schema. 164
A.16 ReportResourceDeploymentStatus Message
Schema. 166
A.17 Request Extended Deployment Duration
Message Schema. 169
A.18
ResponseToRequestExtendedDeploymentDuration Message Schema. 171
A.19 Acknowledgements. 173
B. Revision History.. 174
As detailed in the EDXL-DE Specification, the
goal of the EDXL project is to facilitate emergency information sharing and
data exchange across the local, state, tribal, national and non-governmental
organizations of different professions that provide emergency response and
management services. EDXL will accomplish this goal by focusing on the standardization
of specific messages (messaging interfaces) to facilitate emergency
communication and coordination particularly when more than one profession or
governmental jurisdiction is involved.
The primary purpose of the Emergency Data
Exchange Language Resource Messaging (EDXL-RM) Specification is to provide a
set of standard formats for XML emergency response messages. These Resource
Messages are specifically designed as payloads of Emergency Data Exchange
Language Distribution Element- (EDXL-DE)-routed messages. Together EDXL-DE and EDXL-RM
are intended to expedite all activities associated with resources needed to
respond and adapt to emergency incidents. The Distribution Element may be
thought of as a "container". It provides the information to route
"payload" message sets (such as Alerts or Resource Messages), by
including key routing information such as distribution type, geography,
incident, and sender/recipient IDs.
The Resource Message is constrained to the set
of Resource Message Types contained in this specification. The Resource Message
is intended to be the payload or one of the payloads of the Distribution
Element which contains it.
Disaster Management (DM) is a communications program in the
Department of Homeland Security’s (DHS) Office for Interoperability and
Compatibility (OIC) and managed by the Science and Technology (S&T)
Directorate. The program was initiated as one of the President’s e-government
initiatives. DM’s mission is to serve as the program within the Federal
Government to help local, tribal, state, and federal public safety and
emergency response agencies improve public safety response through more
effective and efficient interoperable data sharing. The DHS DM program sponsors
a Practitioner Steering Group (PSG).
The DM Practitioner Steering Group (PSG) governance was
formalized following publication of the EDXL Distribution Element. It plays a
key role in the direction, prioritization, definition, and execution of the DHS-DM
program. The group is comprised of representatives of major emergency response
associations, setting priorities and providing recommendations regarding messaging
standards development as well as the other facets of the DM program.
The PSG specified messaging standards-based
systems interoperability as the top priority for the DHS Disaster Management
program. The EDXL Resource Messaging Specification effort was identified
as the top priority standard by this group following the EDXL-DE. The
requirements and specification effort was initiated by this group in partnership
with industry members of the Emergency Interoperability
Consortium (EIC) in a Standards Working Group (SWG). That group developed a
draft specification which was submitted to the OASIS Emergency Management
Technical Committee to begin work on this EDXL-RM specification.
The process remained the same as with the EDXL-DE
specification with the exception that the Technical Committee requested that
the initial candidate specification submitted by the expert group be recast as
a formal Requirements Document according to a template that the Technical
Committee provided to the expert group. The candidate specification was then
resubmitted along with this requested requirements document.
As stated in Section 1.1, the EDXL Resource Message specification defines
16 separate and specific message types supporting the major communication requirements
for allocation of resources across the emergency incident life-cycle. This
includes preparedness, pre-staging of resources, initial and ongoing response,
recovery and demobilization / release of resources.
The EDXL Resource Message structure is defined
using successively more detailed or constrained artifacts in the form of
diagrams, figures and tables. The overall structure of the EDXL Resource
Message is first represented in a reference model referred to as the
Element Reference Model (ERM). This overall model is the foundation from which
individual constraint schemas (individual resource message types) are
defined. The ERM (Section 3.2) with
the Data Dictionary (Section 4)
defines the overall structure of Resource Messages including message structure
(element cardinality), message element definitions and cardinality which must
be adhered to. An overall XML schema is also provided for the ERM.
Following overall Resource Message definition,
each individual EDXL Resource Message type is defined. Table 2 provides a matrix defining required, optional and conditional message
elements for each EDXL Resource Message. A section is then provided for each
individual EDXL Resource Message (each message constrains the overall
ERM or reference model), providing the normative ERM, element cardinality and
optionality, business rules and message flow that defines each individual
message type. Message XML and example XML is also provided for each message.
The following descriptions of these artifacts
are here only as preparation to better understand how to use these diagrams,
figures and tables
The non-normative Abstract Reference Model
diagram in Figure 1 shows the abstract structural
relationships of the main components or elements. The normative ERM diagram in Figure 2 shows the structural relationships of the main Resource
Messaging elements. Elements are logical groupings of message elements
for purposes of defining message structure
- The EDXLResourceMessage element
itself is the top level element of this specification as a whole, and
contains the message elements that identify and describe the message with
information such as ID, DateTime, ContactInformation, MessageDescription
and previous message references;
- An IncidentInformation element identifies
and describes the incident with which the message is concerned;
- A MessageRecall element is needed when
a message updates or cancels a previous message;
- A Funding element specifies
applicable codes and specific funding information;
- A ResourceInformation element specifies
the resource information or resource requirement. The
ResourceInformation element contains:
- A Resource element to
identify and describe the specific resource or resources with which the
message is concerned, such as ID, Name, Type and Description.
The Resource element contains the following additional elements:
i. An OwnershipInformation element; and,
ii. A ResourceStatus element.
- A ResponseInformation element that
identifies the Resource to which it applies, specifies the ResponseType
such as Accept or Decline, a ResponseCode and ResponseReason;
- An AssignmentInformation element to
specify information such as Quantity, PriceQuote and OrderID.
The AssignmentInformation element includes:
i. An AssignmentInstructions element for specifying ModeOfTransportation,
NavigationInstructions and ReportingInstructions; and,
- A ScheduleInformation element to
specify a ScheduleType, such as RequestedArrival, RequestedDeparture,
ActualArrival and Actual Departure, as well as DateTime
and Location;
- A ContactInformation element is
organized separately to be reused in Resource Message Elements as needed,
and it reuses the OASIS Customer Information Quality Specifications;
- A LocationType element is organized
separately to be used in Resource Message elements as needed, using the
geo-oasis:WhereType;
- A ValueListType element is organized and
specified separately to be used in Resource Message elements as needed.
Table 1 provides a Resource Message Type
Summary of the 16 specific types of Resource Message. This is useful for
getting a quick overview of the message types contained in the specification.
Figure 3 illustrates the three primary types
of behavior which Resource Messages enable:
·
Discovery;
·
Ordering; and
·
Deployment.
Table 2 provides a Resource Message Type – Element Matrix
where each row represents a specific message element grouped by element group and
each column represents a specific message type. Using this matrix, one can
determine whether any combination of message element and message type is
Required, Conditional, or Optional.
Finally, each specific message type is fully defined in
Sections 3.4 through 3.19.
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 [RFC2119].
The term “Conditional” as used in this
specification is to be interpreted that a message element MUST be
used, according to specified rules, within a particular message type (elements MUST
be one of “Required,” “Optional” or “Conditional”).
The term “Provisional” as used in this specification
is to be interpreted that the Request, Requisition or Commit is accepted on a tentative;
constrained or probationary basis; or that a Release is made on a tentative,
constrained or probationary basis.
[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.
[EDXL-HAVE] Emergency Data Exchange Language Hospital AVailablity Exchange http://www.oasis-open.org/apps/org/workgroup/emergency/download.php/25719/emergency_edxl_have-1.0-spec-pr03.pdf
[OGC
03-105r1] OpenGIS Geography Markup Language (GML)
Implementation Specification, http://portal.opengeospatial.org/files/?artifact_id=4700,
Version 3.1.1, 2003
[OGC CRS] Open
Geospatial Consortium, Topic 2 - Spatial Referencing by Coordinates (Topic
2) (CRS Abstract Specification), https://portal.opengeospatial.org/files/?artifact_id=6716,
Version 3, 2004.
[OGC 04-092r4] Open Geospatial Consortium, GML
3.1.1 schemas, http://schemas.opengis.net/gml/3.1.1/,
2004
OASIS CIQ OASIS,
Customer Information Quality (CIQ) Specifications Version 3.0, Name (xNL),
Address (xAL), and Party (xPIL), http://docs.oasis-open.org/ciq/v3.0/specs/,
15 June 2007
[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
[ISO 4217] ISO 4217:2001, Codes
for the representation of currencies and funds
[ISO 4217 codes] ISO 4217 currency
names and code elements, http://www.iso.org/iso/support/faqs/faqs_widely_used_standards/widely_used_standards_other/currency_codes/currency_codes_list-1.htm
[UCUM] Gunther
Schadow, Clement J. McDonald, The Unified Code for Units of Measure,Version
1.6, http://aurora.regenstrief.org/UCUM/ucum.html, Regenstrief Institute for Health Care, 2005
Below are some of the guiding principles behind
the development of EDXL-RM:
- Provide a standard message format for the
Resource Message
- Provide separate specific formats for the
distinct Resource Message Types
- Enable dissemination of messages based on
geographic delivery area
- Use and reuse of data content and models
developed by other initiatives
- Business process-driven specific messaging
needs across emergency professions
- Supporting everyday events and incident
preparedness, as well as disasters
- Facilitate emergency information sharing and
data exchange across the local, state, tribal, national and
non-governmental organizations of different professions that provide
emergency response and management services
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.oasisopen.org/committees/download.php/14981/EDXLRqmtsSupplement101905.doc,
October 19, 2005
In summary, the EDXL Resource Messaging
specification should
1. Define a detailed message 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. ResponseToRequestResource
c.
RequisitionResource
d. CommitResource
e. RequestInformation
f. ResponseToRequestInformation
g. OfferUnsolicitedResource
h. ReleaseResource
i.
RequestReturn
j.
ResponseToRequestReturn
k. RequestQuote
l.
ResponseToRequestQuote
m. RequestResourceDeploymentStatus
n. ReportResourceDeploymentStatus
o. RequestExtendedDeploymentDuration
p. ResponseToRequestExtendedDeploymentDuration
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 in a ResponseToRequestResource
that indicates availability of the requested Resource or to accept or decline to
an OfferUnsolicitedResource
5. Provide the ability to cancel any Resource Message (actual method is
MessageRecall)
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 Distribution of EDXL-RM
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 the EDXL-DE. Together EDXL-DE and EDXL-RM
are intended to expedite activities associated with managing resources during
all phases of Emergency Management. Routing and distribution information is
found only in the EDXL-DE and not in the EDXL-RM.
EDXL
Distribution Element (EDXL-DE) V 1.0 was approved as an OASIS standard in April
2006. The EDXL-DE provides a flexible message-distribution framework for data
sharing among emergency information systems using XML. The EDXL-DE may be used
over any data transmission system, including, but not limited to, the SOAP HTTP
binding.
The
primary purpose of the Distribution Element is to facilitate the routing of
emergency messages to recipients. The Distribution Element may be thought of as
a "container". It provides the information to route "payload"
message sets by including key routing information such as distribution type,
geography, incident, and sender/recipient IDs. Messages may be distributed to
specific recipients, to a geographic area, or based on codes such as agency
type (police, fire, etc.).
The
EDXL-DE is designed to carry one or more payloads called Content Objects. Each
Content Object may be well-formed XMLContent, or NonXMLContent. The EDXL-RM is designed to be well-formed XMLContent for routing using the
EDXL-DE. The EDXL-DE supports both context sensitive routing via metadata (i.e.
information about the Content Objects) and directed distribution (i.e. the
sender specifies specific recipients).
While the EDXL-RM is designed to be an EDXL-DE payload, other routing
mechanisms may be used to distribute EDXL-RM content if the message metadata is
provided in the same form or if the sender specifies specific recipients of the
payload.
Note: The following examples of usage 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.
This scenario follows the detection of a noxious
aerosol substance leak at a chemical plant that produces toxic materials. This
scenario involves evacuations, requests for hazmat teams and the evolution of
the incident into an explosion that destroys the leak site and an adjacent
building with casualties requiring emergency healthcare teams, full incident
command establishment, responses of various kinds and cleanup.
Full use case
available: http://www.oasis-open.org/committees/download.php/26805/EDXL_use_example_SafecomExplosion%20060805.doc
Explosion scenarios from the following source document provided
scenario content for this use case:
“SAFECOM
Statement of Requirements for Public Safety Wireless Communications and Interoperability”
The SAFECOM Program
Department of Homeland Security
Version 1.0
March 10, 2004
2.3.2 Cedar Fire Incident
This is an actual use case that follows the
events of the “Cedar” fire incident in late October and November 2003 in San Diego County, California. Operation Center (EOC) has been activated, and requests the
agencies to be on alert. This scenario represents a large scale incident
involving activation of the state Emergency Operation Center (EOC). This use
example is based upon four official source documents which provide a detailed
description of the incident and response, and provides independent evaluations
of overall response. The use example chronicles a lack of radio
interoperability coupled with poor coordination of mutual aid in the area, due
to several concurrent fires back to back with other recent fires in this
geographical region.
Full use case available: http://www.oasis-open.org/committees/download.php/26803/EDXL_use_example_Fire061005.doc
The following source documents provided
scenario content for this use case:
1.
Final
Draft_ 2003 SD Co Fire Safety Review-no pics.pdf http://www.oasis-open.org/committees/download.php/26809/Final%20Draft_%202003%20SD%20Co%20Fire%20Safety%20Review-no%20pics.pdf
2.
Cedar
Fire SDFD.pdf http://www.oasis-open.org/committees/download.php/26808/Cedar%20Fire%20SDFD.pdf
3.
City
of SD City Mgr Rpt Fire 2003.pdf http://www.oasis-open.org/committees/download.php/26810/City%20of%20SD%20City%20Mgr%20Rpt%20Fire%202003.pdf
Firestorm
2003 Case Study – Final.pdf http://www.oasis-open.org/committees/download.php/26807/Firestorm%202003%20Case%20Study%20-%20Final.pdf
This scenario modeled a category 5 hurricane
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/26804/EDXL_use_example_Hurricane061005.doc
The following source
document provided scenario content for this use case: “Planning Scenarios,
Executive Summaries, Created for use in National, Federal, State and Local
Homeland Security Preparedness Activities” – Version 2.0 – The Homeland
Security Council, David Howe, Senior Director for Response and Planning – July
2004”
“Scenario 10: Natural Disaster – Major Hurricane http://www.altheim.com/lit/planning_scenarios_exec_summary.html#p36
2.3.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 antivirals.
Full use
case available: http://www.oasis-open.org/committees/download.php/26806/EDXL_use_example_Influenza_06152005%20LaniGrahmRev.doc
3 EDXL Resource Messaging Model (Normative unless otherwise stated)
Section 3 of this Standard is normative unless otherwise
stated. If any differences are found between any XML schema and its associated
model, diagram, table or other artifact or text, then the XML schema shall
always take precedence and the other artifact(s) must be changed to match the
XML schema.
NOTE: Please report any such errors to OASIS
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 one of two major
message categories: a Request or a Response message; or a minor message
category type, or 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 or Parties (person or organization) 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 or
Resources with which it is concerned. A Resource contains information about its
Identity, Description and 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.
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 are
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 3.3.
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.
An RM message MUST be carried as the payload of the EDXL-DE
or a distribution mechanism with the distribution type values of Report,
Update, Cancel, Request, Response, Dispatch, Ack and Error, as defined in
EDXL-DE. For example, the acknowledgement of an RM message is handled by the distribution
mechanism.
When a message recipient receives an RM message, it uses the
EDXL-DE DistributionType value of Ack as an acknowledgement. An acknowledgement
is intended to inform the sender that the RM message has been received.
The EDXL-RM provides the mechanism to recall or update a
previously sent resource message through the EDXL MessageRecall element. The
MessageRecall element, when present, contains the RecalledMessageID and the
RecallType. The RecalledMessageID contains the MessageID of the message
previously sent that is being either canceled or updated. If the RecallType
element contains the value “Cancel”, then the entire message specified in
RecalledMessageID is to be canceled. If the RecallType element contains the
value “Update”, then the entire message specified in RecalledMessageID is
replaced by the new message.
This two-way communication is characterized 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 1 below.
Table 1: Resource Message Type
Summary
|
Message Type
|
Description
|
Message
Sender
|
|
RequestResource
|
Message used to request
needed resources from one or many recipients, possibly spawning multiple
responses.
|
Resource Consumer
|
|
ResponseToRequestResource
|
Message used as the response
to a “RequestResource”. Allows sender to list resource(s) which they feel
represent suitable match with a resource request.
|
Resource Supplier
|
|
RequisitionResource
|
Message used to “order”
specific resource, or to confirm specific resource to be “ordered” relating
to one or more responses to a “RequestResource”.
|
Resource Consumer
|
|
CommitResource
|
Message used to agree or
commit specific resource in response to a RequestResoure or RequisitionResource,”.
|
Resource Supplier
|
|
RequestInformation
|
Message used to ask resource
questions or provide general description of situation and general resources
needs.
|
Resource Consumer,
Resource Supplier
|
|
ResponseToRequestInformation
|
Message used as the response
to a RequestInformation message providing general information or to list
resource that may meet the specified need.
|
Resource Supplier, Resource
Consumer
|
|
OfferUnsolicitedResource
|
Message used to offer
available resources (that have not been requested) to assist with an
emergency response.
|
Resource Supplier
|
|
ReleaseResource
|
Message used at the incident
to “release” (demobilize) resource back to its original Supplier.
|
Resource Consumer
|
|
RequestReturn
|
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").
|
Resource Supplier
|
|
ResponseToRequestReturn
|
Message used as the response
to a "RequestReturn" indicating whether the resource may be
released, with relevant time-line information.
|
Resource Consumer
|
|
RequestQuote
|
Message used to request a
price quote from a seller or supplier.
|
Resource Consumer
|
|
ResponseToRequestQuote
|
Message used as the response
to a “RequestQuote”. Allows sender to list resource(s) which they feel
represent suitable match with the request, with pricing information.
|
Resource Supplier
|
|
RequestResourceDeploymentStatus
|
Message used to request
current “status” of resource.
|
Resource Consumer,
Resource Supplier
|
|
ReportResourceDeploymentStatus
|
Message used to report on
the current “status” of any resource.
|
Resource Consumer,
Resource Supplier
|
|
RequestExtendedDeploymentDuration
|
A request initiated by the
requester / receiver of resource, “I want to extend how long I need to keep
this resource”
|
Resource Consumer
|
|
ResponseToRequestExtendedDeployment
Duration
|
Message used as the response
to “RequestExtendedDeploymentDuration”.
|
Resource Supplier
|
Table 1 above and Figure 3 below are informative only. They are 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 Section3.3.
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 Resource Messages. For example,
the Ordering phase may actually only require the CommitResource message for
some actors.
Figure 3: Resource Message
Phases
Table 2 (below) summarizes all the Message
Types and their element contents. The specific details on each of the
Message Types are outlined in the following sections.
Table 2: Resource Message Type – Element Matrix (Key: R = Required, C = Conditional, O = Optional)
N/A – Not Applicable to the message type)
|
Schema Element
|
Message Element
|
Request Resource
|
ResponseTo Request Resource
|
Requisition Resource
|
Commit Resource
|
Request Information
|
ResponseTo Request Information
|
Offer Unsolicited Resource
|
Release Resource
|
Request Return
|
ResponseTo Request Return
|
Request Quote
|
ResponseTo Request Quote
|
Request Resource Deployment
Status
|
Report Resource Deployment
Status
|
Request Extended Deployment
Duration
|
ResponseTo 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
|
O
|
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
|
ResourceInfoElementID
|
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
|
PrecedingResourceInfoElementID
|
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 3: ScheduleTypes – Message Matrix
|
|
RequestResource
|
ResponseToRequestResource
|
RequisitionResource
|
CommitResource
|
RequestInformation
|
ResponseToRequestInformation
|
OfferUnsolicitedResource
|
ReleaseResource
|
RequestReturn
|
ResponseToRequestReturn
|
RequestQuote
|
ResponseToRequestQuote
|
RequestResourceDeploymentStatus
|
ReportResourceDeploymentStatus
|
RequestExtendedDeploymentDuration
|
ResponseToRequestExtendedDeploymentDuration
|
|
RequestedArrival
|
x
|
x
|
x
|
x
|
x
|
x
|
|
x
|
x
|
x
|
x
|
x
|
x
|
x
|
x
|
x
|
|
EstimatedArrival
|
|
x
|
x
|
x
|
x
|
x
|
x
|
x
|
x
|
x
|
|
x
|
x
|
x
|
x
|
x
|
|
ActualArrival
|
|
|
|
|
x
|
x
|
|
x
|
x
|
x
|
|
|
x
|
x
|
x
|
x
|
|
RequestedDeparture
|
x
|
x
|
x
|
x
|
x
|
x
|
|
x
|
x
|
x
|
x
|
x
|
x
|
x
|
x
|
x
|
|
EstimatedDeparture
|
|
x
|
x
|
x
|
x
|
x
|
x
|
x
|
x
|
x
|
|
x
|
x
|
x
|
x
|
x
|
|
ActualDeparture
|
|
|
|
x
|
x
|
x
|
|
x
|
x
|
x
|
|
|
x
|
x
|
x
|
x
|
|
RequestedReturnArrival
|
|
x
|
x
|
x
|
x
|
x
|
x
|
x
|
x
|
x
|
|
x
|
x
|
x
|
x
|
x
|
|
EstimatedReturnArrival
|
x
|
x
|
x
|
x
|
x
|
x
|
|
x
|
|
x
|
x
|
x
|
x
|
x
|
x
|
x
|
|
ActualReturnArrival
|
|
|
|
|
x
|
x
|
|
|
|
|
|
|
x
|
x
|
|
|
|
RequestedReturnDeparture
|
|
x
|
x
|
x
|
x
|
x
|
x
|
x
|
x
|
x
|
|
x
|
x
|
x
|
x
|
x
|
|
EstimatedReturnDeparture
|
x
|
x
|
x
|
x
|
x
|
x
|
|
x
|
|
x
|
x
|
x
|
x
|
x
|
x
|
x
|
|
ActualReturnDeparture
|
|
