advancing open standards for the information …€¦ · web viewopen standards improve...

An OASIS Emergency Management Technical Committee White Paper

The Distribution Element:The Basic Steps to Package and AddressYour Emergency Informationnt 2.0The Basic Steps to Package and Address Your Emergency InformationBy Jeff Waters and Rex BrooksOn behalf of the OASIS Emergency Management Technical Committee

Date: 13 April 2013

2

This paper provides a basic introduction to the Distribution Element 2.0 (DE2), one of the important OASIS EDXL standards for emergency management and response. As with the earlier version, the DE2 serves the same two primary purposes: (1) the DE2 allows an organization to wrap important pieces of emergency information into a single easy-to-distribute XML "package", and (2) the DE allows an organization to "address" the package in flexible ways to support intelligent routing, including specifying recipients by role, by geographic area, or by keywords. With the DE, organizations can use standardized lists of roles or keywords, or their own lists for additional flexibility and tailoring. So what’s new? This version of the DE expands the ability to use local community-defined terms, uses a profile of the Geographic Markup Language (GML), follows best practices for naming conventions, provides an extension mechanism for inclusion of supplemental community terms and information, provides the capability to link content objects, and is reorganized for increased flexibility and reuse of common types. Fortunately, the DE remains a simple, concise standard. This paper describes the DE version 2.0, highlighting changes from the original version. After reading this short paper, the reader will be ready to begin using the DE2.

This white paper was produced and approved by the OASIS Emergency Management Technical Committee as a Committee Draft. It has not been reviewed and/or approved by the OASIS membership at-large.

Copyright © 2012 OASIS. All rights reserved.

All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual Property Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the OASIS website. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to OASIS, except as needed for the purpose of developing any document or deliverable produced by an OASIS Technical Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must be followed) or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

25 May 2023

Table of Contents

Introduction.................................................................................................4

Background..................................................................................................5

About OASIS...............................................................................................6

Purpose........................................................................................................7

What’s New?...............................................................................................8

Scope.........................................................................................................11

What’s in the DE?.....................................................................................12

The DE Header Tags.............................................................................12

The DE Descriptor Tags.......................................................................13

The Content Wrapper Tags...................................................................18

Putting It All Together..............................................................................19

Where is the Post Office?..........................................................................22

Conclusion.................................................................................................23

References.................................................................................................24

APPENDIX A. Distribution Element (DE) 2.0 XML Schema................25

APPENDIX B. Distribution Element (DE) Domain Model....................30

APPENDIX C. Distribution Element (DE) Completed Example............31

The Distribution Element 2.0: The Basic Steps to Package and Address Your Emergency Information

4

IntroductionWouldn't it be nice if the important information about an emergency were available in a single package rather than scattered about in bits and pieces? And wouldn't it be nice if the package were addressable to the right groups of people, those with appropriate roles or those in certain geographic areas rather than distributed ad hoc or by local custom or not distributed at all? Yes, it would be nice and there exists today a standard to do just that: the Distribution Element 2.0 (DE).

Perhaps the best news about the DE is that it's simple. Anyone can learn and use the DE. In fact, by the time you finish reading this short paper, you too will know how to package and address your information the DE way. Welcome to Basics of the DE. Let's begin.

25 May 2023

FAQ

What if I don’t know the Person’s “address”?

The DE supports addressing by specifying a person’s role. Transport systems built to support the DE will use this information to ensure your information gets to the person(s) who has that role.

What if I don’t know who the information should go to?

The DE supports addressing by describing the emergency information with keywords. Transport systems built to support the DE will use this information to ensure your information gets to the right person(s) based on rules or subscriptions using the same or similar keywords.

BackgroundThe DE version 2.0 is an enhanced version of the original Distribution Element, one of a family of standards that comprise or support the Emergency Data Exchange Language (EDXL). EDXL began in 2004 as a project of the Disaster Management eGov Initiative of the U.S. Department of Homeland Security (DHS) as a means to enhance inter-agency emergency data communications. The standards which comprise or support EDXL are: (1) Common Alerting Protocol (CAP) for emergency alerts; (2) Resource Messaging (RM) for issuing and handling requests for emergency resources; (3) Hospital AVailability Exchange (HAVE) for communicating the status of a hospital and its resources; and (4) the Distribution Element 2.0 (DE) for packaging and addressing emergency information. (New standards emerging include Situation Reporting (SitRep) and Tracking of Emergency Patients (TEP)) All of these standards can be found under the names CAP, EDXL-DE, EDXL-RM and EDXL-HAVE at the OASIS website: http://www.oasis-open.org. The goal of the EDXL initiative is to facilitate emergency information sharing and data exchange across the local, state, tribal, national and non-governmental organizations. The effort focuses on standardization of specific messages to facilitate emergency communication and coordination. Any technology vendor or organization can easily develop their XML-based messaging exchanges using these standards, leveraging their existing legacy information technology applications. For more background on EDXL, see http://xml.coverpages.org/edxl.html.


http://xml.coverpages.org/edxl.html

http://www.oasis-open.org/

6

About OASISThe Organization for the Advancement of Structured Information Systems (OASIS) is an international, not-for-profit, open standards organization which fosters the development, convergence and adoption of open standards in a variety of domains, including emergency management, cloud computing, service oriented architecture, the Smart Grid, and electronic publishing. Open standards are standards developed by an organization open for membership to all qualifying organizations or individuals, with an orderly, equal and fair opportunity for contribution to the development of the standards by all members. OASIS has more than 5,000 participants representing over 600 organizations with members from over 100 countries.

The benefits of open standards adhere to all members and non-members alike; however, the benefits of membership are unique to members. Open standards improve interoperability of systems, enabling plug-and-play opportunity for all vendors and individuals. Open standards lower overall cost of system development and maintenance, stimulate innovation, grow global markets, and protect the right of free choice of technology. The benefits of membership include early assessment, feedback, and education on the emerging standards that impact your business or agency. Your organization can help lead the standards development effort in your field of interest, defining data formats that will govern information exchange in your field for years to come.

Participation in OASIS is easy, low-cost, and fun, with direct benefits to your business and your bottom line. Technology is changing too rapidly for any individual or company to go it alone. The connections to members, who include business partners, customers, government organizations, and technology/standards experts, enable your organization to not only stay on top of but to design the technology-driven business landscape.

Please review the list of OASIS member organizations at http://www.oasis-open.org/member-roster and consider whether you too would like to join. The OASIS staff is friendly and helpful, ready to answer your questions. To reach a staff member to discuss how to participate, please send an email to XXX or call YYY. If you would like to join our Emergency Management Technical Committee, we would like to welcome you and we are also available to answer your questions. Please send an email to ZZZ or if you would like to chat by phone, the OASIS staff will put you in contact with one of our members. Thanks.

25 May 2023

http://www.oasis-open.org/member-roster

PurposeThe DE serves two important purposes. First, the DE allows an organization to wrap separate but related pieces of emergency information into a single "package" for easier and more useful distribution. Second, the DE allows an organization to "address" the package to organizations with specified roles or groups located in specified locations or those interested in specified keywords. In the absence of national standards on incident taxonomy, the DE allows an organization to use its own terms to characterize its content, such as roles and keywords. This version 2.0 of the DE expands the ability to use local community-defined terms, uses a profile of the Geographic Markup Language (GML), follows best practices for naming conventions, provides the capability to link content objects, and is reorganized for increased flexibility and reuse of common types.

DHS recommends the DE in their grant guidance to ensure systems are built to support sharing of emergency information. See http://www.fema.gov/pdf/emergency/nims/FY09_Recommend_Standards_List_121708.pdf. Use of the DE means that the wide variety of middleware systems do not have to develop separate capabilities to handle each kind of message. They only need to process the DE, without opening the content of the payload attached to it.


http://www.fema.gov/pdf/emergency/nims/FY09_Recommend_Standards_List_121708.pdf

8

What’s New?The new Version 2.0 of the DE keeps all the things that were good and worked well in the original Version 1.0 and adds improved customization, standardization, flexibility, and descriptive power:

Customization

In an emergency, it’s important to be able to use terms that are well-known and understood in your community. Version 1.0 was designed to allow some customization, so you could specify your own terms for roles and keywords. The ability to customize the DE has been expanded in Version 2.0. Now you can use Community Extensions to define your own terms for extending or tailoring other DE elements. Simply choose the best matching default term for use by outsiders and then use the extension mechanism to supply your own community-defined term. many other DE elements, including the type of distribution, the status of the distribution, kind of area, urgency, severity, confidence and classification. We’ll look at some examples in a bit. This increased ability to customize the DE puts you and your jurisdiction or community in control to use and expand your own terms to describe your emergency information. Of course, the customization is optional and you don’t have to use it. Default values are provided for your use as well. It’s your choice.

Standardization

When developing a standard like the DE, it’s useful and sensible to reuse well-known, existing standards. There is no need to reinvent the wheel and interoperability is fostered because many systems already understand the existing standards. Version 1.0 was largely homegrown, but now that it has matured we have had the opportunity to reuse some important standards in Version 2.0. The Geography Markup Language (GML) developed by the Open Geospatial Consortium (OGC) is now used in Version 2.0 to represent addressing information based on geographic area. Customer Information Quality (CIQ) developed by OASIS is now used to represent addressing information based on geopolitical information such as street, city, state, and country. To keep it simple, only a subset (profile) of the full standards were used. In addition, Xlink developed by the World Wide Web Consortium (W3C) is now used to enable you to better describe your content by providing meaningful links between your content objects. The net effect of using these standards is improved interoperability and robustness when sending your emergency information using the DE Version 2.0.

Flexibility

What if you already distribute your emergency information using another standard “wrapper” like SOAP or ATOM? In Version 1.0 of the DE, there wasn’t much flexibility. Users felt they would have to abandon their existing standardized distribution mechanism and lose out on the benefits of the DE. In Version 2.0, the descriptive components are now usable outside the traditional wrapper components. So you can now have the benefits of the DE to describe your emergency information no matter which wrapper you use. It’s your choice.

25 May 2023

Descriptive Power

A well-known problem with ensuring people have the information they need is to decide whether to use explicit addresses like an email address or implicit addresses like roles or keywords, such as “State Coordinating Officer”, “Disaster Recovery Center” or “Search and Rescue”. Although explicit addressing is easy and simple, just like sending an email, it has the same disadvantages as email. Often people don’t get the information they need because they weren’t on the address line and often, in an emergency, the senders don’t know everyone and don’t know their explicit addresses. So explicit addressing is easy but brittle and doesn’t scale effectively in an emergency. The better option is often implicit addressing where a role or keyword is specified and the target recipients are determined either by the distribution system using rules or by the recipients who have previously subscribed for the types of information they want. This better implicit option requires an ability to effectively describe the key content of the message.

An ideal addressing mechanism would allow for a range of addressing with significant capability for implicit addressing. Version 1.0 of the DE supported a range from specific to general, including explicit address, role, target area, and keywords. Version 2.0 expands this capability to describe your content. You can now specify the urgency, severity, and confidence of your message. You can specify multiple kinds of areas that describe your message, such as source area or evacuation area. You can specify your own any descriptive terms from your own list used in your community. You can specify the confidentiality of your message using your preferred list of terms. Now transport systems have a better description of the messages you are sending and be in a better position to do smarter routing, to apply rules and infer from those terms the target recipient(s).

Note: You can use both explicit and implicit addressing in the DE. You can specify someone specific and still provide keywords, areas, confidence, urgency and other terms so that all appropriate and interested users will receive your message.

Community Extensions

The DE 2.0 now supports the inclusion of community-defined sets of name/value pairs, referred to here as “Community Extensions” or simply “Extensions” for short. Users of the Common Alert Protocol (CAP) are familiar with this concept since CAP was the first EDXL standard to include the Parameter element which allows a user to add name/value data to a normal CAP alert. The Canadian Emergency Management community has been utilizing the Parameter elements to send supplemental business information, referred to as “layers”, with CAP for years. Now, you can do the same with the DE and other EDXL standards. For example, if you send a DE message with an alert or image about an earthquake, you might want to include some specific earthquake data, like the magnitude and depth of the earthquake. There are no earthquake-specific fields in the DE; however, your community can extend the DE to include that information, which you define as a set of Parameter elements specifically, designed to represent earthquake data. Although standards’ developers sometimes frown upon such extension mechanisms, since they appear to allow for arbitrary, non-standard representation of information, the “Community Extensions” concept solves several major problems for improving information sharing and developing standards for the emergency management community. First, the nature of emergencies is that the unexpected will happen and emergency managers need flexibility to send whatever information is needed . Second, an emergency begins and often stays local, so local authorities and users need control to send the information they decide is important to address the current emergency. Third, communities need the opportunity to explore potential new standards. The Parameter name/value extension mechanism, along with the concept and formalism of “Community Extensions”, provides an on-ramp for communities to determine what works well for them. Those Community Extensions which are most successful can be formalized into future standards. Now, with support for Community Extensions in the DE 2.0, you can add supplemental “layers” of business information and receive the same benefits whenever any EDXL message is sent.


10

A Few Problems Fixed

The development of Version 2.0 of the DE provided the opportunity to address a few specific problems that had cropped up with Version 1.0. These are specific problems, which may not have come up for you, but we can mention them quickly:

Grouping Areas: With Version 1.0, you could specify multiple target areas but it was never clear what this meant. Should the message go to everyone in any of these target areas? If the areas overlapped, should the message be sent to only those in the intersection? Or are the areas alternative descriptions of the same area? This created some confusion which is now fixed. In Version 2.0, you can specify not only the kind of area with defaults (e.g. source, target) or your own terms, but also how you want the areas grouped (e.g. union, intersection). So no more confusion over how to group multiple target areas.

Distribution Reference: If you sent a message, and then wanted to update or cancel it, in Version 1.0 you had to send another message and specify details to identify the previous message. The details were not standardized and the requirement created difficulties for users who were doing many updates. Also the requirement was more related to the mechanics of message transport. After all, from a user standpoint, it’s the same message, we’re just updating or canceling it. The solution in Version 2.0 is to do away with the requirement to specify details of the previous message. The recommended method to update or cancel is to use the same message id for both the original message and any updates. (Note that if a system needs to find the previous messages, it can do so using the date time sent.)

Expiration: If you send a message, when should your message expire? There was no specific way to specify this in Version 1.0 which created the obvious problem and burden of having to send many cancellation messages or leave it up to recipients to guess when the message should expire. If you were to look at a message, how would you know if it was out-of-date? For emergency messages, it’s important to know when they expire. The simple fix in Version 2.0 was to include DateTimeExpires as an element right next to DateTimeSent.

So what’s new in Version 2.0? The good old stuff from Version 1.0 is still there but what was good before is better now. More customization, more flexibility, more standardization, and more descriptive power are now at your fingertips. A new opportunity for emergency information sharing and interoperability awaits as soon as you start to use the DE.

25 May 2023

ScopeThe rest of the paper describes what is in the DE; however, for effective understanding and usage of the DE, it is equally important to say what is not in the DE. Although the DE facilitates improved routing of emergency information, the DE is not intended to replace or compete with standards covering core routing capabilities and routing needs that apply generally to any type of information sharing. These more general capabilities and needs include authentication, quality of service, redundancy, backup, message brokering or translation, choice of transport mechanism, and encryption, among others. Routing is an important topic of its own and is addressed by a number of organizations with a variety of standards.

The DE facilitates routing by packaging information and describing the message with labels such as keywords, intended recipient roles and sender roles; however, the DE assumes that other standards will be used to enable the routing itself and to address the routing concerns mentioned above that are typical of any information sharing framework across an enterprise. This separation of concern allows the DE to be a simple standard focused on its core purpose: packaging, describing and addressing emergency information. The OASIS Emergency Management Technical Committee has prepared a draft document advising on best practices for addressing these routing concerns from the perspective of the DE and the EDXL overall. The draft “Best Practices for Routing Using the Distribution Element”, can be found at http://www.oasis-open.org/committees/download.php/38532/EDXL-DE-Routing-Basics-WhitePaper-06212010.doc


12

What’s in the DE?The DE is simply a set of eXtensible Markup Language (XML) elements, sometimes referred to as “tags”. An XML element is a name for a piece of information defined in a schema. In fact, if you're familiar with XMLSchema, you may want to go straight to the schema in Appendix A and take a quick look. The DE is short and simple. For those with a graphical bent, you may want to take a quick look at the domain model diagram in Appendix B. For the rest of us, we'll go over the basics right here.

For explanatory purposes, we'll subdivide the DE into three parts or three sets of XML elements (“tags”): the Header tags, the Descriptive tags, and the Content Wrapper tags. We'll review each part of the DE with examples. This will give us a quick practical overview of the DE with xml examples for all the basic DE tags.

The DE Header TagsThe seven DE header tags are contained in a DE Envelope tag and are used for simple administrative annotations. The tags and their data types are:

DistributionID (EDXLStringType)

SenderID (EDXLStringType)

DateTimeSent (EDXLDateTimeType)

DateTimeExpires (EDXLDateTimeType)

DistributionStatus (DistributionStatusType)

DistributionKind (DistributionType)

The tags are fairly self-explanatory. If you choose to use the DE Envelope tag, as most users will, then all of these header tags are required.1 You can put a unique string of your choice in the DistributionID to identify the package. In the senderID, an e-mail address will suffice.

The DateTimeSent tag is just what it says and contains the date and time. The DateTimeExpires is a new tag in the DE version 2.0 which represents the date and time after which the information in the package should no longer be relied upon. The only oddity for newcomers to XML dateTime is the format where, for example, August 7th, 2008 at 6:05pm in the U.S. Mountain timezone is represented as 2008-08-07T18:05:00-07:00. This format is borrowed from ISO 8601 and is of the form: CCYY-MM-DDThh:mm:ss[(+|-)hh:mm] where the timezone is specified as (+|-)hh:mm.2

1 The new version of the DE allows for the three sets of tags (DE Header tags, DE Descriptor tags, and Content tags) to be used independently, if desired. This additional flexibility supports those experienced users who already distribute their emergency information in formats that have their own “envelope” to package their content, such as a SOAP envelope or an RSS feed. If you haven’t already committed to a specific envelope format, we recommend using all of these tags together inside a DE Envelope tag. 2 Note that the use of Z to specify Greenwich meantime is not allowed; instead, the timezone offset must be specified. This is the one restriction on the traditional XMLSchema dateTime format applied by the EDXLDateTimeType.

25 May 2023

Sometimes it’s nice to have a choice: either use default terms or use your own. The DE 2.0 supports interoperability by providing reliable defaults for many of the elements and allowing you to use your own terms utilizing the ValueList* where no defaults are available, such as for senderRole, or for providing supplemental information in Community Extensions. In the case of DistributionStatus and DistributionType, defaults values are provided and you select one. The default DistributionStatus can be one of Actual, Exercise, System or Test. The default DistributionType can be one of Report, Update, Cancel or a few others. Usually, the DistributionType will just be Report. See Figure 1 (below).

<distributionID>http://myhost.com/packages/17</distributionID><senderID>[email protected]</senderID><dateTimeSent>2009-11-15T16:53:00-05:00</dateTimeSent><dateTimeExpires>2009-11-15T17:53:00-05:00</dateTimeExpires><distributionStatus>Exercise</distributionStatus><distributionKind>Report</distributionKind>

Figure 1. XML Snippet of Distribution Element Header Tags Using Default Values

There is nothing particularly fancy or special about these header tags, but they are important for purposes, such as message tracking and auditing. Here's what the tags look like when filled in with some sample data.

The DE Descriptor TagsThe fourteen Descriptor Tags include:

combinedConfidentiality

language

senderRole

recipientRole


*What is a ValueList?

A ValueList is a named list of values, from which you can pick one or more values. In the DE, many elements are represented as ValueLists. The primary advantage of a ValueList is that you can select which list you would like to use or create your own. In this way, the DE can allow for customization of elements to address local needs.

Where are ValueLists used in the DE?

ValueLists are used in the DE when no default values are available such as to represent senderRole, recipientRole and keywords.

14

keyword

explicitAddress

targetAreas

urgency

severity

certainty

incidentID

incidentDescription

link

ext:extension

These tags are primarily complex types which means they contain other tags, as shown in the examples below. All of these tags are optional, so you can just use the ones you need. The tags enable various ways of addressing your package, explicitly by specific address, or implicitly by geographic area, by recipient role, and by keyword. Let’s look at examples of how each of these tags can be used to aid description and distribution of your emergency information.

With the first two tags, combinedConfidentiality and language, you can describe the emergency information in terms of its level of privacy and written language. For combinedConfidentiality, you may choose classified or unclassified. (For more specific classification terms, you may include your own supplemental classification as a Community Extension.) Use the term describing the highest classification of your packaged content. For example, to specify that the emergency information is unclassified, one could do the following:

<combinedConfidentiality>Unclassified</combinedConfidentiality> <language>EN</language>

Figure 2. XML Snippet of Distribution Element Descriptor Tags: combinedConfidentiality and language

For Language, use the two-letter language code familiar to html developers, e.g. "EN" for English. (For a complete list of codes, see ISO639-1 at http://www.sil.org/iso639-3/codes.asp?order=639_1&letter=%25.)

You also can address information to a group of people (or computer systems) by their role in the emergency, such as the example below which indicates the sender is supporting “Search and Rescue” and the recipients are systems supporting situational awareness and warning devices:

<senderRole> <ct:ValueListURI>urn:myagency:gov:sensors:senderRole</ct:ValueListURI> <ct:Value>Search and Rescue</ct:Value> </senderRole> <recipientRole> <ct:ValueListURI>urn:myagency:gov:sensors:recipientRole</ct:ValueListURI> <ct:Value>Situational Awareness Apps</ct:Value> <ct:Value>Warning Devices</ct:Value> </recipientRole>

Figure 3. XML Snippet of a DE senderRole and recipientRole

25 May 2023

http://www.sil.org/iso639-3/codes.asp?order=639_1&letter=%25

These particular roles are for demonstration purposes. You can select from lists of roles developed by your community or jurisdiction. Each of these roles is a ValueList, consisting of a list name and one or more selected values from the externally-managed list. The list name, the <ValueListURI> tag, is a Uniform Resource Name (URN) or a Uniform Resource Locator (URL) which are W3C standards for creating unique identifiers. The DE uses this construction of <ValueListURI> followed by one or more <values> to give communities flexibility to define standard lists of terms for roles and keywords. For more information on URNs, see http://tools.ietf.org/html/rfc2141.

You can address a group of recipients by specifying keywords from a list. The keywords can be used for searching and filtering. Here is an example:

<keyword> <ct:ValueListURI>urn:myagency:gov:sensors:keywords</ct:ValueListURI> <ct:Value>SNM Detection</ct:Value> <ct:Value>XYZ</ct:Value> </keyword>

Figure 4. XML Snippet of a DE Keyword(s)

For specific address routing, just use the <ExplicitAddress> tag, specifying the distribution method and address. For example, to send the package via email to [email protected], you would do this:

<explicitAddress> <explicitAddressScheme>e-mail</explicitAddressScheme> <explicitAddressValue>[email protected]</explicitAddressValue> </explicitAddress>

Figure 5. XML Snippet of a DE Explicit Address

To specify distribution to a group of people (or systems) in a certain area, you can define the geographic area by name, such as:

<targetAreas> <areaKind>DistributionTargetArea</areaKind> <areaGrouping>Union</areaGrouping> <targetArea> <geoPoliticalLocation> <ct:GeoCode> <ct:ValueListURI>http://www.unece.org/fileadmin/DAM/cefact/locode/usk.htm</ct:ValueListURI> <ct:Value>USNYC</ct:Value> </ct:GeoCode> </geoPoliticalLocation> </targetArea> </targetAreas>

Figure 6. XML Snippet of a DE targetArea Specified by geoPoliticalLocation


http://tools.ietf.org/html/rfc2141

16

The new version of the DE allows more flexibility for allowing you to select your appropriate list of location values by specifying the ValueListURI and Value tags. Here we’ve used the United Nations Location Codes (UN/LOCODE) designator for the location concerned, in this case New York City. You can look up UN/LOCODEs at http://www.unece.org/cefact/locode/service/location.htm. We’ve also specified the kind of area to be “DistributionTargetArea” and that all areas in this list should be grouped by “union”, although here there is only one area specified.

You can also specify a geographic area by specifying a list of latitude/longitude points in decimal degrees defining a polygon where the first and the last points are always the same, such as:

<targetArea> <edxl-gsf:EDXLGeoLocation> <gml:Polygon gml:id="myPolygon"> <gml:exterior> <gml:LinearRing> <gml:pos>33.4745 -112.1174</gml:pos> <gml:pos>33.4238 -112.0238</gml:pos> <gml:pos>33.4238 -112.1174</gml:pos> <gml:pos>33.4745 -112.1174</gml:pos> </gml:LinearRing> </gml:exterior> </gml:Polygon> </edxl-gsf:EDXLGeoLocation> </targetArea>

Figure 7. XML Snippet of a DE targetArea Specified by a Polygon

The format for specifying the polygon utilizes the standard Geography Markup Language (GML). OASIS has defined a subset of GML called a Simple Features Profile to lower the learning curve and simplify the use of this important standard.

Another option for representing a geographic area is to use the <CircleByCenterPoint> tag with latitude, longitude and radius. For example:

<targetArea> <edxl-gsf:EDXLGeoLocation> <gml:CircleByCenterPoint numArc="1"> <gml:pos>33.4745 -112.1174</gml:pos> <gml:radius uom="urn:ogc:def:uom:UCUM:km">3</gml:radius> </gml:CircleByCenterPoint> </edxl-gsf:EDXLGeoLocation> </targetArea>

Figure 8. XML Snippet of a DE targetArea Specified by a Circle

In this case, we specified kilometers (km) as our unit of measure. For more information on specifying units of measure, see http://www.opengeospatial.org/ogcUrnPolicy .

You have the option to specify the Urgency, Severity and Certainty of the emergency information. As with many DE tags, you choose one of the default enumerated values (and, if needed, you can specify your own values in a Community Extension from your own list). Here is an example indicating that the urgency is immediate, the severity is minor and the certainty is high because the event was observed:

25 May 2023

http://www.opengeospatial.org/ogcUrnPolicy

http://www.unece.org/cefact/locode/service/location.htm

<urgency>Immediate</urgency> <severity>Minor</severity> <certainty>Observed</certainty>

Figure 9. XML Snippet of a DE Descriptor elements: urgency, severity, certainty

Finally, you have the option to include additional business data or metadata using as a Community Extension. A Community Extension is simply a community-defined set of name/value pairs. An extension can be defined for including supplemental information which communities would like to exchange with some level of agreement and formatting. For example, a Community Extension might represent a set of earthquake information which could accompany a DE message containing an alert. Communities will want to document their extensions. For more information and examples of the extension concept, please see the discussion of extension “layers” at http://www.capan.ca. Including an extension is easy in your DE, as shown in the example below. Simply provide a name for your extension and then any parameter tags specifying your name/value pairs. (Note that the names are URIs, so the names are globally unique and whose definitions can be available for web-based lookup.) This example represents an earthquake with a magnitude of 5.3 on the Richter scale, at a time of 11:25 pm GMT on August 30 th, 2010, and a depth of 38.7 international miles.

<ext:extension> <community>http://example/layers/earthquake</community> <id>layer1</id> <parameter> <nameURI>http://example/layers/earthquake/Name</nameURI> <value>Earthquake1</value> </parameter> <parameter> <nameURI>http://example/layers/earthquake/Magnitude</nameURI> <value uom="http://example/layers/earthquake/RichterScale">5.3</value> </parameter> <parameter> <nameURI>http://example/layers/earthquake/EventTime</nameURI> <value>2010-08-30T23:25:40+00:00</value> </parameter> <parameter> <nameURI>http://example/layers/earthquake/Depth</nameURI> <value uom="http://qudt.org/vocab/unit/MileInternational">38.7</value> </parameter></ext:extension>

Figure 9. XML Snippet of a Community Extension representing basic earthquake information

With all these options, you can easily address your package by role, by location, by geographic area, or by keywords, specify the urgency, severity and certainty, as well as provide any needed supplemental information using your own organization approved lists of terms. This is a simple but powerful distribution addressing mechanism available to you in the DE.


18

The Content Wrapper TagsNow that you understand header and distribution tags, we only need to cover the content wrapper tags of the DE. Let's say you have two pieces of XML content to add to your package. For XML content, you can use the DE tags: ContentObject and ContentXML. Here's how to do it:

<content xlink:type="resource"> <contentObject xlink:type="resource"> <contentXML> <embeddedXMLContent>

{yourXMLContentItem1GoesHere} </embeddedXMLContent>

</contentXML> </contentObject> <contentObject xlink:type="resource"> <contentXML> <embeddedXMLContent>

{yourXMLContentItem1GoesHere} </embeddedXMLContent>

</contentXML> </contentObject></content>

Figure 10. XML Snippet Demonstrating How to Embed XML Content in the DE

In this example, we didn't actually put in the XML content but instead simply indicated where it should go.

You can add as many <contentObject> tags as you like. (The attributes specifying contentObjects as resource types allows linking of content objects using the Xlink standard. There are examples in the DE download package demonstrating this capability for those who are interested.) If you have non-XML content, such as a picture in jpeg format, or any other well-known format, just specify the mimetype. You can include the binary content using the <contentData> tag in which case the data needs to be base-64 encoded. (Base 64 encoding is used to ensure the data can be represented with ASCII characters. For more info on base-64 encoding, see http://www.faqs.org/rfcs/rfc3548.html. The mimetype format is defined in RFC 2046, see http://www.ietf.org/rfc/rfc2046.txt.) Another option for your non-XML content is to include the mimetype followed by the url location of the image or other data. For example:

<contentObject xlink:type="resource"> <otherContent> <mimeType>image/jpeg</mimeType> <uri>http://www.myhost.com/pictures/pic333</uri> </otherContent> </contentObject>

Figure 11. XML Snippet Demonstrating How to Reference Other Content in the DE

25 May 2023

http://www.ietf.org/rfc/rfc2046.txt

http://www.faqs.org/rfcs/rfc3548.html

Putting It All TogetherFigure 2 (below) is an example that puts together many of the XML snippets to see what an entire DE message looks like (minus the actual content), wrapping everything in the EDXLDistribution tag. (For a validated DE with content, see Appendix C.)

<?xml version="1.0" encoding="UTF-8"?><edxlDistribution xlink:type="extended" xsi:schemaLocation="urn:oasis:names:tc:emergency:EDXL:DE:2.0 ../schema/edxl-de-v2.0-wd11.xsd urn:oasis:names:tc:emergency:cap:1.1 ./example-supporting-schema/cap.xsd http://myserver.org/test/ ./example-supporting-schema/test.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:oasis:names:tc:emergency:EDXL:DE:2.0" xmlns:edxl-gsf="urn:oasis:names:tc:emergency:edxl:gsf:1.0" xmlns:ext="urn:oasis:names:tc:emergency:edxl:extension:1.0" xmlns:ct="urn:oasis:names:tc:emergency:edxl:ct:1.0" xmlns:gml="http://www.opengis.net/gml/3.2" xmlns:xlink="http://www.w3.org/1999/xlink"> <distributionID>http://myhost.com/packages/17</distributionID> <senderID>[email protected]</senderID> <dateTimeSent>2009-11-15T16:53:00-05:00</dateTimeSent> <dateTimeExpires>2009-11-15T17:53:00-05:00</dateTimeExpires> <distributionStatus>Exercise</distributionStatus> <distributionKind>Report</distributionKind> <descriptor xlink:type="resource"> <combinedConfidentiality>Unclassified</combinedConfidentiality> <language>EN</language> <senderRole> <ct:ValueListURI>urn:myagency:gov:sensors:senderRole</ct:ValueListURI> <ct:Value>Search and Rescue</ct:Value> </senderRole> <recipientRole> <ct:ValueListURI>urn:myagency:gov:sensors:recipientRole</ct:ValueListURI> <ct:Value>Situational Awareness Apps</ct:Value> <ct:Value>Warning Devices</ct:Value> </recipientRole> <keyword> <ct:ValueListURI>urn:myagency:gov:sensors:keywords</ct:ValueListURI> <ct:Value>SNM Detection</ct:Value> <ct:Value>XYZ</ct:Value> </keyword> <explicitAddress> <explicitAddressScheme>e-mail</explicitAddressScheme> <explicitAddressValue>[email protected]</explicitAddressValue> </explicitAddress> <targetAreas> <areaKind>DistributionTargetArea</areaKind> <areaGrouping>Union</areaGrouping> <targetArea> <geoPoliticalLocation>


20

<ct:GeoCode> <ct:ValueListURI>http://www.unece.org/fileadmin/DAM/cefact/locode/usk.htm</ct:ValueListURI> <ct:Value>USNYC</ct:Value> </ct:GeoCode> </geoPoliticalLocation> </targetArea> </targetAreas> <targetAreas> <areaKind>SourceTargetArea</areaKind> <areaGrouping>Union</areaGrouping> <targetArea> <edxl-gsf:EDXLGeoLocation> <gml:Polygon gml:id="myPolygon"> <gml:exterior> <gml:LinearRing> <gml:pos>33.4745 -112.1174</gml:pos> <gml:pos>33.4238 -112.0238</gml:pos> <gml:pos>33.4238 -112.1174</gml:pos> <gml:pos>33.4745 -112.1174</gml:pos> </gml:LinearRing> </gml:exterior> </gml:Polygon> </edxl-gsf:EDXLGeoLocation> </targetArea> <targetArea> <edxl-gsf:EDXLGeoLocation> <gml:CircleByCenterPoint numArc="1"> <gml:pos>33.4745 -112.1174</gml:pos> <gml:radius uom="urn:ogc:def:uom:UCUM:km">3</gml:radius> </gml:CircleByCenterPoint> </edxl-gsf:EDXLGeoLocation> </targetArea> </targetAreas> <urgency>Immediate</urgency> <severity>Minor</severity> <certainty>Observed</certainty> <ext:extension> <ext:community>http://www.mytestserver.org/layers/</ext:community> <ext:id>earthquake</ext:id> <ext:parameter> <ext:nameURI>http://www.mytestserver.org/layers/earthquake/Name</ext:nameURI> <ext:value>Earthquake1</ext:value> </ext:parameter> <ext:parameter> <ext:nameURI>http://www.mytestserver.org/layers/earthquake/Magnitude</ext:nameURI> <ext:value uom="http://www.mytestserver.org/layers/earthquake/RichterScale">5.3</ext:value> </ext:parameter> <ext:parameter> <ext:nameURI>http://www.mytestserver.org/layers/earthquake/EventTime</ext:nameURI> <ext:value>2010-08-30T23:25:40+00:00</ext:value> </ext:parameter>

25 May 2023

<ext:parameter> <ext:nameURI>http://www.mytestserver.org/layers/earthquake/Depth</ext:nameURI> <ext:value uom="http://qudt.org/vocab/unit/MileInternational">38.7</ext:value> </ext:parameter> </ext:extension> <ext:extension> <ext:community>http://mycommunity.org</ext:community> <ext:id>layer1</ext:id> <ext:parameter> <ext:nameURI>http://mycommunity.org/layer1/urgency</ext:nameURI> <ext:value>Low</ext:value> </ext:parameter> </ext:extension> </descriptor> <content xlink:type="resource"> <contentObject xlink:type="resource"> <contentXML> <embeddedXMLContent>

{ … PUT YOUR XML CONTENT HERE …} </embeddedXMLContent> </contentXML> </contentObject> <contentObject xlink:type="resource"> <otherContent> <mimeType>image/jpeg</mimeType> <uri>http://www.myhost.com/pictures/pic333</uri> </otherContent> </contentObject> <contentObject xlink:type="resource"> <contentXML> <embeddedXMLContent> { … PUT YOUR XML CONTENT HERE …} </embeddedXMLContent> </contentXML> </contentObject> <contentObject xlink:type="resource"> <contentXML> <embeddedXMLContent> { … PUT YOUR XML CONTENT HERE …} </embeddedXMLContent> </contentXML> </contentObject> </content></edxlDistribution>

Figure 12. An almost complete DE example with placeholders for the actual XML content items.

In this example, we see the basic DE tags we've learned combined into the DE package, including header tags, distribution tags, and content wrapper tags. Is there more? There are ways to get fancier. For example, you can encrypt your content or you can add individual roles and keywords for each piece of content in your package to support more finely tuned routing. But that's not required. With the basics shown in this paper, you can easily get started packaging your emergency information for easy and useful distribution.


22

Where is the Post Office?Now that you have your emergency content nicely packaged and addressed, you might be wondering where you take your package to actually get it distributed, i.e. where is the virtual post office? There are a number of current distribution solutions available for EDXL Content (e.g. CAP, HAVE, etc.) while full DE-aware solutions are emerging.

If you are based in the U.S., one solution is to use DMIS/OPEN, a backbone message distribution server maintained by DHS. See http://www.disasterhelp.gov/disastermanagement/about/contact.shtm to find out more about getting started with DMIS/OPEN. Other solutions for alerting include the Integrated Public Alert and Warning System (IPAWS - http://www.fema.gov/emergency/ipaws/), the Emergency Alert System (EAS - http://www.fcc.gov/pshs/services/eas/) and the Cellular Messaging Alert System (CMAS - http://www.cmasalert.com/).

A second option is to use any IP network and middle ware system. There are many open source and commercial solutions in this space. Consult your IT specialist about these options.

As a third option, you can also use the public internet. By posting your DE package to your own RESTful website, your package can be accessed by your customers in the same manner as an RSS feed. You can use your web administrator's recommended authentication and security mechanism, as needed. This is a scalable and easy to implement solution. For more information on RESTful web services, see reference [5].

A fourth option is to use an open source or vendor-supplied routing solution that will parse your distribution tags and send out your package via e-mail, publish/subscribe, or other technique. You might wish to consult the Emergency Interoperability Consortium at http://www.eic.org/ as an additional resource.

Of course, these options are only the beginning. New routing solutions and architectures are needed to take full advantage of the DE. Now is a good time to consider joining OASIS so your company or organization can assist in these efforts.

25 May 2023

http://www.eic.org/

http://www.cmasalert.com/

http://www.fcc.gov/pshs/services/eas/

http://www.fema.gov/emergency/ipaws/

http://www.disasterhelp.gov/disastermanagement/about/contact.shtm%20

ConclusionThe DE 2.0 is an important step forward for providing a standardized way to package and address your emergency information. We hope this paper has been helpful in explaining the basics of the DE. Additional papers explaining the details of the other EDXL standards are underway.

The OASIS Emergency Management Technical Committee is always seeking advice, feedback and guidance. If you have questions or suggestions regarding the DE 2.0, or want to join OASIS to help improve the DE directly, you can make a comment by following the procedure at http://www.oasis-open.org/committees/comments/form.php?wg_abbrev=emergency for subscribing to and sending an email message to the public comment list for the OASIS Emergency Management Technical Committee. We welcome your input. Enjoy the DE and thanks for reading this tutorial on the Distribution Element Version 2.0.


http://www.oasis-open.org/committees/comments/form.php?wg_abbrev=emergency%20

http://www.oasis-open.org/committees/comments/form.php?wg_abbrev=emergency%20

24

References[1] OASIS Standard, “Emergency Data Exchange Language Distribution Element, v. 1.0” May 2006.

(http://docs.oasis-open.org/emergency/edxl-de/v1.0/EDXL-DE_Spec_v1.0.pdf) [2] Robin Cover, editor, “Emergency Data Exchange Language” OASIS CoverPages Report, June 2006.

(http://xml.coverpages.org/edxl.html)[3] Tim Grapes, “Emergency Data Exchange Language Overview and Phased Approach” OASIS

CoverPages Report, March 2005. (http://xml.coverpages.org/EDXL-OverviewApproachSummary200503.pdf)

[4] Renato Iannella and Karen Henricksen, “Managing Information in the Disaster Coordination Centre: Lessons and Opportunities” Proceedings of the 4th International ISCRAM Conference (B. Van de Walle, P. Burghardt and C. Nieuwenhuis, eds.) Delft, the Netherlands, May 2007 (http://nicta.com.au/__data/assets/pdf_file/0009/8658/ISCRAM10-final_2.pdf)

[5] Leonard Richardson and Sam Ruby, Restful Web Services, (O'Reilly 2007) ISBN: 9780596529260 (http://oreilly.com/catalog/9780596529260/)

25 May 2023

http://oreilly.com/catalog/9780596529260/

http://nicta.com.au/__data/assets/pdf_file/0009/8658/ISCRAM10-final_2.pdf

http://xml.coverpages.org/EDXL-OverviewApproachSummary200503.pdf

http://xml.coverpages.org/EDXL-OverviewApproachSummary200503.pdf

http://xml.coverpages.org/edxl.html

http://docs.oasis-open.org/emergency/edxl-de/v1.0/EDXL-DE_Spec_v1.0.pdf

APPENDIX A. Distribution Element (DE) 2.0 XML SchemaThe following schema is the core DE 2.0 schema. The complete DE 2.0 zip package, with supporting schema, examples and documentation can be found at the OASIS website.

<?xml version="1.0" encoding="UTF-8"?><xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xlink="http://www.w3.org/1999/xlink"

xmlns:edxl-gsf="urn:oasis:names:tc:emergency:edxl:gsf:1.0" xmlns:ct="urn:oasis:names:tc:emergency:edxl:ct:1.0" xmlns="urn:oasis:names:tc:emergency:EDXL:DE:2.0" xmlns:gml="http://www.opengis.net/gml/3.2" xmlns:ext="urn:oasis:names:tc:emergency:edxl:extension:1.0" targetNamespace="urn:oasis:names:tc:emergency:EDXL:DE:2.0" elementFormDefault="qualified" attributeFormDefault="unqualified"

version="1.0CD"><xs:import namespace="http://www.w3.org/1999/xlink" schemaLocation="./other-

supporting-schema/xlink.xsd"/><xs:import namespace="urn:oasis:names:tc:emergency:edxl:gsf:1.0" schemaLocation="./other-supporting-schema/EDXLCT_wd06/edxl-gsf.v1.0.xsd"/><xs:import namespace="urn:oasis:names:tc:emergency:edxl:ct:1.0" schemaLocation="./other-supporting-schema/EDXLCT_wd06/edxl-ct-v1.0-wd05.xsd"/>

<xs:import namespace="urn:oasis:names:tc:emergency:edxl:extension:1.0" schemaLocation="./other-supporting-schema/EDXLCT_wd06/edxl-ext-v1.0.xsd"/>

<xs:element name="edxlDistribution" type="DEDistributionType"/><xs:complexType name="DEDistributionType"> <xs:complexContent> <xs:extension base="DEEnvelopeType">

<xs:sequence><xs:element ref="descriptor" minOccurs="0" maxOccurs="1"/><xs:element ref="content" minOccurs="0" maxOccurs="1"/><xs:element name="other" type="AnyXMLType" minOccurs="0"

maxOccurs="unbounded"/></xs:sequence><xs:attributeGroup ref="xlink:extendedAttrs"/>

</xs:extension> </xs:complexContent></xs:complexType><xs:complexType name="DEEnvelopeType"> <xs:sequence> <xs:element name="distributionID" type="ct:EDXLStringType" minOccurs="1"/> <xs:element name="senderID" type="ct:EDXLStringType" minOccurs="1"/> <xs:element name="dateTimeSent" type="ct:EDXLDateTimeType" minOccurs="1"/> <xs:element name="dateTimeExpires" type="ct:EDXLDateTimeType"

minOccurs="1"/> <xs:element name="distributionStatus" type="DistributionStatusType"

minOccurs="1"/> <xs:element name="distributionKind" type="DistributionKindType"

minOccurs="1"/>

26

<xs:element ref="ext:extension" minOccurs="0" maxOccurs="unbounded" /> </xs:sequence></xs:complexType><xs:element name="descriptor" type="DEDescriptorType"/><xs:complexType name="DEDescriptorType"> <xs:sequence> <xs:element name="combinedConfidentiality" type="ConfidentialityType"

minOccurs="0"/> <xs:element name="language" type="xs:language" minOccurs="0"/> <xs:element name="senderRole" type="ct:ValueListType" minOccurs="0"

maxOccurs="unbounded"/> <xs:element name="recipientRole" type="ct:ValueListType" minOccurs="0"

maxOccurs="unbounded"/> <xs:element name="keyword" type="ct:ValueListType" minOccurs="0"

maxOccurs="unbounded"/> <xs:element name="explicitAddress" type="ValueSchemeType" minOccurs="0"

maxOccurs="unbounded"/> <xs:element name="targetAreas" type="TargetAreasType" minOccurs="0"

maxOccurs="unbounded"/> <xs:element name="urgency" type="UrgencyType" minOccurs="0"/> <xs:element name="severity" type="SeverityType" minOccurs="0"/> <xs:element name="certainty" type="CertaintyType" minOccurs="0"/> <xs:element name="incidentID" type="ct:EDXLStringType" minOccurs="0"

maxOccurs="unbounded"/> <xs:element name="incidentDescription" type="ct:EDXLStringType"

minOccurs="0" maxOccurs="unbounded"/> <xs:element ref="link" minOccurs="0" maxOccurs="unbounded"/> <xs:element ref="ext:extension" minOccurs="0" maxOccurs="unbounded" /> </xs:sequence> <xs:attributeGroup ref="xlink:resourceAttrs"/></xs:complexType><xs:element name="content" type="DEContentType"/><xs:complexType name="DEContentType"> <xs:sequence> <xs:element ref="contentObject" minOccurs="1" maxOccurs="unbounded"/> <xs:element ref="link" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attributeGroup ref="xlink:resourceAttrs"/></xs:complexType><xs:element name="link" type="DELinkType"/><xs:complexType name="DELinkType"> <xs:attributeGroup ref="xlink:arcAttrs"/></xs:complexType><xs:element name="contentDescriptor" type="DEContentDescriptorType"/><xs:complexType name="DEContentDescriptorType"> <xs:sequence> <xs:element name="contentDescription" type="ct:EDXLStringType" minOccurs="0"

maxOccurs="1"/> <xs:element name="contentKeyword" type="ct:ValueListType" minOccurs="0"

maxOccurs="unbounded"/> <xs:element name="originatorRole" type="ct:ValueListType" minOccurs="0"

maxOccurs="unbounded"/> <xs:element name="consumerRole" type="ct:ValueListType" minOccurs="0"

maxOccurs="unbounded"/> <xs:element name="contentID" type="ct:EDXLStringType" minOccurs="0"

maxOccurs="unbounded"/> <xs:element name="confidentiality" type="ConfidentialityType" minOccurs="0"

maxOccurs="1"/> <xs:element name="contentLanguage" type="xs:language" minOccurs="0"

maxOccurs="1"/>

25 May 2023

<xs:element ref="ext:extension" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence></xs:complexType><xs:element name="contentObject" type="DEContentObjectType"/><xs:complexType name="DEContentObjectType"> <xs:sequence> <xs:element ref="contentDescriptor" minOccurs="0" maxOccurs="1"/> <xs:choice minOccurs="1" maxOccurs="1">

<xs:element name="contentXML" type="ContentXmlType"/><xs:element name="otherContent" type="OtherContentType"/>

</xs:choice> <xs:element name="other" type="AnyXMLType" minOccurs="0"

maxOccurs="unbounded"/> </xs:sequence> <xs:attributeGroup ref="xlink:resourceAttrs"/></xs:complexType>

<xs:complexType name="OtherContentType" mixed="false"> <xs:sequence> <xs:element name="mimeType" type="ct:EDXLStringType" minOccurs="1"/> <xs:element name="size" type="xs:integer" minOccurs="0"/> <xs:element name="digest" type="xs:base64Binary" minOccurs="0"/> <xs:choice> <xs:sequence> <xs:element name="uri" type="xs:anyURI" /> <xs:element name="contentData" type="xs:base64Binary" minOccurs="0"/> </xs:sequence> <xs:element name="contentData" type="xs:base64Binary" /> </xs:choice> </xs:sequence> </xs:complexType>

<xs:complexType name="ContentXmlType" mixed="false"> <xs:sequence> <xs:element name="keyXMLContent" type="AnyXMLType" minOccurs="0"

maxOccurs="1"/> <xs:element name="embeddedXMLContent" type="AnyXMLType" minOccurs="1"

maxOccurs="1"/> </xs:sequence></xs:complexType><xs:complexType name="AnyXMLType"> <xs:sequence> <xs:any namespace="##other" processContents="strict" maxOccurs="1"/> </xs:sequence> <xs:anyAttribute namespace="##other" processContents="lax"/></xs:complexType><xs:complexType name="TargetAreasType"> <xs:sequence> <xs:element name="areaKind" type="AreaKindType" minOccurs="1"

maxOccurs="1"/> <xs:element name="areaGrouping" type="AreaGroupingType" minOccurs="1"

maxOccurs="1"/> <xs:element name="targetArea" type="TargetAreaType" minOccurs="1"

maxOccurs="unbounded"/> </xs:sequence></xs:complexType><xs:complexType name="TargetAreaType"> <xs:choice> <xs:element ref="edxl-gsf:EDXLGeoLocation" minOccurs="1" maxOccurs="1"/> <xs:element name="geoPoliticalLocation"

type="ct:EDXLGeoPoliticalLocationType" minOccurs="1" maxOccurs="1"/> </xs:choice>


28

</xs:complexType><xs:complexType name="ValueSchemeType"> <xs:sequence> <xs:element name="explicitAddressScheme" type="ct:EDXLStringType"/> <xs:element name="explicitAddressValue" type="ct:EDXLStringType"

minOccurs="1" maxOccurs="unbounded"/> </xs:sequence></xs:complexType>

<xs:simpleType name="AreaKindType"> <xs:restriction base="ct:EDXLStringType"> <xs:enumeration value="SourceTargetArea"/> <xs:enumeration value="DistributionTargetArea"/> <xs:enumeration value="OtherTargetArea"/> <xs:enumeration value="Unknown"/> <xs:enumeration value="NoAppropriateDefault"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="AreaGroupingType"> <xs:restriction base="ct:EDXLStringType">

<xs:enumeration value="Intersection"/><xs:enumeration value="Union"/><xs:enumeration value="ExclusiveOr"/><xs:enumeration value="Complement"/><xs:enumeration value="OtherGroupingType"/><xs:enumeration value="Unknown"/><xs:enumeration value="NoAppropriateDefault"/>

</xs:restriction> </xs:simpleType> <xs:simpleType name="ConfidentialityType"> <xs:restriction base="ct:EDXLStringType">

<xs:enumeration value="Unclassified"/> <xs:enumeration value="Classified"/>

</xs:restriction> </xs:simpleType> <xs:simpleType name="CertaintyType"> <xs:restriction base="ct:EDXLStringType">

<xs:enumeration value="Observed"/><xs:enumeration value="Likely"/><xs:enumeration value="Possible"/><xs:enumeration value="Unlikely"/><xs:enumeration value="Unknown"/><xs:enumeration value="NoAppropriateDefault"/>

</xs:restriction> </xs:simpleType> <xs:simpleType name="DistributionKindType"> <xs:restriction base="ct:EDXLStringType">

<xs:enumeration value="Report"/><xs:enumeration value="Update"/><xs:enumeration value="Cancel"/><xs:enumeration value="Request"/><xs:enumeration value="Response"/><xs:enumeration value="Dispatch"/><xs:enumeration value="Ack"/><xs:enumeration value="Error"/><xs:enumeration value="SensorConfiguration"/><xs:enumeration value="SensorControl"/><xs:enumeration value="SensorStatus"/><xs:enumeration value="SensorDetection"/><xs:enumeration value="Unknown"/><xs:enumeration value="NoAppropriateDefault"/>

25 May 2023

</xs:restriction> </xs:simpleType> <xs:simpleType name="DistributionStatusType"> <xs:restriction base="ct:EDXLStringType">

<xs:enumeration value="Actual"/><xs:enumeration value="Exercise"/><xs:enumeration value="System"/><xs:enumeration value="Test"/><xs:enumeration value="Unknown"/><xs:enumeration value="NoAppropriateDefault"/>

</xs:restriction> </xs:simpleType> <xs:simpleType name="SeverityType"> <xs:restriction base="ct:EDXLStringType">

<xs:enumeration value="Extreme"/><xs:enumeration value="Severe"/><xs:enumeration value="Moderate"/><xs:enumeration value="Minor"/><xs:enumeration value="Unknown"/><xs:enumeration value="NoAppropriateDefault"/>

</xs:restriction> </xs:simpleType> <xs:simpleType name="UrgencyType"> <xs:restriction base="ct:EDXLStringType">

<xs:enumeration value="Immediate"/><xs:enumeration value="Expected"/><xs:enumeration value="Future"/><xs:enumeration value="Past"/><xs:enumeration value="Unknown"/><xs:enumeration value="NoAppropriateDefault"/>

</xs:restriction> </xs:simpleType></xs:schema>


30

APPENDIX B. Distribution Element (DE) Domain Model

25 May 2023

APPENDIX C. Distribution Element (DE) Completed ExampleHere is an example DE message containing two Common Alert Protocol messages. This example includes the XML snippets shown above in this white paper. Many optional elements are used in this example, as well as multiple target areas, for demonstration purposes. The data, roles and related URIs are fictional, for demonstration purposes only.

<?xml version="1.0" encoding="UTF-8"?><edxlDistribution xlink:type="extended" xsi:schemaLocation="urn:oasis:names:tc:emergency:EDXL:DE:2.0 ../schema/edxl-de-v2.0-wd11.xsd urn:oasis:names:tc:emergency:cap:1.1 ./example-supporting-schema/cap.xsd http://myserver.org/test/ ./example-supporting-schema/test.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:oasis:names:tc:emergency:EDXL:DE:2.0" xmlns:edxl-gsf="urn:oasis:names:tc:emergency:edxl:gsf:1.0" xmlns:ext="urn:oasis:names:tc:emergency:edxl:extension:1.0" xmlns:ct="urn:oasis:names:tc:emergency:edxl:ct:1.0" xmlns:gml="http://www.opengis.net/gml/3.2" xmlns:xlink="http://www.w3.org/1999/xlink"> <distributionID>http://myhost.com/packages/17</distributionID> <senderID>[email protected]</senderID> <dateTimeSent>2009-11-15T16:53:00-05:00</dateTimeSent> <dateTimeExpires>2009-11-15T17:53:00-05:00</dateTimeExpires> <distributionStatus>Exercise</distributionStatus> <distributionKind>Report</distributionKind> <descriptor xlink:type="resource"> <combinedConfidentiality>Unclassified</combinedConfidentiality> <language>EN</language> <senderRole> <ct:ValueListURI>urn:myagency:gov:sensors:senderRole</ct:ValueListURI> <ct:Value>Search and Rescue</ct:Value> </senderRole> <recipientRole> <ct:ValueListURI>urn:myagency:gov:sensors:recipientRole</ct:ValueListURI> <ct:Value>Situational Awareness Apps</ct:Value> <ct:Value>Warning Devices</ct:Value> </recipientRole> <keyword> <ct:ValueListURI>urn:myagency:gov:sensors:keywords</ct:ValueListURI> <ct:Value>SNM Detection</ct:Value> <ct:Value>XYZ</ct:Value> </keyword> <explicitAddress> <explicitAddressScheme>e-mail</explicitAddressScheme> <explicitAddressValue>[email protected]</explicitAddressValue> </explicitAddress> <targetAreas> <areaKind>DistributionTargetArea</areaKind> <areaGrouping>Union</areaGrouping> <targetArea> <geoPoliticalLocation> <ct:GeoCode>


32

<ct:ValueListURI>http://www.unece.org/fileadmin/DAM/cefact/locode/usk.htm</ct:ValueListURI> <ct:Value>USNYC</ct:Value> </ct:GeoCode> </geoPoliticalLocation> </targetArea> </targetAreas> <targetAreas> <areaKind>SourceTargetArea</areaKind> <areaGrouping>Union</areaGrouping> <targetArea> <edxl-gsf:EDXLGeoLocation> <gml:Polygon gml:id="myPolygon"> <gml:exterior> <gml:LinearRing> <gml:pos>33.4745 -112.1174</gml:pos> <gml:pos>33.4238 -112.0238</gml:pos> <gml:pos>33.4238 -112.1174</gml:pos> <gml:pos>33.4745 -112.1174</gml:pos> </gml:LinearRing> </gml:exterior> </gml:Polygon> </edxl-gsf:EDXLGeoLocation> </targetArea> <targetArea> <edxl-gsf:EDXLGeoLocation> <gml:CircleByCenterPoint numArc="1"> <gml:pos>33.4745 -112.1174</gml:pos> <gml:radius uom="urn:ogc:def:uom:UCUM:km">3</gml:radius> </gml:CircleByCenterPoint> </edxl-gsf:EDXLGeoLocation> </targetArea> </targetAreas> <urgency>Immediate</urgency> <severity>Minor</severity> <certainty>Observed</certainty> <ext:extension> <ext:community>http://www.mytestserver.org/layers/</ext:community> <ext:id>earthquake</ext:id> <ext:parameter> <ext:nameURI>http://www.mytestserver.org/layers/earthquake/Name</ext:nameURI> <ext:value>Earthquake1</ext:value> </ext:parameter> <ext:parameter> <ext:nameURI>http://www.mytestserver.org/layers/earthquake/Magnitude</ext:nameURI> <ext:value uom="http://www.mytestserver.org/layers/earthquake/RichterScale">5.3</ext:value> </ext:parameter> <ext:parameter> <ext:nameURI>http://www.mytestserver.org/layers/earthquake/EventTime</ext:nameURI> <ext:value>2010-08-30T23:25:40+00:00</ext:value> </ext:parameter> <ext:parameter> <ext:nameURI>http://www.mytestserver.org/layers/earthquake/Depth</ext:nameURI> <ext:value uom="http://qudt.org/vocab/unit/MileInternational">38.7</ext:value> </ext:parameter> </ext:extension> <ext:extension>

25 May 2023

<ext:community>http://mycommunity.org</ext:community> <ext:id>layer1</ext:id> <ext:parameter> <ext:nameURI>http://mycommunity.org/layer1/urgency</ext:nameURI> <ext:value>Low</ext:value> </ext:parameter> </ext:extension> </descriptor> <content xlink:type="resource"> <contentObject xlink:type="resource"> <contentXML> <embeddedXMLContent><test xmlns="http://myserver.org/test/"></test></embeddedXMLContent> </contentXML> </contentObject> <contentObject xlink:type="resource"> <otherContent> <mimeType>image/jpeg</mimeType> <uri>http://www.myhost.com/pictures/pic333</uri> </otherContent> </contentObject> <contentObject xlink:type="resource"> <contentXML> <embeddedXMLContent> <alert xmlns = "urn:oasis:names:tc:emergency:cap:1.1"> <identifier>http://www.myagency.gov/alerts/25</identifier> <sender>[email protected]</sender> <sent>2005-11-15T16:58:00-05:00</sent> <status>Exercise</status> <msgType>Update</msgType> <scope>Public</scope> <info> <category>Transport</category> <event>Traffic Routes</event> <urgency>Immediate</urgency> <severity>Moderate</severity> <certainty>Likely</certainty> <description>Traffic adjustments ensure clear routes to St. Josephs Hospital and Phoenix Childrens Hospital on Thomas Rd. </description> <area> <areaDesc>Best Routes</areaDesc> <polygon>38.91655012246089,-77.02016267943407 38.91655012246089,-77.0117098391165 38.907662564641285,-77.0117098391165 38.907662564641285,-77.02016267943407 38.91655012246089, -77.02016267943407</polygon> </area> </info> </alert> </embeddedXMLContent> </contentXML> </contentObject> <contentObject xlink:type="resource"> <contentXML> <embeddedXMLContent> <alert xmlns = "urn:oasis:names:tc:emergency:cap:1.1"> <identifier>http://www.myagency.gov/alerts/26</identifier> <sender>[email protected]</sender> <sent>2005-11-15T17:00:00-05:00</sent> <status>Exercise</status>


34

<msgType>Update</msgType> <scope>Public</scope> <info> <category>Transport</category> <event>Traffic Routes</event> <urgency>Immediate</urgency> <severity>Moderate</severity> <certainty>Likely</certainty> <description>Traffic adjustments ensure clear routes to St. Josephs Hospital and Phoenix Childrens Hospital on Thomas Rd. </description> <area> <areaDesc>Best Routes</areaDesc> <polygon>38.91655012246089,-77.02016267943407 38.91655012246089,-77.0117098391165 38.907662564641285,-77.0117098391165 38.907662564641285,-77.02016267943407 38.91655012246089, -77.02016267943407 </polygon> </area> </info> </alert> </embeddedXMLContent> </contentXML> </contentObject> </content></edxlDistribution>

25 May 2023

advancing open standards for the information …€¦ · web viewopen standards improve...

Documents