Microsoft Word - EDXL-DE_Spec

EDXL-DE 1.0 OASIS Standard 1 May 2006

Emergency Data Exchange Language (EDXL)

Distribution Element, v. 1.0

OASIS Standard EDXL-DE v1.0, 1 May 2006

Document Identifier:

EDXL-DE-V1.0

OASIS Identifier:

{EMTC}-{EDXL-DE}-{1.0} (HTML) (Word) (PDF)

Location:

This Version: http://docs.oasis-open.org/emergency/EDXL-DE/V1.0

Technical Committee:

OASIS Emergency Management TC

Chair(s):

Elysa Jones, Warning Systems, Inc. - <ejones@warningsystems.com>

Editor(s):

Michelle Raymond, Individual

Sylvia Webb, Individual

Patti Iles Aymond, IEM, Inc.

- <[email protected]>

Subject / Keywords:

distribution element, dissemination, routing, payload, alert, resource message, emergency,

information sharing, data exchange, emergency response, emergency management, geospatial,

political, target area, message delivery, message sender, message recipient, distribution status,

distribution type, sender role, recipient role, response type, event cause, confidentiality, circle,

polygon, location, content object, consumer role, notification, XML message, distribution type,

geography, incident, sender identification, sender id, recipient identification, recipient id, inter-agency,

emergency information, functional role, recipient address, hazard, distribution status, distribution type,

event type, event etiology, message processor, event stage, resource code and response type

Related Work:

This specification is related to:

CAP 1.1 - http://www.oasis-open.org/committees/emergency

The Common Alerting Protocol (CAP) provides an open, non-proprietary digital message format

for all types of alerts and notifications. CAP messages are recommended as one of the

standardized forms for XML based message content, to be distributed by this Distribution

Element.

EDXL-DE 1.0 OASIS Standard 1 May 2006

Abstract:

This Distribution Element specification describes a standard message distribution framework for data

sharing among emergency information systems using the XML-based Emergency Data Exchange

Language (EDXL). This format may be used over any data transmission system, including but not

limited to the SOAP HTTP binding.

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. This document is updated periodically on no particular

schedule.

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 Technical Committee’s web page at 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 www.oasis-

open.org/committees/emergency/ipr.php.

Notices

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 OASIS specifications can be found at 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 specification, can be obtained from the

OASIS President.

OASIS invites any interested party to bring to its attention any copyrights, patents or patent

applications, or other proprietary rights which may cover technology that may be required to

implement this specification. Please address the information to the OASIS President.

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

this document itself does not be modified in any way, such as by removing the copyright notice or

references to OASIS, except as needed for the purpose of developing OASIS specifications, in which

case the procedures for copyrights defined in the OASIS Intellectual Property Rights document 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.

EDXL-DE 1.0 OASIS Standard 1 May 2006

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

RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A

PARTICULAR PURPOSE.

EDXL-DE 1.0 OASIS Standard 1 May 2006

Table of Contents

1. INTRODUCTION...................................................................................................................................................5

1.1 PURPOSE..............................................................................................................................................................5

1.2 HISTORY ..............................................................................................................................................................5

1.3 STRUCTURE OF THE EDXL DISTRIBUTION ELEMENT...........................................................................................6

1.3.1 <EDXLDistribution>..................................................................................................................................6

1.3.2 <targetArea>..............................................................................................................................................6

1.3.3 <contentObject>.........................................................................................................................................6

1.4 APPLICATIONS OF THE EDXL DISTRIBUTION ELEMENT ......................................................................................6

1.5 TERMINOLOGY.....................................................................................................................................................6

1.6 NORMATIVE REFERENCES....................................................................................................................................7

1.7 NON-NORMATIVE REFERENCES...........................................................................................................................7

2. DESIGN PRINCIPLES AND CONCEPTS (NON-NORMATIVE)....................................................................8

2.1 DESIGN PHILOSOPHY ...........................................................................................................................................8

2.2 REQUIREMENTS FOR DESIGN ...............................................................................................................................8

2.3 EXAMPLE USAGE SCENARIOS ..............................................................................................................................9

2.3.1 Distribution of Emergency Message/s or Alerts Based on Geographic Delivery Area and Incident Type.9

2.3.2 Encapsulation and Distribution of One or More Emergency Messages or Alerts or Notifications............9

2.3.3 Distribution of Resource Messages or Reports...........................................................................................9

2.3.4 Distribution of Well-Formed XML Messages..............................................................................................9

3. EDXLDISTRIBUTION ELEMENT STRUCTURE (NORMATIVE)..............................................................10

3.1 DOCUMENT OBJECT MODEL ..............................................................................................................................10

3.2 DATA DICTIONARY............................................................................................................................................11

3.2.1 EDXLDistribution Element and Sub-elements..........................................................................................11

3.2.2 targetArea Element and Sub-elements ......................................................................................................18

3.2.3 contentObject Element and Sub-elements.................................................................................................21

3.2.4 nonXMLContent Element and Sub-elements.............................................................................................26

3.2.5 xmlContent Element and Sub-elements.....................................................................................................28

3.2.6 List and Associated Value(s).....................................................................................................................30

3.2.7 Explicit Addressing ...................................................................................................................................31

APPENDIX A. XML SCHEMA FOR THE EDXLDISTRIBUTION ELEMENT..............................................32

APPENDIX B. EDXL-DE EXAMPLES..................................................................................................................35

B.1 EDXL-DE WITH CAP PAYLOAD......................................................................................................................35

B.2 EDXL-DE WITH MULTIPLE ENCRYPTED PAYLOADS .......................................................................................36

APPENDIX C. ACKNOWLEDGMENTS...............................................................................................................41

C.1 OASIS EMERGENCY MANAGEMENT TECHNICAL COMMITTEE: ........................................................................41

APPENDIX D. REVISION HISTORY....................................................................................................................42

EDXL-DE 1.0 OASIS Standard 1 May 2006

1. Introduction 1

1.1 Purpose 2

The primary purpose of the Distribution Element is to facilitate the routing of any properly formatted XML 3

emergency message to recipients. The Distribution Element may be thought of as a "container". It 4

provides the information to route "payload" message sets (such as Alerts or Resource Messages), by 5

including key routing information such as distribution type, geography, incident, and sender/recipient IDs. 6

1.2 History 7

The Disaster Management eGov Initiative of the Department of Homeland Security (DHS) determined in 8

2004 to launch a project to develop interagency emergency data communications standards. It called 9

together a group of national emergency response practitioner leaders and sought their guidance on 10

requirements for such standards. In June, 2004 the first such meeting identified the need for a common 11

distribution element for all emergency messages. Subsequent meetings of a Standards Working Group 12

developed detailed requirements and a draft specification for such a distribution element (DE). 13

During the same period the DM Initiative was forming a partnership with industry members of the 14

Emergency Interoperability Consortium (EIC) to cooperate in the development of emergency standards. 15

EIC had been a leading sponsor of the Common Alerting Protocol (CAP). Both organizations desired to 16

develop an expanded family of data formats for exchanging operational information beyond warning. 17

EIC members participated in the development of the DE, and in the broader design of the design of a 18

process for the development of additional standards. This was named Emergency Data Exchange 19

Language (EDXL). 20

The goal of the EDXL project is to facilitate emergency information sharing and data exchange across the 21

local, state, tribal, national and non-governmental organizations of different professions that provide 22

emergency response and management services. EDXL will accomplish this goal by focusing on the 23

standardization of specific messages (messaging interfaces) to facilitate emergency communication and 24

coordination particularly when more than one profession is involved. It is not just an "emergency 25

management" domain exercise. 26

It is a national effort including a diverse and representative group of local, state and federal emergency 27

response organizations and professionals, following a multi-step process. Just as a data-focused effort 28

targets shared data elements, the EDXL process looks for shared message needs, which are common 29

across a broad number of organizations. The objective is to rapidly deliver implementable standard 30

messages, in an incremental fashion, directly to emergency response agencies in the trenches, providing 31

seamless communication and coordination supporting each particular process. The effort first addresses 32

the most urgent needs and proceeds to subsequent message sets in a prioritized fashion. The goal is to 33

incrementally develop and deliver standards. 34

EDXL is intended as a suite of emergency data message types including resource queries and requests, 35

situation status, message routing instructions and the like, needed in the context of cross-disciplinary, 36

cross-jurisdictional communications related to emergency response. 37

The priorities and requirements are created by the DM EDXL Standards Working Group (SWG) which is a 38

formalized group of emergency response practitioners, technical experts, and industry. 39

EDXL-DE 1.0 OASIS Standard 1 May 2006

The draft DE specification was trialed by a number of EIC members starting in October, 2004. In 1

November, 2004, EIC formally submitted the draft to the OASIS Emergency Management Technical 2

Committee for standardization. 3

1.3 Structure of the EDXL Distribution Element 4

The EDXL Distribution Element (DE) comprises an <EDXLDistribution> element as described hereafter, 5

optional <targetArea> elements describing geospatial or political target area for message delivery, and a 6

set of <contentObject> elements each containing specific information regarding a particular item of 7

content. The included content may be any XML or other content type or a URI to access the content. 8

The <EDXLDistribution> block may be used without content to form the body of a routing query to, or 9

response from, a directory service. 10

1.3.1 <EDXLDistribution> 11

The <EDXLDistribution> element asserts the originator’s intent as to the dissemination of that particular 12

message or set of messages. 13

Note that use of the <EDXLDistribution> element does not guarantee that all network links and nodes will 14

implement the asserted dissemination policy or that unintended disclosure will not occur. Where sensitive 15

information is transmitted over distrusted networks, it should be encrypted in accordance with the Web 16

Services Security (WSS) standard http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-17

message-security-1.0.pdf with any updates and errata published by the OASIS Web Services Security 18

Technical Committee http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss, or some 19

other suitable encryption scheme. 20

1.3.2 <targetArea> 21

The <targetArea> is a container element for the geospatial or political area targeting of the recipient of the 22

message content. It contains data necessary to the originator's intent, based on location targeting, as to 23

the dissemination of that particular message or set of messages. 24

1.3.3 <contentObject> 25

The <contentObject> is a container element for specific messages. The <contentObject> element MUST 26

either contain an <xmlContent> content container or a <nonXMLContent> content container. Additional 27

elements (metadata) used for specific distribution of the <contentObject> payload or hints for processing 28

the payload are also present in the <contentObject> container element. 29

1.4 Applications of the EDXL Distribution Element 30

The primary use of the EDXL Distribution Element is to identify and provide information to enable the 31

routing of encapsulated payloads, called Content Objects. It is used to provide a common mechanism to 32

encapsulate content information. 33

1.5 Terminology 34

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD 35

NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” are to be interpreted as described in Key words for 36

use in RFCs to Indicate Requirement Levels [RFC2119]. 37

EDXL-DE 1.0 OASIS Standard 1 May 2006

In addition, within this Specification, the keyword “CONDITIONAL” should be interpreted as potentially 1

“REQUIRED” or “OPTIONAL” depending on the surrounding context. The term payload refers to some 2

body of information contained in the distribution element. 3

1.6 Normative References 4

[RFC2046] 5

N. Freed, Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types, 6

http://www.ietf.org/rfc/rfc2046.txt, IETF RFC 2046, November 1996. 7

[RFC2119] 8

S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, 9

http://www.ietf.org/rfc/rfc2119.txt, IETF RFC 2119, March 1997. 10

[RFC3066] 11

H. Alvestrand, Tags for the Identification of Languages, 12

http://www.ietf.org/rfc/rfc3066.txt, IETF RFC 3066, January 2001. 13

[WGS 84] 14

National Geospatial Intelligence Agency, Department of Defense World Geodetic 15

System 1984, http://earth-info.nga.mil/GandG/tr8350_2.html, NGA Technical Report 16

TR8350.2, January 2000. 17

[XML 1.0] 18

T. Bray, Extensible Markup Language (XML) 1.0 (Third Edition), 19

http://www.w3.org/TR/REC-xml/, W3C REC-XML-20040204, February 2004. 20

[namespaces] 21

T. Bray, Namespaces in XML, http://www.w3.org/TR/REC-xml-names/, W3C REC-22

xml-names-19990114, January 1999. 23

[dateTime] 24

N. Freed, XML Schema Part 2: Datatypes Second Edition, 25

http://www.w3.org/TR/xmlschema-2/#dateTime, W3C REC-xmlschema-2, October 26

2004. 27

1.7 Non-Normative References 28

EDXL General Functional Requirements 29

EDXL General Functional Requirements, http://www.oasis-30

open.org/committees/document.php?document_id=10031&wg_abbrev=emergency, 31

November 2004. 32

EDXL Distribution Element Implementer's Guide 33

EDXL Distribution Element Implementer's Guide, http://www.oasis-34

open.org/committees/document.php?document_id=14120&wg_abbrev=emergency, 35

August 2005. 36

EDXL-DE 1.0 OASIS Standard 1 May 2006

2. Design Principles and Concepts (non-normative) 1

2.1 Design Philosophy 2

Below are some of the guiding principles of the Distribution Element: 3

• Provide an Open Container Model to enable dissemination of one or more emergency messages 4

• Provide flexible mechanisms to inform message routing and/or processing decisions 5

• Enable dissemination of messages based on geographic delivery area 6

• Use and re-use of data content and models developed by other initiatives 7

• Business process-driven specific messaging needs across emergency professions 8

• Supporting everyday events and incident preparedness, as well as disasters 9

• Facilitate emergency information sharing and data exchange across the local, state, tribal, 10

national and non-governmental organizations of different professions that provide emergency 11

response and management services 12

• Multi-use format - One message schema supports multiple message types (e.g., alert / update / 13

cancellations / acknowledgments / error messages) in various applications (actual / exercise / test 14

/ system message.) 15

2.2 Requirements for Design 16

The Distribution Element specification should: 17

1. Define a single compound XML structure (or an equivalent single structure if transcoded into 18

another format) including the required and optional elements defined below. 19

2. Specify a desired geographic delivery area, expressed in geospatial coordinates or using 20

political/administrative codes 21

3. Allow the ability to encapsulate a payload or set of payloads 22

4. Take a modular approach to the enumerations of element values which may evolve over time, 23

e.g. by referring to a separate schema for those enumerations. 24

5. Specify unique distribution and sender identifiers 25

6. Specify the date and time the distribution was sent 26

7. Specify the actionability of the distribution message (e.g., real-world, test, exercise) 27

8. Specify the functional type of the distribution message (e.g., report, request, update, cancellation, 28

etc.) 29

9. Specify that the following elements may be present in a valid payload: 30

a. A specification of the format of the distribution message (e.g., the URI of an XML Schema 31

for the message) 32

b. The functional role and/or type of the sender of the distribution message 33

c. One or more functional role and/or type of desired recipients of the distribution message 34

d. A reference to one or more previous distribution messages 35

e. One or more types of response activity involved 36

f. A reference to the type of incident 37

g. One or more characterization of the etiology of the subject event or incident (e.g., 38

terrorism, natural, under investigation, etc.) 39

h. The incident name or other identifier of one or more event or incident 40

i. A reference to one or more response types. 41

j. One or more specific recipient addresses (as a URI) 42

k. Specify an assertion of the confidentiality level of the combined payloads. 43

10. In addition, the Content Object element contained within the Distribution Element SHOULD: 44

a. Allow the encapsulation of one or more payloads in each of the Content Object elements. 45

b. Specify the functional role and/or type of the sender of each payload 46

c. Specify one or more functional roles and/or types of desired recipients of each payload 47

EDXL-DE 1.0 OASIS Standard 1 May 2006

d. Specify an assertion of the confidentiality level of each payload. 1

11. Provide or refer to specific lists (enumerations) of values and their definitions for: 2

a. Types of incidents 3

b. Types of hazards and/or events 4

c. Types of agencies 5

d. Types of response activity 6

e. The functional role and/or type of the sender 7

f. The functional roles and/or types of desired recipients 8

g. The incident name or other identifier of one or more event or incident. 9

2.3 Example Usage Scenarios 10

Note: The following examples of use scenarios were used as a basis for design and review of the EDXL 11

Distribution Element Message format. These scenarios are non-normative and not intended to be 12

exhaustive or to reflect actual practices. 13

2.3.1 Distribution of Emergency Message/s or Alerts Based on Geographic 14

Delivery Area and Incident Type 15

The terror alert level has been raised to RED. Credible intelligence indicates that terrorist groups in the 16

Mid-Atlantic region are seeking to conduct an attack in the next 48 hours. The Department of Homeland 17

Security sends an emergency alert message, and using the Distribution Element, distributes it to all 18

emergency agencies in the specified area. 19

2.3.2 Encapsulation and Distribution of One or More Emergency Messages or 20

Alerts or Notifications 21

A Radiological sensor triggered at a prominent Tunnel toll booth. Radiation alarm levels indicates 22

possible dirty bomb. Authorities decide to send multiple messages to a number of jurisdictions. They send 23

an EDXL Distribution Element with two encapsulated CAP messages. The first one notifies the area 24

where the sensor has been triggered. The second one is an alert to emergency response agencies that 25

the state Emergency Operation Center (EOC) has been activated, and requests the agencies to be on 26

alert. 27

2.3.3 Distribution of Resource Messages or Reports 28

The Local EOC has a need for additional resource/support, but is unsure what specifically to request. A 29

free-form request for information and resource availability is prepared, and is sent to the state EOC and 30

other organizations (person to person) using the Distribution Element. The Local EOC receives an 31

acknowledgment message from the State EOC, as well as a request for Information on additional details 32

of the requested resource. Both of these messages are contained within a single Distribution Element. 33

2.3.4 Distribution of Well-Formed XML Messages 34

A huge crash, involving a car and a HAZMAT truck, occurs at a busy junction on an inter-state freeway. 35

Separate automatic notifications of both the car crash and the HAZMAT carrier are sent using the 36

Vehicular Emergency Data Set (VEDS), contained in the Distribution Element. The Transportation 37

Management Center (TMC) shares information (related to the above incident) with the adjacent TMC, 38

using the IEEE 1512 Incident Management Message Set. These set of messages are exchanged using 39

the EDXL Distribution Element. 40

EDXL-DE 1.0 OASIS Standard 1 May 2006

3. EDXLDistribution Element Structure (normative) 1

3.1 Document Object Model 2

Bold indicates required element. 3

Italics indicates one or more optional unspecified elements 4

# indicates conditional requirement 5

* indicates multiple instances allowed 6

EDXLDistribution

distributionID

senderID

dateTimeSent

distributionStatus

distributionType

combinedConfidentiality

language

senderRole *

recipientRole *

keyword *

distributionReference * #

explicitAddress *

targetArea

circle *

polygon *

country *

subdivision *

locCodeUN *

contentObject

contentDescription

contentKeyword *

incidentID

incidentDescription

originatorRole *

consumerRole *

confidentiality

other *

nonXMLContent

mimeType

size

digest

uri

contentData

xmlContent

keyXMLContent

embeddedXMLContent

0..*

EDXL-DE 1.0 OASIS Standard 1 May 2006

3.2 Data Dictionary 1

Note: Unless explicitly constrained within this Data Dictionary, EDXL-DE elements MAY have null values. 2

Implementers MUST check for this condition wherever it might affect application performance. 3

3.2.1 EDXLDistribution Element and Sub-elements 4

The Distribution Message element, <EDXLDistribution> is the container element for all data necessary to 5

the originator’s intent as to the dissemination of the contained message or set of messages. 6

Element

EDXLDistribution

Type XML Structure

Usage REQUIRED, MUST be used once and only once, top level container

Definition The container of all of the elements related to the distribution of the content messages.

Comments 1. The <EDXLDistribution> element may include one or more <targetArea> and

<contentObject> blocks.

2. Use of the <EDXLDistribution> element does not guarantee that all network links

and nodes will implement the asserted dissemination policy or that unintended

disclosure will not occur. Where sensitive information is transmitted over untrusted

networks, it should be encrypted in accordance with the Web Services Security

(WSS) standard (<http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-

soap-message-security-1.0.pdf>) with any updates and errata published by the

OASIS Web Services Security Technical Committee (<http://www.oasis-

open.org/committees/tc_home.php?wg_abbrev=wss>), or some other suitable

encryption scheme.

Sub-

elements

• distributionID

• senderID

• dateTimeSent

• distributionStatus

• distributionType

• combindedConfidentiality

• language

• senderRole

• recipientRole

• keyword

• distributionReference

• explicitAddress

• targetArea

• contentObject

Used In top level element

EDXL-DE 1.0 OASIS Standard 1 May 2006

Element

distributionID

Type xsd:string

Usage REQUIRED, MUST be used once and only once

Definition The unique identifier of this distribution message.

Comments 1. Uniqueness is assigned by the sender to be unique for that sender.

2. The identifier MUST be a properly formed -escaped if necessary- XML string.

Used In EDXLDistribution

Element

senderID

Type xsd:string

Usage REQUIRED, MUST be used once and only once

Definition The unique identifier of the sender.

Comments 1. Uniquely identifies human parties, systems, services, or devices that are all

potential senders of the distribution message.

2. In the form actor@domain-name.

3. Uniqueness of the domain-name is guaranteed through use of the Internet Domain

Name System, and uniqueness of the actor name enforced by the domain owner.

4. The identifier MUST be a properly formed -escaped if necessary- XML string.

Examples: dispatcher@example.gov, 0006.0e39.ad80@example.com

Used In EDXLDistribution

Element

dateTimeSent

Type xsd:dateTime

Usage REQUIRED, MUST be used once and only once

Definition The date and time the distribution message was sent.

Comments 1. The Date Time combination must include the offset time for time zone.

2. Must be in the W3C format for the XML [dateTime]

data type.

Example: 2004-08-01T16:49:00-07:00

Used In EDXLDistribution

EDXL-DE 1.0 OASIS Standard 1 May 2006

Element

distributionStatus

Type xsd:string with restrictions

Usage REQUIRED, MUST be used once and only once

Definition The actionability of the message.

Comments 1. Value must be one of:

a. Actual - "Real-world" information for action

b. Exercise - Simulated information for exercise participants

c. System - Messages regarding or supporting network functions

d. Test - Discardable messages for technical testing only.

2. The status MUST be a properly formed -escaped if necessary- XML string.

Used In EDXLDistribution

Element

distributionType

Type xsd:string with restrictions

Usage REQUIRED, MUST be used once and only once

Definition The function of the message.

Comments 1. Value must be one of:

a. Report - New information regarding an incident or activity

b. Update - Updated information superseding a previous message

c. Cancel - A cancellation or revocation of a previous message

d. Request - A request for resources, information or action

e. Response - A response to a previous request

f. Dispatch - A commitment of resources or assistance

g. Ack - Acknowledgment of receipt of an earlier message

h. Error - Rejection of an earlier message (for technical reasons)

i. SensorConfiguration - These messages are for reporting configuration

during power up or after Installation or Maintenance.

j. SensorControl - These are messages used to control sensors/sensor

concentrator components behavior.

k. SensorStatus - These are concise messages which report sensors/sensor

concentrator component status or state of health.

l. SensorDetection - These are high priority messages which report sensor

detections.

2. The distribution type applies to the function of the content objects as a set. Those

cases where payloads have different distribution types should be clustered in

different distribution elements.

3. The type MUST be a properly formed -escaped if necessary- XML string.

Used In EDXLDistribution

EDXL-DE 1.0 OASIS Standard 1 May 2006

Element

combindedConfidentiality

Type xsd:string

Usage REQUIRED, MUST be used once and only once

Definition Confidentiality of the combined distribution message’s content.

Comments 1. The <combindedConfidentiality> indicates the confidentiality of the combined

<contentObject> sub-elements. Generally the combined confidentiality is the most

restrictive of the <confidentiality> elements in the container <contentObject>

element, but it can be more restrictive than any of the individual <confidentiality>

elements.

2. The <combindedConfidentiality> element MUST be present if a <confidentiality>

element is present in any of the <contentObject> elements.

3. Application specific mechanisms will be required to determine the minimum

confidentiality level in cases where different confidentiality schemes are used in

the <contentObject>.

4. Default value “UNCLASSIFIED AND NOT SENSITIVE”

5. The confidentiality MUST be a properly formed -escaped if necessary- XML string.

Used In EDXLDistribution

Element

language

Type xsd:string

Usage OPTIONAL, MAY use once and only once

Definition The primary language (but not necessarily exclusive) used in the payloads.

Comments 1. Valid language values are supplied in the ISO standard [RFC3066].

2. The language MUST be a properly formed -escaped if necessary- XML string.

Examples: FR, EN

Used In EDXLDistribution

EDXL-DE 1.0 OASIS Standard 1 May 2006

Element

senderRole

Type List and Associated Value(s)

Usage OPTIONAL, MAY use multiple

Definition The functional role of the sender, as it may determine message routing decisions.

Comments 1. The list and associated value(s) is in the form:

<valueListUrn>valueListUrn</valueListUrn>

<value>value</value>

</senderRole>

where the content of <valueListUrn> is the Uniform Resource Name of a published

list of values and definitions, and the content of <value> is a string (which may

represent a number) denoting the value itself.

2. Multiple instances of the <value>, MAY occur with a single <valueListUrn> within

the <senderRole> container.

3. Multiple instances of <senderRole> MAY occur within a single <EDXLDistribution>

container.

Sub-

elements

• valueListUrn

• value

Used In EDXLDistribution

EDXL-DE 1.0 OASIS Standard 1 May 2006

Element

recipientRole

Type List and Associated Value(s)

Usage OPTIONAL, MAY use multiple

Definition The functional role of the recipient, as it may determine message routing decisions.

Comments 1. The list and associated value(s) is in the form:

<valueListUrn>valueListUrn</valueListUrn>

<value>value</value>

</recipientRole>

where the content of <valueListUrn> is the Uniform Resource Name of a published

list of values and definitions, and the content of <value> is a string (which may

represent a number) denoting the value itself.

2. Multiple instances of the <value>, MAY occur with a single <valueListUrn> within

the <recipientRole> container.

3. Multiple instances of <recipientRole> MAY occur within a single

<EDXLDistribution> container.

Sub-

elements

• valueListUrn

• value

Used In EDXLDistribution

EDXL-DE 1.0 OASIS Standard 1 May 2006

Element

keyword

Type List and Associated Value(s)

Usage OPTIONAL, MAY use multiple

Definition The topic related to the distribution message, as it may determine message routing

decisions.

Comments 1. The list and associated value(s) is in the form:

<valueListUrn>valueListUrn</valueListUrn>

<value>value</value>

</keyword>

where the content of <valueListUrn> is the Uniform Resource Name of a published

list of values and definitions, and the content of <value> is a string (which may

represent a number) denoting the value itself.

2. Multiple instances of the <value>, MAY occur with a single <valueListUrn> within

the <keyword> container.

3. Multiple instances of <keyword> MAY occur within a single <EDXLDistribution>

container.

4. Examples of things <keyword> might be used to describe include event type,

event etiology, incident ID and response type.

Sub-

elements

• valueListUrn

• value

Used In EDXLDistribution

Element

distributionReference

Type xsd:string

Usage CONDITIONAL, MAY use multiple

Definition A reference to a previous distribution message.

Comments 1. The <distributionID> and <senderID> and <dateTimeSent> of the referenced

previous message, concatenated with a comma delimiter.

2. This element should appear at least once in any message which updates, cancels

or otherwise refers to another message.

3. MUST be a properly formed -escaped if necessary- XML string.

Example: msgID0074,actor@domain-name,2004-08-01T16:49:00-07:00

Used In EDXLDistribution

EDXL-DE 1.0 OASIS Standard 1 May 2006

Element

explicitAddress

Type XML Structure

Usage OPTIONAL, MAY use multiple

Definition The identifier of an explicit recipient.

Comments 1. Identifies human parties, systems, services, or devices that are all potential

recipients of the distribution message.

2. The explicit address of a recipient in the form:

< explicitAddressScheme> explicitAddressScheme </ explicitAddressScheme>

<explicitAddressValue> explicitAddressValue </ explicitAddressValue>

</ explicitAddress >

where the content of <explicitAddressScheme> is the distribution addressing

scheme used, and the content of <explicitAddressValue> is a string denoting the

addressees value.

3. Multiple instances of the < explicitAddressValue >, MAY occur with a single <

explicitAddressScheme > within the < explicitAddress > container.

4. Multiple instances of < explicitAddress > MAY occur within a single

<EDXLDistribution> container.

Sub-

elements

• explicitAddressScheme

• explicitAddressValue

Used In EDXLDistribution

3.2.2 targetArea Element and Sub-elements 2

The <targetArea> is a container element for the geospatial or political area targeting of the message 3

content. It indicates the originator’s intent based on location targeting as to the dissemination of that 4

particular message or set of messages. 5

Geospatial Note: 6

Values for latitude and longitude shall be expressed as decimal fractions of degrees. Whole 7

degrees of latitude shall be represented by a decimal number ranging from 0 through 90. Whole 8

degrees of longitude shall be represented by a decimal number ranging from 0 through 180. 9

When a decimal fraction of a degree is specified, it shall be separated from the whole number of 10

degrees by a decimal point (the period character, "."). Decimal fractions of a degree should be 11

expressed to the precision available, with trailing zeroes being used as placeholders if required. 12

A decimal point is optional where the precision is less than one degree. 13

Some effort should be made to preserve the apparent precision when converting from 14

another datum or representation, for example 41 degrees 13 minutes should be represented as 15

41.22 and not 41.21666, while 41 13' 11" may be represented as 41.2197. 16

Latitudes north of the equator MAY be specified by a plus sign (+), or by the absence of a minus 17

sign (-), preceding the designating degrees. Latitudes south of the Equator MUST be designated 18

by a minus sign (-) preceding the digits designating degrees. Latitudes on the Equator MUST be 19

designated by a latitude value of 0. 20

EDXL-DE 1.0 OASIS Standard 1 May 2006

Longitudes east of the prime meridian shall be specified by a plus sign (+), or by the absence of a 1

minus sign (-), preceding the designating degrees. Longitudes west of the prime meridian MUST 2

be designated by a minus sign (-) preceding the digits designating degrees. Longitudes on the 3

prime meridian MUST be designated by a longitude value of 0. A point on the 180th meridian 4

shall be taken as 180 degrees West, and shall include a minus sign. 5

Element

targetArea

Type XML Structure

Usage OPTIONAL, MAY use multiple

Definition The container element for location information.

Comments 1. Multiple <targetArea> blocks may appear in a single <EDXLDistribution> element,

in which case the target area for the current message is the union of all areas

described in the various <targetArea> structures.

Sub-

elements

• circle

• polygon

• country

• subdivision

• locCodeUN

Used In EDXLDistribution

Element

circle

Type xsd:string

Usage OPTIONAL, MAY use multiple

Definition An enclosed geographic area within a given radius around a geographic point.

Comments 1. Represented in the form "latitude, longitude, radius". (See Geospatial Note above)

2. The central point is represented by lat-long values conforming to the WGS84

coordinate reference system. [WGS 84]

3. The radius value is expressed in kilometers.

4. MUST be a properly formed -escaped if necessary- XML string.

Example: 38.26295, -122.07454 15

Used In targetArea

EDXL-DE 1.0 OASIS Standard 1 May 2006

Element

polygon

Type xsd:string

Usage OPTIONAL, MAY use multiple

Definition An enclosed geographic area within a simple closed polygon defined by an ordered set of

vertices.

Comments 1. Represented by a space-delimited series of latitude, longitude pairs, with the last

pair identical to the first. (See Geospatial Note above)

2. The lat-long values conform to the WGS84 coordinate reference system. [WGS

84]

3. MUST be a properly formed -escaped if necessary- XML string.

Example: 42,-124.2102 42,-120.1 39,-120 35.0,-114.6328 34.35,- 120.4418 38.9383,-

123.817 42,-124.2102

Used In targetArea

Element

country

Type xsd:string

Usage OPTIONAL, MAY use multiple

Definition The code of the country.

Comments 1. The two-character ISO 3166-1 Country Code for the country concerned.

2. More specific target location information can be defined in the <subdivision>

elements.

3. MUST be a properly formed -escaped if necessary- XML string.

Used In targetArea

EDXL-DE 1.0 OASIS Standard 1 May 2006

Element

subdivision

Type xsd:string

Usage OPTIONAL, MAY use multiple

Definition The ISO 3166-2 designator for the administrative subdivision concerned.

Comments 1. The first two characters, before the hyphen, are the two character ISO 3166-1

Country Code for the country within which the designated subdivision is located.

2. The following one-to-three characters following the hyphen designate the particular

subdivision.

3. MUST be a properly formed -escaped if necessary- XML string.

Examples: US-TX (U.S. State of Texas), DK-025 (Danish county Roskilde), MG-T

(Antananarivo province, Madagascar)

Used In targetArea

Element

locCodeUN

Type xsd:string

Usage OPTIONAL, MAY use multiple

Definition The UN/LOCODE designator for the location concerned.

Comments 1. The two first digits are the two character ISO3166-1 Country Code for the country

in which the place is located.

2. The following three characters are the UN/LOCODE designator for the particular

location within that country.

3. No spaces or punctuation are used within this designator.

4. MUST be a properly formed -escaped if necessary- XML string.

Example: USFFB (Fairfield, Alabama, USA), USSUU (Fairfield, California, USA), GBFFD

(Falfield, South Gloucestershire, UK)

Used In targetArea

3.2.3 contentObject Element and Sub-elements 4

The <contentObject> element is the container element for specific messages. The <contentObject> 5

element MUST either contain an <xmlContent> content container or a <nonXMLContent> content 6

container. Additional elements (metadata) used for specific distribution of the <contentObject> payload or 7

hints for processing the payload are also present in the <contentObject> container element. 8

EDXL-DE 1.0 OASIS Standard 1 May 2006

Element

contentObject

Type XML Structure

Usage OPTIONAL, MAY use multiple

Definition The container element for message data and content.

Comments 1. The <contentObject> is the container element for specific messages.

2. The <contentObject> may have an optional attribute that defines a namespace

prefix which resolves ambiguous element names.

3. The <contentObject> element MUST contain exactly one of the two content

formats:

a. <xmlContent>, for valid namespaced XML content or

b. <nonXMLContent>, containing one or both of the elements <uri>, for

reference to the content’s location, and <contentData>, for data

encapsulated in the message.

Sub-

elements

• contentDescription

• contentKeyword

• incidentID

• incidentDescription

• originatorRole

• consumerRole

• confidentiality

• nonXMLContent

• xmlContent

Used In EDXLDistribution

Element

contentDescription

Type xsd:string

Usage OPTIONAL, MAY use once and only once

Definition The human-readable text describing the content object.

Comments 1. MUST be a properly formed -escaped if necessary- XML string.

Examples: "CAP message from FEMA", "Map of affected area" or "Photo of missing child".

Used In contentObject

EDXL-DE 1.0 OASIS Standard 1 May 2006

Element

contentKeyword

Type List and Associated Value(s)

Usage OPTIONAL, MAY use multiple

Definition The topic related to the message data and content, as it may determine message

distribution and presentation decisions.

Comments 1. The list and associated value(s) is in the form:

<valueListUrn>valueListUrn</valueListUrn>

<value>value</value>

</contentKeyword>

where the content of <valueListUrn> is the Uniform Resource Name of a published

list of values and definitions, and the content of <value> is a string (which may

represent a number) denoting the value itself.

2. Multiple instances of the <value>, MAY occur with a single <valueListUrn> within

the <contentKeyword> container.

3. Multiple instances of <contentKeyword> MAY occur within a single

<contentObject> container.

Examples of things <contentKeyword> might be used to describe include message

processor, event stage, resource code and response type.

Sub-

elements

• valueListUrn

• value

Used In contentObject

Element

incidentID

Type xsd:string

Usage OPTIONAL, MAY use once and only once

Definition The human-readable text uniquely identifying the incident/event/situation associated with

the contentObject.

Comments 1. MUST be a properly formed -escaped if necessary- XML string.

Used In contentObject

EDXL-DE 1.0 OASIS Standard 1 May 2006

Element

incidentDescription

Type xsd:string

Usage OPTIONAL, MAY use once and only once

Definition The human-readable text describing the incident/event/situation associated with the

contentObject.

Comments 1. MUST be a properly formed -escaped if necessary- XML string.

Used In contentObject

Element

originatorRole

Type List and Associated Value(s)

Usage OPTIONAL, MAY use multiple

Definition The functional role of the message originator, as it may determine message distribution

and presentation decisions.

Comments 1. The list and associated value(s) is in the form:

<valueListUrn>valueListUrn</valueListUrn>

<value>value</value>

</originatorRole>

where the content of <valueListUrn> is the Uniform Resource Name of a published

list of values and definitions, and the content of <value> is a string (which may

represent a number) denoting the value itself.

2. Multiple instances of the <value>, MAY occur with a single <valueListUrn> within

the <originatorRole> container.

3. Multiple instances of <originatorRole> MAY occur within a single <contentObject>

container.

Sub-

elements

• valueListUrn

• value

Used In contentObject

EDXL-DE 1.0 OASIS Standard 1 May 2006

Element

consumerRole

Type List and Associated Value(s)

Usage OPTIONAL, MAY use multiple

Definition The functional role of the message consumer, as it may determine message distribution

and presentation decisions.

Comments 1. The list and associated value(s) is in the form:

<valueListUrn>valueListUrn</valueListUrn>

<value>value</value>

</consumerRole>

where the content of <valueListUrn> is the Uniform Resource Name of a published

list of values and definitions, and the content of <value> is a string (which may

represent a number) denoting the value itself.

2. Multiple instances of the <value>, MAY occur with a single <valueListUrn> within

the <consumerRole> container.

3. Multiple instances of <consumerRole> MAY occur within a single <contentObject>

container.

Example: <valueListUrn>"http://www.dhs.gov/NiemRoleType"</valueListUrn>, <value>ICS

Operations Branch</value>

Sub-

elements

• valueListUrn

• value

Used In contentObject

Element

confidentiality

Type xsd:string

Usage OPTIONAL, MAY use once and only once

Definition Special requirements regarding confidentiality of the content of this <contentObject>.

Comments 1. MUST be a properly formed -escaped if necessary- XML string.

Used In contentObject

EDXL-DE 1.0 OASIS Standard 1 May 2006

Element

other

Type xsd:other

Usage OPTIONAL, MAY be use to add an unlimited number of XML elements for enveloped

signing process.

Definition Special requirements allowing for signature of the content of a <contentObject>.

Comments 1. There is no mandatory validation of the elements if the namespace reference can

not be located.

2. MUST be a properly formed XML string – escaped, if necessary.

3. Element names cannot duplicate other element names in the contentObject. Such

duplication would prevent validation due to the ambiguity introduced.

4. This element may be used for signatures. If this element is used for experimental

extensions, such extensions may not be supported by all users or in future

versions of EDXL-DE.

Used In contentObject

3.2.4 nonXMLContent Element and Sub-elements 2

Element

nonXMLContent

Type XML Structure

Usage CONDITIONAL, MUST use once if xmlContent is not used

Definition Container for content provided in a non-XML MIME type.

Comments 1. The <nonXMLContent> container MUST have one or both of the elements

<contentData> and <uri>.

2. If the <uri> element is used in conjunction with the <contentData> element, it must

reference a data location that contains the same data as is contained in the

<contentData> element.

Sub-

elements

• mimeType

• size

• digest

• uri

• contentData

Used In contentObject

EDXL-DE 1.0 OASIS Standard 1 May 2006

Element

mimeType

Type xsd:string

Usage REQUIRED, MUST be used once and only once

Definition The format of the payload.

Comments 1. MIME content type and sub-type as described in [RFC 2046].

2. MUST be a properly formed -escaped if necessary- XML string.

Examples: application/pdf, application/mp3

Used In nonXMLContent

Element

size

Type xsd:integer

Usage OPTIONAL, MAY use once and only once

Definition The file size of the payload .

Comments 1. Value must be in bytes and represent the raw file size (not encoded or encrypted).

Used In nonXMLContent

Element

digest

Type xsd:string

Usage OPTIONAL, MAY use once and only once

Definition The digest value for the payload.

Comments 1. Used to ensure the integrity of the payload.

2. Calculated using the Secure Hash Algorithm (SHA-1)

3. MUST be a properly formed -escaped if necessary- XML string.

Used In nonXMLContent

EDXL-DE 1.0 OASIS Standard 1 May 2006

Element

uri

Type xsd:anyURI

Usage OPTIONAL, MAY use once and only once

Definition A Uniform Resource Identifier that can be used to retrieve the identified resource.

Comments 1. May be a full absolute URI, typically a Uniform Resource Locator, that can be used

to retrieve the resource over the Internet.

2. May be a relative URI naming a file. This may be just a pointer to a file or

specifically to the file represented in the <contentData>.

Used In nonXMLContent

Element

contentData

Type xsd:base64Binary

Usage OPTIONAL, MAY use once and only once

Definition The base-64 encoded data content.

Comments 1. MAY be used either with or instead of the <uri> element in contexts where retrieval

of a resource via a URI is not feasible.

2. MUST be a properly formed -escaped if necessary- XML string.

Used In nonXMLContent

3.2.5 xmlContent Element and Sub-elements 3

Element

xmlContent

Type XML Structure

Usage CONDITIONAL, MUST use once if nonXMLContent is not used

Definition Container for valid-namespaced XML data.

Sub-

elements

1. keyXMLContent

2. embeddedXMLContent

3. An optional namespace attribute may be included.

Used In contentObject

EDXL-DE 1.0 OASIS Standard 1 May 2006

Element

keyXMLContent

Type xsd:string

Usage OPTIONAL, MAY use multiple

Definition A container element for collected fragments of valid XML.

Comments 1. Extracts must come from the XML document contained within the

<embeddedXMLContent> element within the current <contentObject> block.

2. All content within this element MUST be explicitly namespaced as defined in the

enclosing <contentObject> tag.

3. MUST be a properly formed -escaped if necessary- XML string.

Used In xmlContent

Element

embeddedXMLContent

Type xsd:string

Usage OPTIONAL, MAY use multiple

Definition The <embeddedXMLContent> element is an open container for valid XML from an explicit

namespaced XML Schema.

Comments 1. The content MUST be a separately-namespaced well-formed XML document.

2. The enclosed XML content MUST be explicitly namespaced as defined in the

enclosing <embeddedXMLContent> tag.

3. Enclosed XML content may be encrypted and/or signed within this element.

Used In xmlContent

EDXL-DE 1.0 OASIS Standard 1 May 2006

3.2.6 List and Associated Value(s) 1

Element

valueListUrn

Type xsd:string

Usage CONDITIONAL, MAY use once and only once

Definition The name of a certified list maintained by the Community of Interest (COI) for the value

referenced.

Comments 1. MUST be a properly formed -escaped if necessary- XML string.

Used In

• EDXLDistribution/senderRole

• EDXLDistribution/recipientRole

• EDXLDistribution/keyword

• contentObject/contentKeyword

• contentObject/originatorRole

• contentObject/consumerRole

Element

value

Type xsd:string

Usage CONDITIONAL, MAY use multiple

Definition A value from a certified list maintained by the Community of Interest (COI) for the

referenced element.

Comments 1. MUST be a properly formed -escaped if necessary- XML string.

Used In

• EDXLDistribution/senderRole

• EDXLDistribution/recipientRole

• EDXLDistribution/keyword

• contentObject/contentKeyword

• contentObject/originatorRole

• contentObject/consumerRole

EDXL-DE 1.0 OASIS Standard 1 May 2006

3.2.7 Explicit Addressing 1

Element

explicitAddressScheme

Type xsd:string

Usage REQUIRED, MUST use once and only once

Definition Identifies the distribution addressing scheme used.

Comments 1. MUST be a properly formed -escaped if necessary- XML string.

Examples for this type of distribution includes - email, military USMTF, etc. . .

Used In explicitAddress

Element

explicitAddressValue

Type xsd:string

Usage REQUIRED, MAY use multiple

Definition A properly formed -escaped if necessary- XML string denoting the addressees value.

Comments 1. MUST be a properly formed -escaped if necessary- XML string.

Used In explicitAddress

EDXL-DE 1.0 OASIS Standard 1 May 2006

Appendix A. XML Schema for the EDXLDistribution 1

Element 2

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

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" 5

xmlns="urn:oasis:names:tc:emergency:EDXL:DE:1.0" 6

targetNamespace="urn:oasis:names:tc:emergency:EDXL:DE:1.0" 7

elementFormDefault="qualified" attributeFormDefault="unqualified" version="1.0CD"> 8

<xsd:element name="EDXLDistribution"> 10

<xsd:complexType> 11

<xsd:sequence> 12

<xsd:element name="distributionID" type="xsd:string"/> 13

<xsd:element name="senderID" type="xsd:string"/> 14

<xsd:element name="dateTimeSent" type="xsd:dateTime"/> 15

<xsd:element name="distributionStatus" type="statusValues"/> 16

<xsd:element name="distributionType" type="typeValues"/> 17

<xsd:element name="combinedConfidentiality" type="xsd:string"/> 18

<xsd:element name="language" type="xsd:string" minOccurs="0"/> 19

<xsd:element name="senderRole" type="valueListType" minOccurs="0" 20

maxOccurs="unbounded"/> 21

<xsd:element name="recipientRole" type="valueListType" 22

minOccurs="0" maxOccurs="unbounded"/> 23

<xsd:element name="keyword" type="valueListType" minOccurs="0" 24

maxOccurs="unbounded"/> 25

<xsd:element name="distributionReference" type="xsd:string" 26

minOccurs="0" maxOccurs="unbounded"/> 27

<xsd:element name="explicitAddress" type="valueSchemeType" 28

minOccurs="0" maxOccurs="unbounded"/> 29

<xsd:element name="targetArea" type="targetAreaType" minOccurs="0" 30

maxOccurs="unbounded"/> 31

<xsd:element name="contentObject" type="contentObjectType" 32

minOccurs="0" maxOccurs="unbounded"/> 33

</xsd:sequence> 34

</xsd:complexType> 35

</xsd:element> 36

<xsd:annotation/> 37

<xsd:annotation/> 38

<xsd:complexType name="contentObjectType"> 40

<xsd:sequence> 41

<xsd:element name="contentDescription" type="xsd:string" minOccurs="0"/> 42

<xsd:element name="contentKeyword" type="valueListType" minOccurs="0" 43

maxOccurs="unbounded"/> 44

<xsd:element name="incidentID" type="xsd:string" minOccurs="0"/> 45

<xsd:element name="incidentDescription" type="xsd:string" minOccurs="0"/> 46

<xsd:element name="originatorRole" type="valueListType" minOccurs="0" 47

maxOccurs="unbounded"/> 48

EDXL-DE 1.0 OASIS Standard 1 May 2006

<xsd:element name="consumerRole" type="valueListType" minOccurs="0" 1

maxOccurs="unbounded"/> 2

<xsd:element name="confidentiality" type="xsd:string" minOccurs="0"/> 3

<xsd:choice> 5

<xsd:element name="nonXMLContent" type="nonXMLContentType"/> 6

<xsd:element name="xmlContent" type="xmlContentType"/> 7

</xsd:choice> 8

<xsd:any namespace="##other" processContents="lax" minOccurs="0" 10

maxOccurs="unbounded" /> 11

</xsd:sequence> 13

</xsd:complexType> 14

<xsd:complexType name="nonXMLContentType"> 16

<xsd:sequence> 17

<xsd:element name="mimeType" type="xsd:string"/> 18

<xsd:element name="size" type="xsd:integer" minOccurs="0"/> 19

<xsd:element name="digest" type="xsd:string" minOccurs="0"/> 20

<xsd:element name="uri" type="xsd:anyURI" minOccurs="0"/> 21

<xsd:element name="contentData" type="xsd:base64Binary" minOccurs="0"/> 22

</xsd:sequence> 23

</xsd:complexType> 24

<xsd:complexType name="xmlContentType"> 26

<xsd:sequence> 27

<xsd:element name="keyXMLContent" type="anyXMLType" minOccurs="0" 28

maxOccurs="unbounded"/> 29

<xsd:element name="embeddedXMLContent" type="anyXMLType" minOccurs="0" 30

maxOccurs="unbounded"/> 31

</xsd:sequence> 32

</xsd:complexType> 33

<xsd:complexType name="anyXMLType"> 35

<xsd:sequence> 36

<xsd:any namespace="##other" processContents="lax" maxOccurs="unbounded"/> 37

</xsd:sequence> 38

<xsd:anyAttribute namespace="##other" processContents="lax"/> 40

</xsd:complexType> 41

<xsd:complexType name="valueListType"> 43

<xsd:sequence> 44

<xsd:element name="valueListUrn" type="xsd:string" /> 45

<xsd:element name="value" type="xsd:string" maxOccurs="unbounded"/> 46

</xsd:sequence> 47

</xsd:complexType> 48

<xsd:complexType name="valueSchemeType"> 50

EDXL-DE 1.0 OASIS Standard 1 May 2006

<xsd:sequence> 1

<xsd:element name="explicitAddressScheme" type="xsd:string"/> 2

<xsd:element name="explicitAddressValue" type="xsd:string" 3

maxOccurs="unbounded"/> 4

</xsd:sequence> 5

</xsd:complexType> 6

<xsd:complexType name="targetAreaType"> 8

<xsd:sequence> 9

<xsd:element name="circle" type="xsd:string" minOccurs="0" 10

maxOccurs="unbounded"/> 11

<xsd:element name="polygon" type="xsd:string" minOccurs="0" 12

maxOccurs="unbounded"/> 13

<xsd:element name="country" type="xsd:string" minOccurs="0" 14

maxOccurs="unbounded"/> 15

<xsd:element name="subdivision" type="xsd:string" minOccurs="0" 16

maxOccurs="unbounded"/> 17

<xsd:element name="locCodeUN" type="xsd:string" minOccurs="0" 18

maxOccurs="unbounded"/> 19

</xsd:sequence> 20

</xsd:complexType> 21

<xsd:simpleType name="statusValues"> 23

<xsd:restriction base="xsd:NMTOKEN"> 24

<xsd:enumeration value="Actual"/> 25

<xsd:enumeration value="Exercise"/> 26

<xsd:enumeration value="System"/> 27

<xsd:enumeration value="Test"/> 28

</xsd:restriction> 29

</xsd:simpleType> 30

<xsd:simpleType name="typeValues"> 32

<xsd:restriction base="xsd:NMTOKEN"> 33

<xsd:enumeration value="Report"/> 34

<xsd:enumeration value="Update"/> 35

<xsd:enumeration value="Cancel"/> 36

<xsd:enumeration value="Request"/> 37

<xsd:enumeration value="Response"/> 38

<xsd:enumeration value="Dispatch"/> 39

<xsd:enumeration value="Ack"/> 40

<xsd:enumeration value="Error"/> 41

<xsd:enumeration value="SensorConfiguration"/> 42

<xsd:enumeration value="SensorControl"/> 43

<xsd:enumeration value="SensorStatus"/> 44

<xsd:enumeration value="SensorDetection"/> 45

</xsd:restriction> 46

</xsd:simpleType> 47

</xsd:schema> 48

EDXL-DE 1.0 OASIS Standard 1 May 2006

Appendix B. EDXL-DE Examples 1

B.1 EDXL-DE With CAP Payload 2

The following is a speculative example in the form of an EDXL-DE XML message. 3

<EDXLDistribution xmlns="urn:oasis:names:tc:emergency:EDXL:DE:1.0"> 4

<distributionID>ieam_e3_2</distributionID> 5

<senderID>XML2005</senderID> 6

<dateTimeSent>2005-11-15T16:53:00-05:00</dateTimeSent> 7

<distributionStatus>Exercise</distributionStatus> 8

<distributionType>Update</distributionType> 9

<keyword> 10

<valueListUrn>http://www.niem.gov/EventTypeList</valueListUrn> 11

<value>Explosion</value> 12

</keyword> 13

<targetArea> 14

<polygon>33.4745,-112.1174 33.4745,-112.0238 33.4238,-112.0238 33.4238,-112.1174 33.4745,-15

112.1174 </polygon> 16

</targetArea> 17

<contentObject> 18

<contentDescription>CAP message from DOT advising best alternate Routes 19

</contentDescription> 20

<xmlContent> 21

<embeddedXMLContent> 22

<alert xmlns = "urn:oasis:names:tc:emergency:cap:1.1"> 23

<identifier>Vendor generated</identifier> 24

<sender>AZ DOT</sender> 25

<sent>2005-11-15T16:58:00-05:00</sent> 26

<status>Exercise</status> 27

<msgType>Update</msgType> 28

<scope>Public</scope> 29

<info> 30

<category>Transport</category> 31

<event>Traffic Routes</event> 32

<urgency>Immediate</urgency> 33

<severity>Moderate</severity> 34

<certainty>Likely</certainty> 35

<description>Traffic adjustments ensure clear routes to St. Josephs Hospital 36

and Phoenix Childrens Hospital on Thomas Rd. </description> 37

<area> 38

<areaDesc>Best Routes</areaDesc> 39

<polygon>38.91655012246089,-77.02016267943407 38.91655012246089,-40

77.0117098391165 38.907662564641285,-77.0117098391165 38.907662564641285,-77.02016267943407 41

38.91655012246089,-77.02016267943407 </polygon> 42

</area> 43

</info> 44

</alert> 45

</embeddedXMLContent> 46

</xmlContent> 47

</contentObject> 48

</EDXLDistribution> 49

EDXL-DE 1.0 OASIS Standard 1 May 2006

B.2 EDXL-DE With Multiple Encrypted Payloads 1

The following is a speculative example in the form of an EDXL-DE XML message. 2

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

<EDXLDistribution xmlns="urn:oasis:names:tc:emergency:EDXL:DE:1.0"> 4

<distributionID>Sandia001</distributionID> 5

<senderID>[email protected]</senderID> 6

<dateTimeSent>2005-08-07T18:05:00-07:00</dateTimeSent> 7

<distributionStatus>Actual</distributionStatus> 8

<distributionType>Report</distributionType> 9

<senderRole> 10

<valueListUrn>urn:sandia:gov:sensors:senderRole</valueListUrn> 11

<value>SENTRY sensor managment system</value> 12

</senderRole> 13

<!-- 14

This demonstrates the provison to allow multiple values under the same 15

Value List. <value> is repeated three times, since Warning and reporting 16

systems want CAP content, Hazard Prediction systems want detailed sensor 17

outputs, and situational awareness systems want the location and type of event. 18

--> 19

<recipientRole> 20

<valueListUrn>urn:sandia:gov:sensors:reciepentRole</valueListUrn> 21

<value>Warning and Reporting Devices</value> 22

<value>Hazard Prediction applications</value> 23

<value>Situational Awarness applications</value> 24

</recipientRole> 25

<!-- 27

This key word can be used by subscribing systems or applications 28

to get distribution of one or more of the enclosed <contentObject> 29

container elements. 30

--> 31

<keyword> 33

<valueListUrn>urn:sandia:gov:sensors:keywords</valueListUrn> 34

<value>SNM Detection</value> 35

</keyword> 36

<!-- 38

The elements explicitAddress used in this example are DMIS COGs and e-mail. 39

Routing of EDXL Distribution is just being designed and there are no good 40

way to show real scheme in this example. 41

--> 42

<explicitAddress> 43

<scheme>DMIS COGs</scheme> 44

<value>1734</value> 45

<value>3520</value> 46

</explicitAddress> 47

<explicitAddress> 49

<scheme>e-mail</scheme> 50

<value>[email protected]</value> 51

</explicitAddress> 52

<!-- In a real messaging system this would probably be FOUO or higher 54

based on the sensitivity of a SNM detection. The current confidentiality 55

is all unclassified in this example for distribution purposes. 56

--> 57

<combinedConfidentiality>Unclassified</combinedConfidentiality> 58

60

<targetArea> 61

<!-- 62

These need to have the correct ISO 3166 codes added 63

--> 64

<country>US</country> 65

<subdivision>California</subdivision> 66

EDXL-DE 1.0 OASIS Standard 1 May 2006

<locCodeUN>USA-SF</locCodeUN> 1

</targetArea> 2

<!-- 4

This is a XLST transformed CAP 1.0 message for legacy systems. The message is used by 5

publish/subscription software like NuParadigm Foundation engine in the DoD Alerting Framework. 6

Legacy Warning and reporting systems would not be able to process a CAP 1.1 7

message and therefore a transform was accomplished. 8

Most recent information is added to the begining of the Distribution in this example to 10

allow rapid determination of most recent key <contentObject> container elements. 11

--> 12

<contentObject> 13

14

<contentKeyword> 15

<valueListUrn>"urn:sandia:gov:sensor:detection.event.id"</valueListUrn> 16

<value>10.2.2.1:2005-08-07T18:00:00Z</value> 17

</contentKeyword> 18

<!-- 19

This could be eliminated since it provides no distribution value but was retained 20

to demonstrate the <keyXMLContent> would have to be transformed in CAP 1.1 to CAP 1.0 21

Conversions 22

--> 23

<confidentiality>Unclassified</confidentiality> 24

<xmlContent> 25

<embeddedXMLContent xmlns:cap1.0="http://www.incident.com/cap/1.0"> 26

<EncryptedData xmlns="http://www.w3.org/2001/04/xmlenc#" 27

Type="http://www.w3.org/2001/04/xmlenc#Element"> 28

<EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/> 29

<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#"> 30

<KeyName>deskey.bin</KeyName> 31

</KeyInfo> 32

<CipherData> 33

<CipherValue>GSCinwYBtwJxp6kcZPGqE6rybCfsnvI6Lz+IZVPqnRfnI1hWq7cI2WT4BsjBBQCu 34

TE68pCQ/keOGtvYJ5yNVZEuAnIhOf37OEiqk1rcBARXb03LCYvlXYKA1zmEC5yFT 35

CUcyCMV146G4eNU1H7F+wbMjbSgHjOYgYe+rpjOVYAK9Gs4Uj+CWhijjxpr5Y/vX 36

1NEtHFhLsXC9cSfhXWVmi3veXwbDycC+QtcvQL/Rfr45bDwsJnCCutTzfmoqF1CS 37

BgYUi6osW+XhoRkAttzKbRADVZ6bG5SMkZN0SKiwSaCyKyMKjdpiQwYQhjUXUoAn 38

veBylXREqfmtOIm/pT7Y45pabWNG9l3aljil8P7qZ5Y26Q0X+i0U+eEGuafHrMVb 39

S/QBpAkNbP5/f9UR3B4t5t7hLOsvDXdR6CWFBNsrczLjZ7YC2O+g1HBl8YsQdREA 40

And3PKgoy8QlKv6ZLA+aJzQpSvzbSu3btgN6vyF3GGPqKprVIYRFouaJHYgL81zn 41

zZovnH4lubwa+YPgD0H48a/FM2LaA8euPzMFDWIki0fm5DoZZzYCmPKmfLJS10RG 42

lUKzW0svDw8I1AwX6LBssPm+hoBa7HzTnuM40FD+vsmET+p0bqBtaUSnDHrHXLzp 43

P6TrcNr5R5cxQ4C+shwezFQDNKbioyC6m5PaTH/6qhlTmE32vP8ySnMKvL74QCfP 44

w8hTZxwq9UVLPq2WKJcI0Phc1e3HoYkBTpVk9OUf/CVaxMXGOiXReeLXGPC1IQnn 45

a6xw7ImkgeCFcY+rcttq2fE3UqWtc5R6J16/Jv666K9fgCbXRVhaBdMDYpz0GKFa 46

gMJulUK6zTtah+bidtUrF31UWAX+wqIqmDFJ1ivJaRbLEiEVCrt0jKwOjuR41dDD 47

VS5j2BuvmZ5TILnOnHFU6H4GudnwjpL01eLrwELSfKmbQmUx2A0L6NBj9SRkXXHW 48

onZV6uX+c3CR46OekvxYyMi1rxE2zQPykfh/mELRhGgyDVqtdFQwhDx2Klu+Gh2z 49

3nC51yn37laIO5KSvL5Gkb6jxFVrcUvrcp4pX5czw7/VWbxWoRPY7Bus3akhPu+I 50

/jchv7SiVRP5mX4Ewh+yeduYX+UZLo07m5zhAMtmFdiLJV9tgHVTJf7ZJ3bGWP+h 51

Et0Nl98hGV362cSRhkoLJwNmOgIpGXSMO6T5nA1MZhJ6CkCP8QV1zpKrLVJSRZRn 52

fffBjdl8CzipzjE05JVKbyfbq9I33fkWMbda+Vo9ZMiDinOee6KxnDnxll9ca9Lg 53

+dl9J0qjJz5VwnWLRCeprsOXt+LlmeHC60NJgRarhidlrfuxmONM+QZTk4ZQGIPD 54

fsk5ftJtzvHgW5G/wN7fxyLh1AqQucW13IAsmfwuJS0+HntYZVoXqGjRg1sK6snx 55

zteJJm6a2OyG/M5RvLAEVhOKWyU2+9hjzts8ySg6Qb2+KrUTRQ8JBmVBeSjR2svv 56

2AWyBYj29JAdAikX9gfGDDvTG9GqJr+jFE9mfOBtg7lsdLezQKvvNMsntm6RdSpu 57

dA3vL8uBIliGBNJZSOOKr06BXp6PjbL6Ov47EbOfvP8Vm9vKQD7PmjPaIbN1bUr9 58

V9cHUQ5h6LSecnAy/FZQMLdcamNAIhpiEgoQcwEmaa+1/wTv7LppqxZkFVQQbI2m 59

nC9Ujcd08g2Qyh+0YCHP50SbCwDe2W+CYBi7QBDdF3qt45zaZnHyRm/yXhVWCJX1 60

+0WY/+OukquhaWJ8Y0fygA1yk7Jyqqpu2XU9X0Vu8oETQlL/+37mEzy/beL9VNnr 61

eU7bfQBAnYw1CkeXs5rAcc1vllZEU22Uqg3H5saOQlEHgV1NxL+0C+A9/Q2ZsaFI 62

BDDIiH+f6+6aUno6fotGUA==</CipherValue> 63

</CipherData> 64

</EncryptedData> 65

</embeddedXMLContent> 66

</xmlContent> 67

<Signature xmlns="http://www.w3.org/2000/09/xmldsig#"> 68

<SignedInfo> 69

<CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> 70

<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> 71

EDXL-DE 1.0 OASIS Standard 1 May 2006

<Reference> 1

<Transforms> 2

<Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/> 3

</Transforms> 4

<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> 5

<DigestValue>przigAg811cHIqSXpIrFg1BGx20=</DigestValue> 6

</Reference> 7

</SignedInfo> 8

<SignatureValue>BH8MGSS9QAlgq7a7I7PF5XjKsqaDumTt3cSWxBmwErByvQuaarOgH6MMflVLkG0Y 9

tv6zaOqR6Kis4giTqtZBo8QCkGukpre2gurdi3Ws0yO3Wt8nWrcH3QAUllhocXpV 10

gXahZ8MzHc9zuJq9+bl+S72czTjS0UdCvk/MMRV/xhwZ/1QSn+ffh0s3RU6Cn1Q0 11

aYSuDtX5mAGUWAzJghKgK/qSM5jF4c233g7M4m+Rul3C+QOFBOMGmp+NodnG9b0z 12

hycJGVdUpY0a+1r0quu2pmdLZnIQVY1stWNFS3wI9RzdslwzoGP9/nRARGS0kLf1 13

De+WB4Xdar48A9WJwng0iA==</SignatureValue> 14

<KeyInfo> 15

<KeyName>rsakey.pem</KeyName> 16

</KeyInfo> 17

</Signature></contentObject> 18

<!-- 19

This is the original CAP 1.1 message produced by the SENTRY system. 20

There was sufficent data to warrant the alert. 21

In reality the CAP messages would not be Public, however, It is used in this 22

for simplicity 23

--> 24

<contentObject> 25

<contentKeyword> 26

<valueListUrn>"urn:sandia:gov:sensor:detection.event.id"</valueListUrn> 27

<value>10.2.2.1:2005-08-07T18:00:00Z</value> 28

</contentKeyword> 29

<confidentiality>Unclassified</confidentiality> 30

<xmlContent> 31

<embeddedXMLContent xmlns:cap1.1="urn:oasis:names:tc:emergency:cap:1.1"> 32

<EncryptedData xmlns="http://www.w3.org/2001/04/xmlenc#" 33

Type="http://www.w3.org/2001/04/xmlenc#Element"> 34

<EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/> 35

<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#"> 36

<KeyName>deskey.bin</KeyName> 37

</KeyInfo> 38

<CipherData> 39

<CipherValue>MiKRUfL1Yb3Vw9JcewTAYVnYT3Zh2Tf9d0fhRyGreJW0FWoXr1/27AXFXBTmZC/2 40

hw9cMMFaGKeXNr1tK0Os1Lozx9uZZYoF5UiNH18KD/WnNbpwk+ttK3TwRcxBfowm 41

lzzClMn5suHeUM2PFiCll1Wup8cSfwAqptXVF3sZrLAMsQWJmGfyGYYCiaZ+P3NZ 42

hiVFamDB7D9id5HJ3qHLNcxucGNFA5TfOwe/euP7O1ah9Q7Rp2nxsXF9PaQYziSS 43

G4I/J+v+FwuJXhbLqU1PcbP4ofCLg+s6tph2kJxFArGSX9u3k7FHvp3tLZnskXCw 44

iYRGDqrSGrmLt7bTtMmF/IhFQc4x0aE4ldVEN999uQ6KnDyd22KdUJhupRH8UqZz 45

+sKVJF3+yatOsroCwOCjTe/GqnNRZNtG59dGC5D247LH2AVn/6WU+txFflZhUg0z 46

A0PElIMicguTRaEaIDGJF/QvqzTE1r3iYgHXIGfgEhQiix35ZURWUTcATrKyNFFE 47

/CD8+v6YHGbKrgeJDnvJ5AqjZSU1NajOpCtbhWQm1D878OhjCN+T689PZPB2X2nz 48

f1kupkZ/Fq6Z6aF77j0xp4wB7bpFW5ssWUHySwdg5vYw4hS3Geg5wn3AQViqTGI8 49

oRaDa3wT9byHq+cq83WqA3aroJOXzD/HQCmKNhmPFqYj503JH3aZcWNrDxHyBQRr 50

Libv4o9v4LCGviaKT/2y0S25t5KkL/MJA2c6LIngmhHKQFr1sruWgSrjHn9KtagU 51

KeYqYlgKK6s56X+PHQvusXoxpgDLjXpVVhNpF/mRh+86J4zY3JAIcfIZJQ05DjvX 52

io2iZY/hstzkTfY5+CPvKH7FmuYqeoU7Nano7+EGSB4w0TnSoDfm9D/RIsAtwdpu 53

7WonmeguEK37u0bNuXQHi9LZTELD0L2HIkPVdo4BYq26WMe5vZdwVkW6up92AIQE 54

7KvADQZZUGDVoKA3Njt9O5s6g+a14wcHqxD+FS8veacDsYFrmhs+0WYlyWtDJERL 55

+y0qtHLmSi/kTdYoKRGx+/lyUl8FIfqOnk2dk3BicbQ3kyEbngV3qHBrYqrVITTB 56

eMUKxL3wB5OkcCn3u6Nqun14QFmf8O9KEZGXZZqdQs7jz6MV3yjPvzelmLs9nbCm 57

3eXFGrSlHbbwCLQBconzDWgfoN6W/lTRv3z8RmTg+Z+3CjK2MRt6x5XZTcDqk4JW 58

wozh2btLz4Yc2xUbclbtVd3muOhBq3eSsGXC6xX4fxW0cuqi6UsOZRA2kiKJHY+V 59

2KFO9/y3x4arscIsBwfmNVZYt6bCoy/Or0yva49yV/A//8JFN7aGLh530Dt53J4H 60

bcsQ1n3q7kxir5VLuNj0aZYHjtGu7gzPa1UpPAJ0trqro4qinspnkdRueW7SQYcd 61

ufF5OG4GMTI+VjX4MnOMOgnYiAaZqrBoH3B5t7bAKeszVPs6S9NPfkzx1nkqminG 62

/Z/hBpmsFlcUlS+qylXU7umHvssE2juap1NQUaL6IyHQ0tZzsQd0e6mYkDuzNNbH 63

4l9czPXXXfvcKRJnJ0Yho9j30YfBWyllF67SMewYhcNg35tAbstXe+Ghg+D/TVcd 64

SZ4r1Cmk49IQE3SNwIO6vGUtMhmCJGq+yJx89lfMLijZRBr18exdQ1hoVeQ+YzyY 65

rZ/e6PTZHVkbcHGLsd+InyBdz3MTCmaYLGGG6gGtL42nJYmXDUIwWTAFXcWo0jDh 66

HO28OimZg8QGhiSAAc8uXzwbtjVHIJTC27e6iqldNxnYDoNWDZxVjI3fccbvUwmz 67

702I+4Kb/n5M1X5RXeMZ12OvlRRnQi7nhZuTeTMEbRizHptWP5yse3LcNjRJ2Jr2</CipherValue> 68

</CipherData> 69

</EncryptedData> 70

</embeddedXMLContent> 71

EDXL-DE 1.0 OASIS Standard 1 May 2006

</xmlContent> 1

<Signature xmlns="http://www.w3.org/2000/09/xmldsig#"> 2

<SignedInfo> 3

<CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> 4

<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> 5

<Reference> 6

<Transforms> 7

<Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/> 8

</Transforms> 9

<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> 10

<DigestValue>N7NvgXfahdGZPjb9o0XvwejLI5o=</DigestValue> 11

</Reference> 12

</SignedInfo> 13

<SignatureValue>Tg8zP+/1Cg/3MR9iSareJb7snexQ3DjBxGSL3xH+Kf3Kh5NQq/Uwagw/fmI2wcxc 14

ac/2fz893HeTkXGn8mShg+wmdoRwNykp5uHPtAzcFBKlh3v7FemtM9M73XbX7KsY 15

fM0J+RTHUxp4tTMYUPogSEJWiSGSGVbp+MALtUH799fGqqqOREyuljfVIlLvvCog 16

wOd6n7J8S2sHjyRXEw5AVFnxL6k02TgjztbEuoLu+qvEZOIGXmj9yfy4nj41RNXe 17

HMOS1IAcOQgx5vNzju2slFIWzlmvjqq+7aVg5hy0yBiXJuljvigTOxrwHScaYW8o 18

HDpQHwM6EXbgW3uaWnf9Kg==</SignatureValue> 19

<KeyInfo> 20

<KeyName>rsakey.pem</KeyName> 21

</KeyInfo> 22

</Signature></contentObject> 23

<contentObject> 24

<contentDescription>Photo image from Sensor: RADDET-01, Site: Golden Gate Bridge, having a 25

Detection class of SNM</contentDescription> 26

<contentKeyword> 27

<valueListUrn>"urn:sandia:gov:sensor:detection.event.id"</valueListUrn> 28

<value>10.2.2.1:2005-08-07T18:00:00Z</value> 29

</contentKeyword> 30

<confidentiality>Unclassified</confidentiality> 31

<nonXMLContent> 32

<mimeType>image/jpeg</mimeType> 33

<uri>http://sentry/photoCapture/10.2.2.1:2005-08-07T18:00:00Z</uri> 34

</nonXMLContent> 35

<Signature xmlns="http://www.w3.org/2000/09/xmldsig#"> 36

<SignedInfo> 37

<CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> 38

<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> 39

<Reference> 40

<Transforms> 41

<Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/> 42

</Transforms> 43

<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> 44

<DigestValue>io7Katgoo77YNfQYdZMB8taoeKg=</DigestValue> 45

</Reference> 46

</SignedInfo> 47

<SignatureValue>AjQXGgp9h5TC2D+bh9w59sbmtUpgE/IeZVdDQM+zi58XT2RPb7OXAAABni78WduA 48

uP6nxL6k+BBo4G+TgaqWvCQIqdlDO+qyMnM0ExPui5eg00jstbwiSeYxSt2VQqS2 49

RD2vR811at0XwIkMpugSftKNJBZgB9mhRqQgP+E0nDJJPNYDz0bLJjp0J/EDxn4H 50

6qx6GpDKgDc//53jVhOb4zZPIERsTLjPxpOOnBK31cs5Rf6vU9MyOOBTHZgpvoza 51

muhejW1CIJfYjd/OoKQ9Hiv4MCX4v/dX7n6ePHZaDxNeCccDIjoVYrAHEWxQ9hE6 52

rqriugNLZ3Lh8sUzhZLTyg==</SignatureValue> 53

<KeyInfo> 54

<KeyName>rsakey.pem</KeyName> 55

</KeyInfo> 56

</Signature></contentObject> 57

<!-- This is the based 64 encode image of the Suspect vehicle with SNM. 58

This data is provide for Law Enforcement senstive systems to redistribute 59

on private systems which do not have intenet access. 60

--> 61

<contentObject> 62

<contentDescription>Photo image from Sensor: RADDET-01, Site: Golden Gate Bridge, having a 63

Detection class of SNM</contentDescription> 64

<contentKeyword> 65

<valueListUrn>"urn:sandia:gov:sensor:detection.event.id"</valueListUrn> 66

<value>10.2.2.1:2005-08-07T18:00:00Z</value> 67

</contentKeyword> 68

<confidentiality>Unclassified</confidentiality> 69

<nonXMLContent> 70

<mimeType>image/jpeg</mimeType> 71

EDXL-DE 1.0 OASIS Standard 1 May 2006

<contentData> 1

/9j//gAoaAkAAAAAAECMWv/mOzNdGAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD/2wBDAAgGBgcGBQgH 2

BwcJCQgKDBQNDAsLDBkSEw8UHRofHh0aHBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/ 3

AYG3nGaeEI5BoACp6gmmgKwOBzQBFICRUZXIwOKAE8sjmms5Uc0AU5JwTioxLjpQBHIc5qpJQBGr 4

YNSgjFACbuacQCtAEIXDVOOlACgUuAaAG4xVbUP+Qdc/9czQB//Z 5

</contentData> 6

</nonXMLContent> 7

<Signature xmlns="http://www.w3.org/2000/09/xmldsig#"> 8

<SignedInfo> 9

<CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> 10

<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> 11

<Reference> 12

<Transforms> 13

<Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/> 14

</Transforms> 15

<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> 16

<DigestValue>PkrjafcKUd027EETVu5JwqlubcA=</DigestValue> 17

</Reference> 18

</SignedInfo> 19

<SignatureValue>NvqlkBLs4GpM+t+uoWQ53rmjNT43qdwbMsEoiB0a2BRwqkmynKQDbA2eIHmxfBfo 20

xe+q+15v/2IGQQw+5XmWtMx8QIQkGBElSdlybOKibxBqNuWH+J6yR1mIA6bOmBE+ 21

+F2zA9DuvKZVLa8El1pUGke6FeIzoMC7TdDcBtmSAkRMXxe8MjxjxApM3vnMSt9A 22

iCo2EUx4qYf82iJ9FX7vIFFfL2QW38RvZqY+rjXsHV5OK3fkTPFI+ZE5lIrHKjb3 23

gu409JrdNtSy/wLd/WLypiYFNDZXxT6i5wBbdAvBkQ0jHECOJjfN+h1bHkvT4wLX 24

Cpc26QQ6Ic3goSLojC3rjw==</SignatureValue> 25

<KeyInfo> 26

<KeyName>rsakey.pem</KeyName> 27

</KeyInfo> 28

</Signature></contentObject> 29

<!-- 30

The following content object contains the readings from a UNWD radiation Portal 31

The Detection ID is being used to correlate other contentObject container elements to 32

the data found in this detection 33

Because there is no provision for Location information in the current metadata situational 35

awareness systems would have to extract location for the contents of related CAP messges. 36

--> 37

</EDXLDistribution> 39

EDXL-DE 1.0 OASIS Standard 1 May 2006

Appendix C. Acknowledgments 1

C.1 OASIS Emergency Management Technical Committee: 2

• Patti Aymond, IEM 3

• Art Botterell, Individual 4

• Rex Brooks, HumanMarkup.org, Inc. 5

• Len Bullard, Individual 6

• Mark Carlson, Conneva, Inc. 7

• Eliot Christian, US Department of the Interior 8

• James Bryce Clark, OASIS 9

• Robin Cover, OASIS 10

• David Danko, ESRI 11

• Sukumar Dwarkanath, Individual 12

• David, Ellis, Individual 13

• Jack Fox, US Department of Homeland Security 14

• Tim Grapes, Science Applications International Corporation 15

• Gary Ham, Disaster Management Interoperability Services 16

• Adam Hocek, Individual 17

• Travis Hubbard, Disaster Management Interoperability Services 18

• Renato Iannella, NICTA 19

• Elysa Jones, Warning Systems, Inc. 20

• Jeff Kyser, Warning Systems, Inc. 21

• Mary McRae, OASIS 22

• Tom Merkle, Lockheed Martin 23

• Gary Poindexter, Individual 24

• Michelle Raymond, Individual 25

• Carl Reed, Open GIS Consortium (OGC) 26

• Julia Ridgely, Individual 27

• Eleanor Robinson, Anteon Corporation 28

• Kwasi Speede, Anteon Corporation 29

• Aaron Temin, Individual 30

• Lee Tincher, Science Applications International Corporation 31

• Brett Trusko, OASIS 32

• Richard Vandame, US Department of Homeland Security 33

• Sylvia Webb, Individual 34

• Konstantin Wilms, Individual 35

EDXL-DE 1.0 OASIS Standard 1 May 2006

Appendix D. Revision History 1

Revision Date Editor Changes Made