The primary purpose of the Distribution Element is to facilitate the routing of any properly formatted XML emergency message to recipients. 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 ID’s.

The Disaster Management eGov Initiative of the Department of Homeland Security (DHS) determined in 2004 to launch a project to develop interagency emergency data communications standards. It called together a group of national emergency response practitioner leaders and sought their guidance on requirements for such standards. In June, 2004 the first such meeting identified the need for a common distribution element for all emergency messages. Subsequent meetings of a Standards Working Group developed detailed requirements and a draft specification for such a distribution element (DE).

During the same period the DM Initiative was forming a partnership with industry members of the Emergency Interoperability Consortium (EIC) to cooperate in the development of emergency standards. EIC had been a leading sponsor of the Common Alerting Protocol (CAP). Both organizations desired to develop an expanded family of data formats for exchanging operational information beyond warning.

EIC members participated in the development of the DE, and in the broader design of the design of a process for the development of additional standards. This was named Emergency Data Exchange Language (EDXL).

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 is involved. It is not just an "emergency management" domain exercise.

It is a national effort including a diverse and representative group of local, state and federal emergency response organizations and professionals, following a multi-step process. Just as a data-focused effort targets shared data elements, the EDXL process looks for shared message needs, which are common across a broad number of organizations. The objective is to rapidly deliver implementable standard messages, in an incremental fashion, directly to emergency response agencies in the trenches, providing seamless communication and coordination supporting each particular process. The effort first addresses the most urgent needs and proceeds to subsequent message sets in a prioritized fashion. The goal is to incrementally develop and deliver standards.

EDXL is intended as a suite of emergency data message types including resource queries and requests, situation status, message routing instructions and the like, needed in the context of cross-disciplinary, cross-jurisdictional communications related to emergency response.

The priorities and requirements are created by the DM EDXL Standards Working Group (SWG) which is a formalized group of emergency response practitioners, technical experts, and industry.

The draft DE specification was trialed by a number of EIC members starting in October, 2004. In November, 2004, EIC formally submitted the draft to the OASIS Emergency Management Technical Committee for standardization.

The EDXL Distribution Element (DE) comprises an <EDXLDistribution> element as described hereafter, optional <targetArea> elements describing geospatial or political target area for message delivery, and a set of <contentObject> elements each containing specific information regarding a particular item of content. The included content may be any XML or other content type or a URI to access the content.

The <EDXLDistribution> block may be used without content to form the body of a routing query to, or response from, a directory service.

The <EDXLDistribution> element asserts the originator”s intent as to the dissemination of that particular message or set of messages.

The <targetArea> is a container element for the geo-spatial or political area targeting of the message content. It contains data necessary to the originator's intent, based on location targeting, as to the dissemination of that particular message or set of messages.

The primary use of the EDXL Distribution Element is to identify and provide information to enable the routing of encapsulated payloads, called Content Objects. It is used to provide a common mechanism to encapsulate content information.

EDXL General Functional Requirements

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

• Provide an Open Container Model to enable dissemination of one or more emergency messages
• Provide flexible mechanisms to inform message routing and/or processing decisions
• Enable dissemination of messages based on geographic delivery area
• Use and re-use of data content and models developed by other initiatives
• Business process-driven specific messaging needs across emergency professions
• Supporting everyday events and incident preparedness, as well as disasters
• Facilitate emergency information sharing and data exchange across the local, state, tribal, national and non-governmental organizations of different professions that provide emergency response and management services
• Multi-use format - One message schema supports multiple message types (e.g., alert / update / cancellations / acknowledgments / error messages) in various applications (actual / exercise / test / system message.)

The Distribution Element specification should:

1. Define a single compound XML structure (or an equivalent single structure if transcoded into another format) including the required and optional elements defined below.
2. Specify a desired geographic delivery area, expressed in geospatial coordinates or using political/administrative codes
3. Allow the ability to encapsulate multiple message elements
4. Take a modular approach to the enumerations of element values which may evolve over time, e.g. by referring to a separate schema for those enumerations.
5. Specify unique distribution and sender identifiers
6. Specify the date and time the distribution was sent
7. Specify the actionability of the distribution message (e.g., real-world, test, exercise)
8. Specify the functional type of the distribution message (e.g., report, request, update, cancellation, etc.)
9. Specify that the following elements may be present in a valid Content Object Element:
   1. A specification of the format of the distribution message (e.g., the URI of an XML Schema for the message)
   2. The functional role and/or type of the sender of the distribution message
   3. One or more functional role and/or type of desired recipients of the distribution message
   4. A reference to one or more previous distribution messages
   5. One or more types of response activity involved
   6. A reference to the type of incident
   7. One or more characterization of the etiology of the subject event or incident (e.g., terrorism, natural, under investigation, etc.)
   8. The incident name or other identifier of one or more event or incident
   9. A reference to one or more response types.
   10. One or more specific recipient addresses (as a URI)
   11. Specify an assertion of the confidentiality level of the combined Content Object Elements.
10. In addition, the Content Objects contained within the Distribution Element SHOULD:
    1. Allow the encapsulation of one or more content objects in each of the Content Objects.
    2. Specify the functional role and/or type of the sender of each Content Object
    3. Specify one or more functional roles and/or types of desired recipients of each Content Object
    4. Specify an assertion of the confidentiality level of each Content Object.
11. Provide or refer to specific lists (enumerations) of values and their definitions for:
    1. Types of incidents
    2. Types of hazards and/or events
    3. Types of agencies
    4. Types of response activity
    5. The functional role and/or type of the sender
    6. The functional roles and/or types of desired recipients
    7. The incident name or other identifier of one or more event or incident

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

2.3.1 Distribution of Emergency Message/s or alerts based on Geographic Delivery Area and Incident Type

The terror alert level has been raised to RED. Credible intelligence indicates that terrorist groups in the Mid-Atlantic region are seeking to conduct an attack in the next 48 hours. The Department of Homeland Security sends an emergency alert message, and using the Distribution Element, distributes it to all emergency agencies in the specified area.

2.3.2 Encapsulation and Distribution of one or more emergency messages or alerts or notifications

A Radiological sensor triggered at a prominent Tunnel toll booth. Radiation alarm levels indicates possible dirty bomb. Authorities decide to send multiple messages to a number of jurisdictions. They send an EDXL Distribution Element with two encapsulated CAP messages. The first one notifies the area where the sensor has been triggered. The second one is an alert to emergency response agencies that the state EOC has been activated, and requests the agencies to be on alert.

2.3.3 Distribution of Resource Messages or Reports

The Local EOC has a need for additional resource/support, but is unsure what specifically to request. A free-form request for information and resource availability is prepared, and is sent to the state EOC and other organizations (person to person) using the Distribution Element. The Local EOC receives an acknowledgment message from the State EOC, and a request for Information on additional details of the requested resource. Both of these messages are contained within a single Distribution Element.

2.3.4 Distribution of well-formed XML messages

A huge crash, involving a car and a HAZMAT truck, occurs at a busy junction on an inter-state freeway. Separate automatic notifications of both the car crash and the HAZMAT carrier are sent using the Vehicular Emergency Data Set (VEDS), contained in the Distribution Element. The Transportation Management Center (TMC) shares information (related to the above incident) with the adjacent TMC, using the IEEE 1512 Incident Management Message Set. These set of messages are exchanged using the EDXL Distribution Element.

Bold indicates required element.
* indicates multiple instances allowed

The Distribution Message element, <EDXLDistribution> is the container element for all data necessary to the originator’s intent as to the dissemination of the contained message or set of messages.

The <targetArea> is a container element for the geospatial or political area targeting of the message content. It indicates the originator’s intent based on location targeting as to the dissemination of that particular message or set of messages.

<?xml version="1.0" encoding="UTF-8"?> <schema xmlns="http://www.w3.org/2001/XMLSchema" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:ed="urn:oasis:names:tc:emergency:EDXL:DE:1.0" targetNamespace="urn:oasis:names:tc:emergency:EDXL:DE:1.0" elementFormDefault="qualified" attributeFormDefault="unqualified"> <!-- In a closed system where all content must be validated imports of allowed namespaces could be included: <import namespace="urn:oasis:names:tc:emergency:cap:1.1" schemaLocation="file://c://schemas//CAP1_1.xsd" /> <import namespace="http://www.incident.com/cap/1.0" schemaLocation="file://c://schemas//CAP1_0.xsd" /> <import namespace="http://www.dtra.mil/acrs/event" schemaLocation="file://c://schemas//UNWDSensorEvent.xsd" /> --> <element name="EDXLDistribution"> <annotation> <documentation> The container of all of the elements related to the distribution of the content messages. </documentation> <documentation> 1. The <EDXLDistribution> element MAY include <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. </documentation> </annotation> <complexType> <sequence> <element name="distributionID" type="xsd:string" minOccurs="1" maxOccurs="1"> <annotation> <documentation> The unique identifier of this distribution message. </documentation> <documentation> 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. </documentation> </annotation> </element> <element name="senderID" type="xsd:string" minOccurs="1" maxOccurs="1"> <annotation> <documentation> The unique identifier of the sender. </documentation> <documentation> 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. MUST be a properly formed -escaped if necessary- XML string. Examples: dispatcher@centerville.gov, 0006.0e39.ad80@petroplant </documentation> </annotation> </element> <element name="dateTimeSent" type="xsd:dateTime" minOccurs="1" maxOccurs="1"> <annotation> <documentation> The date and time the distribution message was sent. </documentation> <documentation> 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 </documentation> </annotation> </element> <element name="distributionStatus" minOccurs="1" maxOccurs="1"> <annotation> <documentation> The actionability of the message. </documentation> <documentation> Value must be one of: Actual - "Real-world" information for action Exercise - Simulated information for exercise participants System - Messages regarding or supporting network functions Test - Discardable messages for technical testing only </documentation> </annotation> <simpleType> <restriction base="xsd:string"> <enumeration value="Actual"/> <enumeration value="Exercise"/> <enumeration value="System"/> <enumeration value="Test"/> </restriction> </simpleType> </element> <element name="distributionType" minOccurs="1" maxOccurs="1"> <annotation> <documentation> The function of the message. </documentation> <documentation> Value must be one of: Report - New information regarding an incident or activity Update - Updated information superseding a previous message Cancel - A cancellation or revocation of a previous message Request - A request for resources, information or action Response - A response to a previous request Dispatch - A commitment of resources or assistance Ack - Acknowledgment of receipt of an earlier message Error - Rejection of an earlier message (for technical reasons) </documentation> </annotation> <simpleType> <restriction base="xsd:string"> <enumeration value="Ack"/> <enumeration value="Cancel"/> <enumeration value="Dispatch"/> <enumeration value="Error"/> <enumeration value="Report"/> <enumeration value="Request"/> <enumeration value="Response"/> <enumeration value="Update"/> </restriction> </simpleType> </element> <element name="senderRole" minOccurs="0" maxOccurs="unbounded"> <annotation> <documentation> The functional role of the sender, as it may determine message routing decisions. </documentation> <documentation> 1. The list and associated value(s) is in the form: <senderRole> <valueListUrn>valueListUrn</valueListUrn> <value>value</value> <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 each <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> structure. 3. Multiple instances of <senderRole> MAY occur within a single <EDXLDistribution> block. </documentation> </annotation> <complexType> <sequence> <element ref="ed:valueListUrn" minOccurs="1" maxOccurs="1"> <annotation> <documentation> The content of <valueListUrn> is the Uniform Resource Name of a published list of values and definitions. </documentation> </annotation> </element> <element ref="ed:value" minOccurs="1" maxOccurs="unbounded"> <annotation> <documentation> The content of <value> is a string (which may represent a number) denoting the value itself. </documentation> </annotation> </element> </sequence> </complexType> </element> <element name="recipientRole" minOccurs="0" maxOccurs="unbounded"> <annotation> <documentation> The functional role of the recipient, as it may determine message routing decisions. </documentation> <documentation> 1. The list and associated value(s) is in the form: <recipientRole> <valueListUrn>valueListUrn</valueListUrn> <value>value</value> <value>value</value> </reciepientRole> where the content of <valueListUrn> is the Uniform Resource Name of a published list of values and definitions, and the content of each <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> structure. 3. Multiple instances of <recipientRole> MAY occur within a single <EDXLDistribution> block. </documentation> </annotation> <complexType> <sequence> <element ref="ed:valueListUrn" minOccurs="1" maxOccurs="1"> <annotation> <documentation> The content of <valueListUrn> is the Uniform Resource Name of a published list of values and definitions. </documentation> </annotation> </element> <element ref="ed:value" minOccurs="1" maxOccurs="unbounded"> <annotation> <documentation> The content of <value> is a string (which may represent a number) denoting the value itself. </documentation> </annotation> </element> </sequence> </complexType> </element> <element name="keyword" minOccurs="0" maxOccurs="unbounded"> <annotation> <documentation> The topic related to the distribution message, as it may determine message routing decisions. </documentation> <documentation> 1. The list and associated value(s) is in the form: <keyword> <valueListUrn>valueListUrn</valueListUrn> <value>value</value> <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 each <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> structure. 3. Multiple instances of <keyword> MAY occur within a single <EDXLDistribution> block. Examples of things <keyword> might be used to describe include event type, event etiology, incident ID and response type. </documentation> </annotation> <complexType> <sequence> <element ref="ed:valueListUrn" minOccurs="1" maxOccurs="1"> <annotation> <documentation> The content of <valueListUrn> is the Uniform Resource Name of a published list of values and definitions. </documentation> </annotation> </element> <element ref="ed:value" minOccurs="1" maxOccurs="unbounded"> <annotation> <documentation> The content of <value> is a string (which may represent a number) denoting the value itself. </documentation> </annotation> </element> </sequence> </complexType> </element> <element name="explicitAddress" minOccurs="0" maxOccurs="unbounded"> <annotation> <documentation> The identifier of an explicit recipient. </documentation> <documentation> Identifies human parties, systems, services, or devices that are all potential recipients of the distribution message. </documentation> </annotation> <complexType> <sequence> <element name="explicitAddressScheme" type="xsd:string" minOccurs="1" maxOccurs="1"> <annotation> <documentation> Identifies the distribution addressing scheme used. </documentation> <documentation> MUST be a properly formed -escaped if necessary- XML string. Examples for this type of distribution includes - email, military USMTF, etc . . . </documentation> </annotation> </element> <element name="explicitAddressValue" type="xsd:string" minOccurs="1" maxOccurs="unbounded"> <annotation> <documentation> A properly formed -escaped if necessary- XML string denoting the addressees value. </documentation> </annotation> </element> </sequence> </complexType> </element> <element name="distributionReference" type="xsd:string" minOccurs="0" maxOccurs="unbounded"> <annotation> <documentation> A reference to a previous distribution message. </documentation> <documentation> 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 </documentation> </annotation> </element> <element name="combinedConfidentiality" type="xsd:string" minOccurs="0" maxOccurs="1"> <annotation> <documentation> Confidentiality of the combined distribution message's content. </documentation> <documentation> 1. The <combindedConfidentiality> indicates the confidentiality of the combined <messageObject> sub-elements. Generally the combined confidentiality is the most restrictive of the <confidentiality> elements in the container <messageObject> element, but it can be more restrictive than any of the individual <confidentiality> elements. 2. If this element is not present, all content messages are assumed to be unclassified and not sensitive. 3. The <combindedConfidentiality> element MUST be present if a <confidentiality> element is present in any of the <contentObject> elements. 4. Application specific mechanisms will be required to determine the minimum confidentiality level in cases where different confidentiality schemes are used in the <contentObject>. 5. MUST be a properly formed -escaped if necessary- XML string. </documentation> </annotation> </element> <element name="targetArea" minOccurs="0" maxOccurs="unbounded"> <annotation> <documentation> The container element for location information. </documentation> <documentation> 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. </documentation> </annotation> <complexType> <sequence> <element name="circle" type="xsd:string" minOccurs="0" maxOccurs="unbounded"> <annotation> <documentation> An enclosed geographic area within a given radius around a geographic point. </documentation> <documentation> 1.Represented in the form "latitude, longitude radius". 2. The central point is represented by lat-long values conforming to the WGS84 coordinate reference system. 3. The fixed mandatory attribute of "urn:ogc:def:crs:OGC:1.3:CRS84" must be included. 4. The radius value is expressed in kilometers. 5. MUST be a properly formed -escaped if necessary- XML string. Example: 38.26295, -122.07454 15 </documentation> </annotation> </element> <element name="polygon" type="xsd:string" minOccurs="0" maxOccurs="unbounded"> <annotation> <documentation> An enclosed geographic area within a simple closed polygon defined by an ordered set of vertices. </documentation> <documentation> 1. Represented by a space-delimited series of latitude, longitude pairs, with the last pair identical to the first. 2. The lat-long values conform to the WGS84 coordinate reference system. 3. The fixed mandatory attribute of <urn:ogc:def:crs:OGC:1.3:CRS84> must be included. 4. 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 </documentation> </annotation> </element> <element name="country" type="xsd:string" minOccurs="0" maxOccurs="unbounded"> <annotation> <documentation> The code of the country. </documentation> <documentation> 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. </documentation> </annotation> </element> <element name="subdivision" type="xsd:string" minOccurs="0"> <annotation> <documentation> The ISO 3166-2 designator for the administrative subdivision concerned. </documentation> <documentation> 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. Examples: US-TX (U.S. State of Texas), DK-025 (Danish county Roskilde), MG-T (Antananarivo province, Madagascar) </documentation> </annotation> </element> <element name="locCodeUN" type="xsd:string" minOccurs="0" maxOccurs="unbounded"> <annotation> <documentation> The UN/LOCODE designator for the location concerned. </documentation> <documentation> 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. Examples: USFFB (Fairfield, Alabama, USA), USSUU (Fairfield, California, USA), GBFFD (Falfield, South Gloucestershire, UK) </documentation> </annotation> </element> </sequence> </complexType> </element> <element name="contentObject" minOccurs="0" maxOccurs="unbounded"> <annotation> <documentation> The container element for message data and content. </documentation> <documentation> 1. The <contentObject> element is the container element for specific messages. 2. The <contentObject> element MUST contain one of the two Content Schemes: 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 encapsalated in the message. </documentation> </annotation> <complexType> <sequence> <element name="contentDescription" type="xsd:string" minOccurs="0" maxOccurs="1"> <annotation> <documentation> The human-readable text describing the content object. </documentation> <documentation> MUST be a properly formed -escaped if necessary- XML string. Examples: "CAP message from FEMA", "Map of affected area" or "Photo of missing child". </documentation> </annotation> </element> <element name="contentKeyword" minOccurs="0" maxOccurs="unbounded"> <annotation> <documentation> The topic related to the message data and content, as it may determine message distribution and presentation decisions. </documentation> <documentation> 1. The list and associated value(s) is in the form: <contentKeyword> <valueListUrn>valueListUrn</valueListUrn> <value>value</value> <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 each <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> structure. 3. Multiple instances of <contentKeyword> MAY occur within a single <contentObject> block. Examples of things <contentKeyword> might be used to describe include message processor, event stage, resource code and response type. </documentation> </annotation> <complexType> <sequence> <element ref="ed:valueListUrn" minOccurs="1" maxOccurs="unbounded"> <annotation> <documentation> The content of <valueListUrn> is the Uniform Resource Name of a published list of values and definitions. </documentation> </annotation> </element> <element ref="ed:value" minOccurs="1" maxOccurs="unbounded"> <annotation> <documentation> The content of <value> is a string (which may represent a number) denoting the value itself. </documentation> </annotation> </element> </sequence> </complexType> </element> <element name="originatorRole" minOccurs="0" maxOccurs="unbounded"> <annotation> <documentation> The functional role of the message originator, as it may determine message distribution and presentation decisions. </documentation> <documentation> 1. The list and associated value(s) is in the form: <originatorRole> <valueListUrn>valueListUrn</valueListUrn> <value>value</value> <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 each <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> structure. 3. Multiple instances of <originatorRole> MAY occur within a single <contentObject> block. </documentation> </annotation> <complexType> <sequence> <element ref="ed:valueListUrn" minOccurs="1" maxOccurs="unbounded"> <annotation> <documentation> The content of <valueListUrn> is the Uniform Resource Name of a published list of values and definitions. </documentation> </annotation> </element> <element ref="ed:value" minOccurs="1" maxOccurs="unbounded"> <annotation> <documentation> The content of <value> is a string (which may represent a number) denoting the value itself. </documentation> </annotation> </element> </sequence> </complexType> </element> <element name="consumerRole" minOccurs="0" maxOccurs="unbounded"> <annotation> <documentation> The functional role of the message consumer, as it may determine message distribution and presentation decisions. </documentation> <documentation> 1. The list and associated value(s) is in the form: <consumerRole> <valueListUrn>valueListUrn</valueListUrn> <value>value</value> <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 each <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> structure. 3. Multiple instances of <consumerRole> MAY occur within a single <contentObject; block. Example: <valueListUrn>http://www.dhs.gov/NiemRoleType</valueListUrn> <value>ICS Operations Branch</value> </documentation> </annotation> <complexType> <sequence> <element ref="ed:valueListUrn" minOccurs="1" maxOccurs="1"> <annotation> <documentation> The content of <valueListUrn> is the Uniform Resource Name of a published list of values and definitions. </documentation> </annotation> </element> <element ref="ed:value" minOccurs="1" maxOccurs="unbounded"> <annotation> <documentation> The content of <value> is a string (which may represent a number) denoting the value itself. </documentation> </annotation> </element> </sequence> </complexType> </element> <element name="confidentiality" type="xsd:string" minOccurs="0" maxOccurs="1"> <annotation> <documentation> Special requirements regarding confidentiality of the content of this <contentObject>. </documentation> <documentation> MUST be a properly formed -escaped if necessary- XML string. </documentation> </annotation> </element> <choice id="contentContainer" minOccurs="1" maxOccurs="1"> <element name="nonXMLContent" minOccurs="1" maxOccurs="1"> <complexType> <sequence> <element name="mimeType" type="xsd:string" minOccurs="1" maxOccurs="1"> <annotation> <documentation> The format of the content. </documentation> <documentation> 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, text/xml </documentation> </annotation> </element> <element name="size" type="xsd:integer" minOccurs="0" maxOccurs="1"> <annotation> <documentation> The file size of the content object item. </documentation> <documentation> 1.Value must be in bytes and represent the raw file size (not encoded or encrypted). 2. The <size> element MUST be used to indicate the size of the embedded content when the <contentData> element is used within the <nonXMLContent>. container. 3. The <size> element MAY be used to indicate the size of the resource accessed by the URI when the <uri> element is used within the <nonXMLContent> container. </documentation> </annotation> </element> <element name="digest" type="xsd:string" minOccurs="0"> <annotation> <documentation> The digital digest ("hash") of the content item. </documentation> <documentation> 1. Used to ensure the integrity of the content object. 2. Calculated using the Secure Hash Algorithm (SHA-1) per [FIPS 180-2] 3. MUST be a properly formed -escaped if necessary- XML string. </documentation> </annotation> </element> <element name="uri" type="xsd:anyURI" minOccurs="0" maxOccurs="1"> <annotation> <documentation> A Uniform Resource Identifier that can be used to retrieve the identified resource. </documentation> <documentation> 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 a reference to a file or specifically to the file represented in the <contentData>. </documentation> </annotation> </element> <element name="contentData" type="xsd:string" minOccurs="0" maxOccurs="1"> <annotation> <documentation> The base-64 encoded data content. </documentation> <documentation> MAY be used either with or instead of the <uri> element in contexts where retrieval of a resource via a URI is not feasible. </documentation> </annotation> </element> </sequence> </complexType> </element> <element name="xmlContent" minOccurs="1" maxOccurs="1"> <complexType> <sequence> <element name="keyXMLContent" minOccurs="0" maxOccurs="unbounded"> <annotation> <documentation> A container element for collected fragments of valid XML. </documentation> <documentation> 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 <embeddedXMLContent> tag. </documentation> </annotation> <complexType> <sequence> <any namespace="##any" processContents="lax" maxOccurs="unbounded"/> </sequence> <anyAttribute namespace="##other" processContents="lax"/> </complexType> </element> <element name="embeddedXMLContent" minOccurs="1" maxOccurs="1"> <annotation> <documentation> The Content XML element is an open container for valid XML from an explicit namespaced XML Schema. </documentation> <documentation> 1. The enclosed XML content MUST be explicitly namepaced as defined in the enclosing <xmlContent> container. 2. Enclosed XML content may be encrypted and/or signed within this element. </documentation> </annotation> <complexType> <sequence> <any namespace="##any" processContents="lax" maxOccurs="unbounded"/> </sequence> <anyAttribute namespace="##other" processContents="lax"/> </complexType> </element> </sequence> <anyAttribute namespace="##other" processContents="lax" /> </complexType> </element> </choice> </sequence> </complexType> </element> </sequence> </complexType> </element> <element name="valueListUrn" type="xsd:string"> <annotation> <documentation> The name of the certified list maintained by the Community of Interest (COI) for the value referenced. </documentation> </annotation> </element> <element name="value" type="xsd:string"> <annotation> <documentation> A value from a certified list maintained by the Community of Interest (COI) for the referenced element. </documentation> </annotation> </element> </schema>

OASIS Emergency Management Technical Committee:

• John Aerts, LA County Information Systems Advisory Body
• Patti Aymond, IEM
• William Beavin, The Boeing Company
• Art Botterell, Individual
• Chris Branton, IEM
• Rex Brooks, HumanMarkup.org, Inc.
• Thomas Bui, The Boeing Company
• Len Bullard, Individual
• Scott Came, Individual
• Eliot Christian, US Department of the Interior
• James Bryce Clark, OASIS
• Robin Cover, OASIS
• Michael Daconta, US Department of Homeland Security
• David Danko, ESRI
• Paul Denning, Mitre Corporation
• John Dias, Lawrence Livermore National Laboratory
• Mike Dillon, Drummond Group, Inc.
• Matthew Dovey, Oxford University
• Sukumar Dwarkanath, Individual
• Scott Edson, LA County Information Systems Advisory Body
• David, Ellis, Individual
• Paul Embley, Individual
• Jeff Flading, Anteon Corporation
• Jack Fox, US Department of Homeland Security
• Lawrence Freudinger, NASA
• Tim Grapes, Science Applications International Corporation
• Gilbert Green, USAMC Logistics Support Activity
• Gary Ham, Disaster Management Interoperability Services
• Adam Hocek, Individual
• Travis Hubbard, Disaster Management Interoperability Services
• Renato Iannella, NICTA
• Stephen Jepsen, Oracle
• Elysa Jones, Warning Systems, Inc.
• Hong-Eng Koh, Sun Microsystems
• Jeff Kyser, Warning Systems, Inc.
• Louis Lagonik, Lockheed Martin
• Kim Lambert, LMI Government Consulting
• Richard Masline, IBM
• Mary McRae, OASIS
• Tom Merkle, Lockheed Martin
• Peter Miller, US Department of Homeland Security
• James Morentz, Science Applications International Corporation
• Bona Nasution, MTG Management Consultants, LLC.
• Ash Parikh, Raining Data Corporation
• Walid Ramadan, Individual
• Michelle Raymond, Honeywell ACS Labs
• Carl Reed, Open GIS Consortium (OGC)
• Kent Reed, NIST
• Julia Ridgely, Individual
• Dave Robinson, Wells Fargo
• Eleanor Robinson, Anteon Corporation
• John Ruegg, LA County Information Systems Advisory Body
• Barry Schaeffer, Individual
• William Schroeder, ESRI
• Boris Shur, US Department of Justice
• Kwasi Speede, Anteon Corporation
• William Summers, Science Applications International Corporation
• Michael Thompson, The Boeing Company
• Lee Tincher, Science Applications International Corporation
• Brett Trusko, OASIS
• Rick Tucker, Mitre Corporation
• Richard Vandame, US Department of Homeland Security
• Winfield Wagner, Crossflo Systems, Inc.
• Sylvia Webb, Individual
• Jerry Weltman, IEM
• Konstantin Wilms, Individual
• Bob Wyman Individual