OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

emergency message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [emergency] Groups - EDXL-DE-FormalSpec-DRAFT (Emergency Data Exchange Language (EDXL) Distriubution Element.pdf) uploaded


Sylvia,

I was looking at the difference file before I responded to Renato and
did not see that the left side corresponded with the right, perhaps
due to such drastic differences.  If I have time I thought I would
just draw up his model in the same format as the DOM in the Spec. for
easier comparison.

I've continued cleaning up Section 3 and the Appendices.  If you are
awake and want to pull together something in the header and sections 1
and/or 2 in XHTML that would be grand.  I'll include the current pass
as it stands at this second. If you are working on some other part or
Section 3, let's coordinate.

- Michelle



On 8/5/05, Sylvia Webb <swebb@gefeg.com> wrote:
> Renato,
> 
> You are correct. This was done at the request of Tom Merkle during a short
> call after a EDXL SC call on July 21st.  It was decided that there were
> items in the later model that needed discussion and TC buy-in.
> 
> In the package created for review at
> http://www.oasis-open.org/apps/org/workgroup/emergency/download.php/13784/ED
> XL_Dist_Draft1.zip, a comparison of the schema that Tom Merkle provided and
> the one you provided on June 28th lists the specific differences.
> 
> Regards,
> Sylvia
> 
> -----Original Message-----
> From: Renato Iannella [mailto:renato@nicta.com.au]
> Sent: Thursday, August 04, 2005 6:50 PM
> To: Emergency_Mgt_TC TC
> Subject: Re: [emergency] Groups - EDXL-DE-FormalSpec-DRAFT (Emergency Data
> Exchange Language (EDXL) Distriubution Element.pdf) uploaded
> 
> 
> 
> On 4 Aug 2005, at 21:09, Elysa Jones wrote:
> 
> > MANY thanks to Michelle and Sylvia for getting this spec ready to
> > review.  Please take the time to look it over in the spirit of getting
> > this ready for a final TC review and out the door.  We have set a goal
> > to have this in public comment by mid August, so let's take the time
> > to look over, add content, and verify internal consistency in the
> > document as well as consistency with what we
> > have all argued about and agreed to over the last several months.
> > Until the telecon Fri (that is tomorrow Aug 5 11:00 EDT), Elysa
> 
> This version of the spec seems to be based on the older data model based
> document (2005-May-2) and not the newer information model based document
> (2005-Jun-20)  ??
> 
> 
> Cheers...  Renato Iannella
> National ICT Australia (NICTA)
> 
> 
> --------------------------------------------------------------------------
> This email and any attachments may be confidential. They may contain legally
> privileged information or copyright material. You should not read, copy, use
> or disclose them without authorisation. If you are not an intended
> recipient, please contact us at once by return email and then delete both
> messages. We do not accept liability in connection with computer virus, data
> corruption, delay, interruption, unauthorised access or unauthorised
> amendment. This notice should not be removed.
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your TCs in OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your TCs in OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> 
>
Title: Emergency Data Exchange Language (EDXL) Distriubution Element

OASIS logo

Emergency Data Exchange Lanaguage (EDXL) Distribution Element, v. 1.0

Committee Draft, 05, August 2005

Document Identifier:

[Document Identifier as per OASIS Artifact Naming Guidelines]

OASIS Identifier:

[OASIS Document Number]

Location:

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

Technical Committee:

OASIS Emergency Management TC

Chair(s):

Elysa Jones, Warning Systems, Inc

Editor(s):

Michelle Raymond, Knowledge Interaction Consulting

Sylvia Webb, [company name]

Subject / Keywords:

[Comma-separated keyword listing]

OASIS Conceptual Topic Model Area:

[Please refer to (link) for appropriate topic area]]

Related Work:

This specification replaces or supercedes:

[specifications replaced by this standard - OASIS as well as other standards organizations]

[specifications replaced by this standard - OASIS as well as other standards organizations]

This specification is related to:

[specifications related to this standard - OASIS as well as other standards organizations]

[specifications related to this standard - OASIS as well as other standards organizations]

Abstract:

This Distribution Element specification describes a standard message distribution framework for data sharing among emergency information systems using the XML-based Emergency Data Exchange Language (EDXL). This format may be used over any data transmission system, including but not limited to the SOAP HTTP binding.

Status:

This document was last revised or approved by the Emergency Management Technical Committee on the above date. The level of approval is also listed above. Check the current location noted above for possible later revisions of this document. This document is updated periodically on no particular schedule.

Technical Committee members should send comments on this specification to the Technical Committee’s email list. Others should send comments to the Technical Committee by using the “Send A Comment” button on the Technical Committee’s web page at www.oasis-open.org/committees/emergency.

For information on whether any patents have been disclosed that may be essential to implementing this specification, and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of the Technical Committee web page ( www.oasis-open.org/committees/emergency/ipr.php.

The non-normative errata page for this specification is located at www.oasis-open.org/committees/[specific location].

Notices

OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS's procedures with respect to rights in OASIS specifications can be found at the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification, can be obtained from the OASIS President.

OASIS invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to implement this specification. Please address the information to the OASIS President.

Copyright © OASIS Open 2004. All Rights Reserved.

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 paragraph are included on all such copies and derivative works. However, this document itself does not be modified in any way, such as by removing the copyright notice or references to OASIS, except as needed for the purpose of developing OASIS specifications, in which case the procedures for copyrights defined in the OASIS Intellectual Property Rights document must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.

This document and the information contained herein is provided on an “AS IS” basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Table of Contents

[build table of contents here. Should list at least 3 levels (sections numbered x.x.x) which are hyperlinked to the actual section.]

1 Introduction

1.1 Purpose

1.2 History

1.3 Structure of the EDXL Distribution Element

1.3.1 <distribution>

1.3.2 <targetArea>

1.3.3 <messageElement>

1.3.4 <contentObject>

1.4 Application of the EDXL Distribution Element

1.5 Terminology

1.6 Normative References

1.7 Non-Normative References

2 Design Principles and Concepts (non-normative)

2.1 Design Philosophy

2.2 Requirements for Design

2.3 Example Usage Scenarios

3 Distribution Element Structure (normative)

3.1 Document Object Model

3.2 Data Dictionary

3.2.1 EDXLDist Element and Sub-elements

3.2.2 targetArea Element and Sub-elements

3.2.3 messageElement Element and Sub-elements

3.2.4 contentObject Element

3.2.4.1 contentObject Element and Sub-elements: Option 1

3.2.4.2 contentObject Element and XML Content: Option 2

A. Examples of Distribution Element XML Documents

A.1 Example 1: Sentry Alert Distribution

A.2 Example 2: School Alert Distribution

B. XML Schema for the Distribution Element

C. Acknowledgements

D. Revision History

1. Introduction

[All text is normative unless otherwise labeled.]

1.1 Purpose

[The purpose of the EDXL DE goes here.]

1.2 History

[The history of the EDXL DE goes here.]

1.3 Structure of the EDXL Distribution Element

The EDXL Distribution Element (DE) comprises a <distribution> element as described hereafter, optional <targetArea> elements describing geospatial or political target area for message delivery, and a set of <messageElement> elements each containing specific information regarding a particular item of content, which it includes within a <contentObject>structure. The included content may be any XML or other file or document.

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

1.3.1 <distribution>

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

Note that use of the <distribution> 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.

1.3.2 <targetArea>

[basic targetArea description goes here]

1.3.3 <messageElement>

[basic messageElement description goes here]

1.3.4 <contentObject>

[basic contentObject description goes here]

1.4 Applications of the EDXL Distribution Element

[The applications of the EDXL DE goes here.]

1.5 Terminology

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” are to be interpreted as described in [RFC2119].

1.6 Normative References

[RFC2046]

N. Freed, Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types, http://www.ietf.org/rfc/rfc2046.txt, IETF RFC 2046, November 1996.

[RFC2119]

S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, http://www.ietf.org/rfc/rfc2119.txt, IETF RFC 2119, March 1997.

[Reference]

[Full reference citation]

1.7 Non-Normative References

[Reference]

[Full reference citation]

2. Design Principles and Concepts (non-normative)

[design explanation goes here.]

2.1 Design Philosophy

2.2 Requirements for Design

2.3 Example Usage Scenarios

3. Distribution Element Structure (normative)

[body of standard goes here]

3.1 Document Object Model

Bold indicates required element.
* indicates multiple instances allowed
EDXLDist
messageID
senderID
dateTimeSent
messageStatus
messageType
senderRole *
recipientRole *
keyword *
messageReference *
explicitAddress *
lowestConfidentiality
* 

targetArea
circle *
polygon *
country *
subdivision *
location *
|  
|  
*
messageElement
keyXmlContent
messageSenderRole *
messageRecipientRole *
confidentiality
1 

contentObject
contentDescription
mimeType
size
uri
derefUri
digest
OR
contentObject
{ XML Content }

3.2 Data Dictionary

3.2.1 EDXLDist Element and Sub-elements

Element EDXLDist
Definition The container element for all content necessary to the originator's intent as to the dissemination of that particular message or set of messages.
(REQUIRED)
Notes
  1. The <EDXLDist> element may include <targetArea> and <messageElement> blocks.
  2. Use of the <EDXLDist> element does not guarantee that all network links and nodes will implement the asserted dissemination policy or that unintended disclosure will not occur. Where sensitive information is transmitted over untrusted networks, it should be encrypted in accordance with the Web Services Security (WSS) standard (<http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf>) with any updates and errata published by the OASIS Web Services Security Technical Committee (<http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss>), or some other suitable encryption scheme.
Sub-elements

Element messageID
Type xsd:string
Definition An identifier string for this message, assigned by the sender to be unique for that sender.
(REQUIRED)
Used In EDXLDist

Element senderID
Type xsd:string
Definition A unique identifier for the sender in the form actor@domain-name.
(REQUIRED)
Notes 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.
Used In EDXLDist

Element dateTimeSent
Type xsd:dateTime
Definition The date and time the message was sent, in the ISO-8601 format for the XML DateTime data type.
(REQUIRED)
Notes Example: 2004-08-01T16:49:00-07:00
Used In EDXLDist

Element messageStatus
Type restricted xsd:string value to: Actual, Exercise, System or Test
Definition The actionability of the message.
(REQUIRED)
Notes 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
Used In EDXLDist

Element messageType
Type restricted xsd:string value to: Ack, Cancel, Dispatch, Error, Report, Request, Response or Update
Definition The function of the message.
(REQUIRED)
Notes Value must be one of:
  • Report - New information regarding an incident or activity
  • Update - Updated information superceding 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 - Acknowledgement of receipt of an earlier message
  • Error - Rejection of an earlier message (for technical reasons)
Used In EDXLDist

Element senderRole
Type value list pair
Definition Any value from a discrete managed list, used to inform message routing decisions by describing the functional role of the sender.
(MAY have multiple)
Notes
  1. The value list pair is in the form:
       <senderRole>
          <valueListUrn>valueListUrn</valueListURN>
          <value>value</value>
       </senderRole>
    where the content of "valueListUrn" is the Uniform Resource Name of a published list of values and definitions, and the content of "value" is a string (which may represent a number) denoting the value itself.
  2. Multiple instances of the <valueListUrn>, <value> pairs MAY occur within a single <senderRole> structure.
  3. Multiple instances of <senderRole> MAY occur within a single <EDXLDist> block.
Used In EDXLDist

Element recipientRole
Type value list pair
Definition Any value from a discrete managed list, used to inform message routing decisions by describing the functional role of the recipient.
(MAY have multiple)
Notes
  1. The value list pair is in the form:
       <recipientRole>
          <valueListUrn>valueListUrn</valueListURN>
          <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 "value" is a string (which may represent a number) denoting the value itself.
  2. Multiple instances of the <valueListUrn>, <value> pairs MAY occur within a single <recipientRole> structure.
  3. Multiple instances of <recipientRole> MAY occur within a single <EDXLDist> block.
Used In EDXLDist

Element keyword
Type value list pair
Definition Any value from a discrete managed list, used to inform message routing decisions.
(MAY have multiple)
Notes
  1. The value list pair is in the form:
       <keyword>
          <valueListUrn>valueListUrn</valueListURN>
          <value>value</value>
       </keyword>
    where the content of "valueListUrn" is the Uniform Resource Name of a published list of values and definitions, and the content of "value" is a string (which may represent a number) denoting the value itself.
  2. Examples of things <keyword> might be used to describe include event type, event etiology, incident ID and response type.
  3. Multiple instances of the <valueListUrn>, <value> pairs MAY occur within a single <keyword> structure.
  4. Multiple instances of <keyword> MAY occur within a single <EDXLDist> block.
Used In EDXLDist

Element messageReference
Type xsd:string
Definition The <messageID> and <senderID> and <dateTimeSent> of the referenced previous message, concatenated with a ":" delimiter.
(MAY have multiple)
Notes
  1. This element should appear at least once in any message which updates, cancels or otherwise refers to another message.
  2. Example: msgID0074:actor@domain-name:2004-08-01T16:49:00-07:00
Used In EDXLDist

Element explicitAddress
Type xsd:string
Definition
(MAY have multiple)
Notes
Used In EDXLDist

Element lowestConfidentiality
Type xsd:string
Definition Special requirements regarding confidentiality of the content of this <EDXLDist> element.
(Only one MAY be provide)
Used In EDXLDist

3.2.2 targetArea Element and Sub-elements

Element targetArea
Definition The container element for location information.
(MAY have multiple)
Notes
  1. The targetArea is a container element for the geospatial or political area targeting of the message.
  2. Multiple <targetArea> blocks may appear in a single <EDXLDist> element, in which case the target area for the current message is the union of all areas described in the various <targetArea> structures.
Sub-elements
Used In EDXLDist

Element circle
Type xsd:string
Definition An enclosed area within a given radius around a geographic point.
(MAY have multiple)
Notes
  1. The element is represented in the form "latitude, longitude radius."
  2. The central point is represented per the specification for <site> in the form of latitude and longitude while the space-separated radius value is expressed in kilometers.
  3. Example: 38.26295,-122.07454 15

NOTE: What <site> element is this referencing? The exact spec. should be noted.

Used In targetArea

Element polygon
Type xsd:string
Definition An enclosed gegraphic area within a simple closed polygon defined by an ordered set of vertices.
(MAY have multiple)
Notes
  1. Represented by a space-delimited series of latitude, longitude pairs, with the last pair identical to the first.
  2. Example: 42,-124.2102 42,-120.1 39,-120 35.0,-114.6328 34.35,- 120.4418 38.9383,-123.817 42,-124.2102
Used In targetArea

Element country
Type xsd:string
Definition The two-character ISO 3166 alpha-2 Country Code for the country concerned.
(MAY have multiple)
Used In targetArea

Element subdivision
Type xsd:string
Definition The ISO 3166-2 designator for the administrative subdivision concerned.
(MAY have multiple)
Notes
  1. The first two characters, before the hyphen, is the ISO 3166 alpha-2 Country Code for the country within which the designated subdivision is located. The following one-to-three characters following the hyphen designate the particular sudivision.
  2. Examples: MG-T, DK-025 and US-TX
Used In targetArea

Element location
Type xsd:string
Definition The UN/LOCODE designator for the location concerned.
(MAY have multiple)
Notes
  1. The two first digits are the ISO 3166 alpha-2 Country Code for the country in which the place is located. The follwing three characters are the UN/LOCODE designator for the particular location within that country. No spaces or punctuation are used within this designator.
  2. Examples: GBFFD, USSUU and USFFB
Used In targetArea

3.2.3 messageElement Element and Sub-elements

Element messageElement
Definition The container element for message content.
(MAY have multiple)
Notes
  1. This element MUST assert an explicit namespace for any included XML content in <keyXmlContent> and/or <contentObject>.
  2. If no namespace is asserted in the <messageElement> tag, the enclosed content MAY be assumed to be non-XML.
Sub-elements
Used In EDXLDist

Element keyXMLContent
Definition A container element for collected fragments of a valid XML document contained within an <xmlContent> element within the current <messageElement> block.
(MAY have only one)
Notes All content within this element MUST be explicitly namespaced as defined in the enclosing <messageElement> tag.
Used In messageElement

Element messageSenderRole
Type value list pair
Definition Any value from a discrete managed list, used to inform message routing decisions by describing the functional role of the sender.
(MAY have multiple)
Notes
  1. The value list pair is in the form:
       <messageSenderRole>
          <valueListUrn>valueListUrn</valueListURN>
          <value>value</value>
       </messageSenderRole>
    where the content of "valueListUrn" is the Uniform Resource Name of a published list of values and definitions, and the content of "value" is a string (which may represent a number) denoting the value itself.
  2. Multiple instances of the <valueListUrn>, <value> pairs MAY occur within a single <messageSenderRole> structure.
  3. Multiple instances of <messagSenderRole> MAY occur within a single <messageElement> block.
Used In messageElement

Element messageRecipientRole
Type value list pair
Definition Any value from a discrete managed list, used to inform message routing decisions by describing the functional role of the recipient.
(MAY have multiple)
Notes
  1. The value list pair is in the form:
       <messageRecipientRole>
          <valueListUrn>valueListUrn</valueListURN>
          <value>value</value>
       </messageReciepientRole>
    where the content of "valueListUrn" is the Uniform Resource Name of a published list of values and definitions, and the content of "value" is a string (which may represent anumber) denoting the value itself
  2. Multiple instances of the <valueListUrn>, <value> pairs MAY occur within a single <recipientRole> structure.
  3. Multiple instances of <messageRecipientRole> MAY occur within a single <messageElement> block.
Used In messageElement

Element responseType
Type
Definition
(MAY have only one)
Notes
Used In messageElement

Element confidentiality
Type xsd:string
Definition Special requirements regarding confidentiality of the content of this <messageElement>
(MAY have only one)
Used In messageElement

3.2.4 contentObject Element

Element contentObject
Definition Container element for the actual message content.
(MUST have only one)
Notes
  1. The message content MAY be either a separately-namespaced XML document or some item of non-XML content.
  2. If the enclosed content is XML it MUST be explicitly namepaced as defined in the enclosing <messageElement> tag. Enclosed XML content may be encrypted and/or signed within this element.
  3. This element MUST be present unless the Distribution Element is used in a query to, or a response from, a directory service.
Used In messageElement

3.2.4.1 contentObject Sub-elements: Option 1

Element contentDescription
Type xsd:string
Definition
(MAY have only one)
Notes
Used In contentObject

Element mimeType
Type xsd:string
Definition MIME content type and sub-type as described in [RFC 2046].
(MAY have only one)
Used In contentObject

Element size
Type xsd:integer
Definition Approximate size of the content item (in its un-encoded form) in bytes.
(MAY have only one)
Used In contentObject

Element uri
Type xsd:anyURI
Definition Either a full absolute URI, typically a Uniform Resource Locator, that can be used to retrieve the resource over the Internet, or a relative URI naming the file represented in the <derefUri>.
(MAY have only one)
Used In contentObject

Element derefUri
Type xsd:string
Definition The base-64 encoded data content. MAY be used either with or instead of the <uri> element in contexts where retrieval of a resource via a URI is not feasible.
(MAY have only one)
Used In contentObject

Element digest
Type xsd:string
Definition The digital digest ("hash") of the content item calculated using the Secure Hash Algorithm (SHA-1) per [FIPS 180-2]
(MAY have only one)
Used In contentObject

3.2.4.2 contentObject XML Content: Option 2

Element xmlContent
Type valid xml
Definition
(MAY have only one)
Notes
Used In contentObject

3.2.5 Value list pair

The value list pair of valueListUrn and value is generally contained within another element in the form:
   <containerElement>
      <valueListUrn>valueListUrn</valueListURN>
      <value>value</value>
   </containerElement>

Element valueListUrn
Type xsd:string
Definition The content of <valueListUrn> is the Uniform Resource Name of a published list of values and definitions
(REQUIRED)
Notes Example: http://www.dhs.govNiemAgencyType
Used In

Element value
Type xsd:string
Definition The content of <value> is a string (which may represent a number) denoting the value itself.
(REQUIRED)
Notes Example: Fire Department
Used In

Appendix A. Examples of Distribution Element XML Documents

[Example files go here - MICHELLE]

[NOTE: Formating needs to be worked out and content is a place holder (MR)]

Example 1: Sentry Alert Distribution

<?xml version="1.0" encoding="UTF-8" standalone="no"?> <EDXLDist xmlns="http://www.incident.com/EDXLDist/1.0" > <messageID>12345</messageID > <senderID>dellis@sandia.gov</senderID> <dateTimeSent>2005-05-01T18:00:00-06:00</dateTimeSent> <messageStatus>Actual</messageStatus> <messageType>Report</messageType> <messageReference></messageReference> <recipentAddress></recipentAddress> <lowestConfidentiallity>FOUO</lowestConfidentiallity> <targetArea> <location>USSUU</location> </targetArea> <messageElement> <keyword> <valueListUrn>a</valueListUrn> <value>b</value> </keyword> <senderRole> <valueListUrn>c</valueListUrn> <value>d</value> </senderRole> <recipentRole> <valueListUrn>e</valueListUrn> <value>f</value> </recipentRole> <responseType> <valueListUrn>g</valueListUrn> <value>h</value> </responseType> <confidentiallity>FOUO</confidentiallity> <keyXmlContent xmlns:cap="http://www.incident.com/CAP/1.0" > <cap:category>other</cap:category> <cap:event>chemical</cap:event> </keyXmlContent> <contentOject> <Payload xmlns:cap="http://www.incident.com/CAP/1.0" > <cap:identifier>SENTRY_01</cap:identifier> <cap:sender>SENTRY</cap:sender> <cap:sent>2005-05-01T18:08:00-06:00</cap:sent> <cap:status>Test</cap:status> <cap:msgType>Alert</cap:msgType> <cap:scope>Public</cap:scope> <cap:note>This comment is Extraordinarily tremendous!!</cap:note> <cap:incidents>MWM-13407</cap:incidents> <cap:info> <cap:category>Other</cap:category> <cap:event>chemical</cap:event> <cap:urgency>Immediate</cap:urgency> <cap:severity>Unknown</cap:severity> <cap:certainty>Unknown</cap:certainty> <cap:senderName>SENTRY</cap:senderName> <cap:headline>LV 2 CWA Low Blister</cap:headline> <cap:description>SENTRY has detected a(n) chemical event: MWM-13407 from Site: Tiedown. Its Primary Source is: LV 2 CWA Low Blister, it has a priority of 4, and is located at -77.099953,38.800035 Comment: This comment is Extraordinarily tremendous!!</cap:description> <cap:resource> <cap:resourceDesc>Video clip from Sensor: CWDET-01, Site: Tiedown, having a Detection class of CWDET. Video specs: Length: 23 Type: mpeg Channel Band: Channel A</cap:resourceDesc> <cap:uri>http://sentry/videoClip1</cap:uri> </cap:resource> <cap:resource> <cap:resourceDesc>Photo image from Sensor: CWDET-01, Site: Tiedown, having a Detection class of CWDET. Photo specs: Type: jpeg Channel Band: Channel B</cap:resourceDesc> <cap:uri>http://sentry/photoCapture</cap:uri> </cap:resource> </cap:info> </Payload> </contentOject> </messageElement> </EDXLDist>

Example 2: School Alert Distribution

<?xml version="1.0" encoding="UTF-8" standalone="no"?> <distribution xmlns="http://www.incident.com/EDXLDist/1.0" > <messageID>schoolEvac050214130000</messageID > <senderID>em@centralhigh.centerville.edu</senderID> <dateTimeSent>2005-02-14T13:00:00-05:00</dateTimeSent> <messageStatus>Actual</messageStatus> <messageType>Update</messageType> <senderRole> <valueListURN>centerville.edu.senderRole.schoolEmergencyManager<valueListURN></valueListURN> <value>Principal</value> </senderRole> <recipientRole> <valueListURN>centerville.edu.recipientRole.centralhigh.allSchool</valueListURN> <value>Parents</value> </recipientRole> <recipientRole> <valueListURN>centerville.edu.recipientRole.centralhigh.support</valueListURN> <value>Busing</value> </recipientRole> <keyword> <valueListURN>centerville.edu.keyword.incident.phase</valueListURN> <value>BusRelease</value> </keyword> <messageReference>schoolEmergency050214112019:em@centralhigh.edu:2005-02-14T11:20:19-05:00</messageReference> <recipentAddress>centralhigh.metropolis.edu/studentGuardians</recipentAddress> <messageElement> <keyword> <valueListUrn>district.metropolis.edu.pickupLoc</valueListUrn> <value>Metropolis Community Center</value> </keyword> <keyword> <valueListUrn>district.metropolis.edu/busSched</valueListUrn> <value>Variable</value> </keyword> <messageFormat> </messageFormat> <senderRole> <valueListUrn>centralhigh.metropolis.edu/facultyStaff</valueListUrn> <value>Principal</value> </senderRole> <recipentRole> <valueListUrn>centralhigh.metropolis.edu/studentGuardians</valueListUrn> <value>guardiansAll</value> </recipentRole> </distribution>

Appendix B. XML Schema for the Distribution Element

<?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns="http://www.incident.com/EDXLDist/1.0" targetNamespace="http://www.incident.com/EDXLDist/1.0" elementFormDefault="qualified" attributeFormDefault="unqualified"> <xs:element name="EDXLDist"> <xs:annotation> <xs:documentation> The container element for the distribution element. May include <targetArea> and <messageElement> blocks. </xs:documentation> <xs:documentation> EDXL Distribution Message (version 0.5) </xs:documentation> </xs:annotation> <xs:complexType> <xs:sequence> <xs:element name="messageID" type="xs:string"> <xs:annotation> <xs:documentation> An identifier string for this message, assigned by the sender to be unique for that sender. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="senderID" type="xs:string"> <xs:annotation> <xs:documentation> A unique identifier for the sender in the form actor@domain-name, with uniqueness of the domain-name guaranteed through use of the Internet Domain Name System, and uniqueness of the actor name enforced by the domain owner. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="dateTimeSent" type="xs:dateTime"> <xs:annotation> <xs:documentation> The date and time the message was sent, in the ISO-8601 format for the XML DateTime data type. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="messageStatus" type="xs:string"> <xs:annotation> <xs:documentation> The actionability of the message. 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 </xs:documentation> </xs:annotation> </xs:element> <xs:element name="messageType"> <xs:annotation> <xs:documentation> The function of the message. Value must be one of: Report - New information regarding an incident or activity Update - Updated information superceding 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 - Acknowledgement of receipt of an earlier message Error - Rejection of an earlier message (for technical reasons) </xs:documentation> </xs:annotation> <xs:simpleType> <xs:restriction base="xs:string"> <xs:enumeration value="Ack"/> <xs:enumeration value="Cancel"/> <xs:enumeration value="Dispatch"/> <xs:enumeration value="Error"/> <xs:enumeration value="Report"/> <xs:enumeration value="Request"/> <xs:enumeration value="Resonse"/> <xs:enumeration value="Update"/> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="senderRole" minOccurs="0" maxOccurs="unbounded"> <xs:annotation> <xs:documentation> 1. Any value from a discrete managed list, used to inform message routing decisions by describing the functional role of the sender, in the form of <valueListUrn>, <value> pairs. 2. Multiple instance of the <valueListUrn>, <value> pairs MAY occur within a single <senderRole> structure. 3. Multiple instances of <senderRole> MAY occur within a single <messageElement> block. </xs:documentation> </xs:annotation> <xs:complexType> <xs:sequence> <xs:element ref="valueListUrn"> <xs:annotation> <xs:documentation> The content of "valueListUrn" is the Uniform Resource Name of a published list of values and definitions. </xs:documentation> </xs:annotation> </xs:element> <xs:element ref="value"> <xs:annotation> <xs:documentation> The content of "value" is a string (which may represent a number) denoting the value itself. </xs:documentation> </xs:annotation> </xs:element> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="recipentRole" minOccurs="0" maxOccurs="unbounded"> <xs:annotation> <xs:documentation> 1. Any value from a discrete managed list, used to inform message routing decisions by describing the functional role of the recipient, in the form: where the content of "valueListUrn" is the Uniform Resource Name of a published list of values and definitions, and the content of "value" is a string (which may represent a number) denoting the value itself 2. Multiple instance of <value> MAY occur within a single <recipientRole> structure. 3. Multiple instances or <recipientRole> MAY occur within a single <messageElement> block. </xs:documentation> </xs:annotation> <xs:complexType> <xs:sequence> <xs:element ref="valueListUrn"> <xs:annotation> <xs:documentation> The content of "valueListUrn" is the Uniform Resource Name of a published list of values and definitions. </xs:documentation> </xs:annotation> </xs:element> <xs:element ref="value"> <xs:annotation> <xs:documentation> The content of "value" is a string (which may represent a number) denoting the value itself. </xs:documentation> </xs:annotation> </xs:element> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="keyword" minOccurs="0" maxOccurs="unbounded"> <xs:annotation> <xs:documentation> 1. Any value from a discrete managed list, used to inform message routing decisions, in the form: <keyword> <valueListUrn>valueListUrn</valueListURN> <value>value</value> </keyword> where the content of "valueListUrn" is the Uniform Resource Name of a published list of values and definitions, and the content of "value" is a string (which may represent a number) denoting the value itself 2. Examples of things <keyword> might be used to describe include event type, event etiology, incident ID and response type. 3. Multiple instance of <value> MAY occur within a single <keyword> structure. 4. Multiple instances of <keyword> MAY occur within a single <messageElement> block. </xs:documentation> </xs:annotation> <xs:complexType> <xs:sequence> <xs:element ref="valueListUrn"> <xs:annotation> <xs:documentation> The content of "valueListUrn" is the Uniform Resource Name of a published list of values and definitions. </xs:documentation> </xs:annotation> </xs:element> <xs:element ref="value"> <xs:annotation> <xs:documentation> The content of "value" is a string (which may represent a number) denoting the value itself. </xs:documentation> </xs:annotation> </xs:element> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="messageReference" type="xs:string" minOccurs="0" maxOccurs="unbounded"> <xs:annotation> <xs:documentation> The messageID and senderID and dateTimeSent of the referenced previous message, concatenated with a ":" delimiter (should appear at least once in any message which updates, cancels or otherwise refers to another message.) </xs:documentation> </xs:annotation> </xs:element> <xs:element name="explicitAddress" type="xs:string" minOccurs="0" maxOccurs="unbounded"/> <xs:element name="lowestConfidentiallity" type="xs:string" minOccurs="0"> <xs:annotation> <xs:documentation> Special requirements regarding confidentiality of the content of this <messageElement>. </xs:documentation> </xs:annotation> </xs:element> <xs:element ref="targetArea" minOccurs="0" maxOccurs="unbounded"> <xs:annotation> <xs:documentation> The container element for geospatial or political-area targeting of the message. Multiple <targetArea> blocks may appear in a single <distribution> element, in which case the target area for the current message is the union of all areas described in the various <targetArea> structures. </xs:documentation> <xs:documentation> TargetArea is a container for location information. </xs:documentation> </xs:annotation> </xs:element> <xs:element ref="messageElement" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="targetArea"> <xs:annotation> <xs:documentation>T argetArea is a container for location information. </xs:documentation> <xs:documentation> The container element for geospatial or political-area targeting of the message. Multiple <targetArea> blocks may appear in a single <distribution> element, in which case the target area for the current message is the union of all areas described in the various <targetArea> structures. </xs:documentation> </xs:annotation> <xs:complexType> <xs:sequence> <xs:element name="circle" type="xs:string" minOccurs="0" maxOccurs="unbounded"> <xs:annotation> <xs:documentation> An enclosed area within a given radius around a geographic point, represented in the form "latitude,longitude radius". The central point is represented per the specification for <site>, while the space-separated radius value is expressed in kilometers </xs:documentation> </xs:annotation> </xs:element> <xs:element name="polygon" type="xs:string" minOccurs="0" maxOccurs="unbounded"> <xs:annotation> <xs:documentation> An enclosed geographic area within a simple closed polygon defined by an ordered set of vertices. Represented by a space-delimited series of latitude,longitude pairs, with the last pair identical to the first. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="country" type="xs:string" minOccurs="0" maxOccurs="unbounded"> <xs:annotation> <xs:documentation> The two-character ISO 3166 alpha-2 Country Code for the country concerned. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="subdivision" type="xs:string" minOccurs="0" maxOccurs="unbounded"> <xs:annotation> <xs:documentation> The ISO 3166-2 designator for the administrative subdivision concerned. The first two characters, before the hyphen, is the ISO 3166 alpha-2 Country Code for the country within which the designated subdivision is located. The following one-to-three characters following the hyphen designate the particular subdivision. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="location" type="xs:string" minOccurs="0" maxOccurs="unbounded"> <xs:annotation> <xs:documentation> The UN/LOCODE designator for the location concerned. The two first digits are the ISO 3166 alpha-2 Country Code for the country in which the place is located. The following three characters are the UN/LOCODE designator for the particular location within that country. No spaces or punctuation are used within this designator. </xs:documentation> </xs:annotation> </xs:element> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="messageElement"> <xs:annotation> <xs:documentation> 1. The container element for message content. 2. This element MUST assert an explicit namespace for any included XML content in <keyXmlContent> and/or <contentObject>. If no namespace is asserted in the <messageElement> tag, the enclosed content MAY be assumed to be non-XML. </xs:documentation> <xs:documentation>MessagaeElement is a container for</xs:documentation> </xs:annotation> <xs:complexType> <xs:sequence> <xs:element name="keyXMLContent" minOccurs="0"> <xs:annotation> <xs:documentation> 1. A container element for collected fragments of a valid XML document contained within an <xmlContent> element within the current <messageElement> block. 2. All content within this element MUST be explicitly namepaced as defined in the enclosing <messageElement> tag. </xs:documentation> </xs:annotation> <xs:complexType> <xs:sequence> <xs:element ref="valueListUrn"> <xs:annotation> <xs:documentation> The content of "valueListUrn" is the Uniform Resource Name of a published list of values and definitions. </xs:documentation> </xs:annotation> </xs:element> <xs:element ref="value"> <xs:annotation> <xs:documentation> The content of "value" is a string (which may represent a number) denoting the value itself. </xs:documentation> </xs:annotation> </xs:element> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="messageSenderRole" minOccurs="0" maxOccurs="unbounded"> <xs:annotation> <xs:documentation> 1. Any value from a discrete managed list, used to inform message routing decisions by describing the functional role of the sender, in the form: <senderRole> <valueListUrn>valueListUrn</valueListURN> <value>value</value> </senderRole> </xs:documentation> </xs:annotation> <xs:complexType> <xs:sequence> <xs:element ref="valueListUrn"> <xs:annotation> <xs:documentation> The content of "valueListUrn" is the Uniform Resource Name of a published list of values and definitions. </xs:documentation> </xs:annotation> </xs:element> <xs:element ref="value"> <xs:annotation> <xs:documentation> The content of "value" is a string (which may represent a number) denoting the value itself. </xs:documentation> </xs:annotation> </xs:element> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="messageRecipentRole" minOccurs="0" maxOccurs="unbounded"> <xs:annotation> <xs:documentation> 1. Any value from a discrete managed list, used to inform message routing decisions by describing the functional role of the recipient, in the form: <recipientRole> <valueListUrn>valueListUrn</valueListURN> <value>value</value> </recipientRole> where the content of "valueListUrn" is the Uniform Resource Name of a published list of values and definitions, and the content of "value" is a string (which may represent a number) denoting the value itself (e.g., valueListUrn = "http://www.dhs.gov/NiemRoleType" and value = "ICS Operations Branch".) 2. Multiple instance of <value> MAY occur within a single <recipientRole> structure. 3. Multiple instances or <recipientRole> MAY occur within a single <messageElement> block. </xs:documentation> </xs:annotation> <xs:complexType> <xs:sequence> <xs:element ref="valueListUrn"> <xs:annotation> <xs:documentation> The content of "valueListUrn" is the Uniform Resource Name of a published list of values and definitions. </xs:documentation> </xs:annotation> </xs:element> <xs:element ref="value"> <xs:annotation> <xs:documentation> The content of "value" is a string (which may represent a number) denoting the value itself. </xs:documentation> </xs:annotation> </xs:element> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="responseType" minOccurs="0" maxOccurs="unbounded"> <xs:annotation> <xs:documentation>??</xs:documentation> </xs:annotation> <xs:complexType> <xs:sequence> <xs:element ref="valueListUrn"> <xs:annotation> <xs:documentation> The content of "valueListUrn" is the Uniform Resource Name of a published list of values and definitions. </xs:documentation> </xs:annotation> </xs:element> <xs:element ref="value"> <xs:annotation> <xs:documentation> The content of "value" is a string (which may represent a number) denoting the value itself. </xs:documentation> </xs:annotation> </xs:element> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="confidentiality" type="xs:string" minOccurs="0"> <xs:annotation> <xs:documentation> Special requirements regarding confidentiality of the content of this <messageElement>. </xs:documentation> </xs:annotation> </xs:element> <xs:choice> <xs:element ref="contentObject"> <xs:annotation> <xs:documentation> 1. Container element for the actual message content. That content MAY be either a separately-namespaced XML document or some item of non-XML content. 2. If the enclosed content is XML it MUST be explicitly namepaced as defined in the enclosing <messageElement> tag. Enclosed XML content may be encrypted and/or signed within this element. 3. This element MUST be present unless the Distribution Element is used in a query to, or a response from, a directory service. </xs:documentation> </xs:annotation> </xs:element> </xs:choice> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="contentObject"> <xs:annotation> <xs:documentation> 1. Container element for the actual message content. That content MAY be either a separately-namespaced XML document or some item of non-XML content. 2. If the enclosed content is XML it MUST be explicitly namepaced as defined in the enclosing <messageElement> tag. Enclosed XML content may be encrypted and/or signed within this element. 3. This element MUST be present unless the Distribution Element is used in a query to, or a response from, a directory service. </xs:documentation> </xs:annotation> <xs:complexType> <xs:sequence> <xs:element name="resourceDesc" type="xs:string" minOccurs="0"/> <xs:element name="mimeType" type="xs:string" minOccurs="0"> <xs:annotation> <xs:documentation> MIME content type and sub-type as described in [RFC 2046]. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="size" type="xs:integer" minOccurs="0"> <xs:annotation> <xs:documentation> Approximate size of the content item (in its un-encoded form) in bytes. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="uri" type="xs:anyURI" minOccurs="0"> <xs:annotation> <xs:documentation> Either a full absolute URI, typically a Uniform Resource Locator, that can be used to retrieve the resource over the Internet, or a relative URI naming the file represented in the <derefUri>. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="derefUri" type="xs:string" minOccurs="0"> <xs:annotation> <xs:documentation> The base-64 encoded data content. MAY be used either with or instead of the <uri> element in contexts where retrieval of a resource via a URI is not feasible. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="digest" type="xs:string" minOccurs="0"> <xs:annotation> <xs:documentation> The digital digest ("hash") of the content item calculated using the Secure Hash Algorithm (SHA-1) per [FIPS 180-2] </xs:documentation> </xs:annotation> </xs:element> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="value"/> <xs:element name="valueListUrn" type="xs:string"/> <xs:element name="valueName" type="xs:string"/> </xs:schema>

Appendix C. Acknowledgements

The following individuals have participated in the creation of this specification and are gratefully acknowledged:

Participants:

[list of acknowledgements as determined by Technical Committee chair(s)]

Appendix D. Revision History

[optional; should NOT be included in OASIS Standards]

Revision Date Editor Changes Made
       
       


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]