[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
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:
This specification is related to:
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.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
2 Design Principles and Concepts (non-normative)
3 Distribution Element Structure (normative)
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
[All text is normative unless otherwise labeled.]
[The purpose of the EDXL DE goes here.]
[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.
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.
[basic targetArea description goes here]
[basic messageElement description goes here]
[basic contentObject description goes here]
1.4 Applications of the EDXL Distribution Element
[The applications of the EDXL DE goes here.]
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].
N. Freed, Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types, http://www.ietf.org/rfc/rfc2046.txt, IETF RFC 2046, November 1996.
S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, http://www.ietf.org/rfc/rfc2119.txt, IETF RFC 2119, March 1997.
[Full reference citation]
[Full reference citation]
2. Design Principles and Concepts (non-normative)
[design explanation goes here.]
3. Distribution Element Structure (normative)
[body of standard goes here]
|
* |
|
||||||||||||||||||||
| | | * |
||||||||||||||||||||||
|
1 |
|
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 |
|
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:
|
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:
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
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 |
|
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 |
|
Used In | targetArea |
Element | location |
---|---|
Type | xsd:string |
Definition |
The UN/LOCODE designator for the location concerned. (MAY have multiple) |
Notes |
|
Used In | targetArea |
3.2.3 messageElement Element and Sub-elements
Element | messageElement |
---|---|
Definition |
The container element for message content. (MAY have multiple) |
Notes |
|
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 |
|
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 |
|
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 |
Element | contentObject |
---|---|
Definition |
Container element for the actual message content. (MUST have only one) |
Notes |
|
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 |
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>
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)]
[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]