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] Implementation Guide Outline

Title: Implementation Guide Outline

For the implementation guide does the group see a need for section that would provide guidance and examples on integrating other groups standards, application or content within a CAP message. This would be the equivalent to a CAP binding and profile. For example the OASIS standard on Application Vulnerability provides the ability to create a uniform way of describing application security vulnerabilities. How could such a message be incorporated within a CAP message. I am sure that there are others as well derived from our Category element. This would ensure that CAP is used correctly and provide further examples on its usage.

Does the group also see a need to perhaps provide alternative representations of the CAP standard. We currently use XSD Schema but other standards are also in use such as RELAX NG an OASIS standard. RELAX NG and others (RELAX NG Compact, Schematron for example) are gaining in popularity and may meet the needs of certain implementers. Please find enclosed a RELAX NG first version of the CAP standard.


----- Original Message -----
From: Rex Brooks
Sent: Monday, April 05, 2004 4:00 PM
Subject: [emergency] Implementation Guide Outline

Hi Folks,

This is a first draft, strawman for the implementation or implementer's guide. So please view it as a point of departure. I left out tentative contacts from the justice/law enforcement community that I have already tried to arrange, and our recent discussions on XML examples on the list.

Common Alerting Protocol Implementation Guide Outline

(Note: the first question we need to ask is "What does this audience of implementers need to know?" It is suggested that getting answers from this community is the best way to determine this, so it is also suggested that a method for that be adopted.)

  1.1 Purpose of CAP--Single Consistent Message Across All Primary Audience Boundaries
            1.1.1 Provide Common Message Format and Terminology
             1.1.2 Transport Independence
           Data Dictionary
       XML Schema for API s and Web Serivces
          One-way Broadcast Capability
2. Basic Concepts
   2.1 Notification Messages Protocol
              2.1.1 Not Signal Protocol
               2.1.2 Code of Conduct, Rules of Conduct, Conventions
    2.2 Implementer Audience
                2.2.1. Emergency Management
             2.2.2. First Responders
        2.2.3. Public Immediately At Risk
               2.2.4. Updates and Secondary Audiences
         Update Consistency for Changes to Area, Severity, Urgency, Recommendations
            Update Consistency for Additional Related Incidents
                            (Subsequent Incidents impacting Traffic, Responders, Recommendations)
3. Broadcast Considerations (Need Implementer[s] Feedback from Broadcast/Cable/Satellite Community)
        3.1. Video
              3.1.1. Broadcast
                3.1.2. Cable/Satellite
  3.2. Radio
              3.2.1. Broadcast
                3.2.1. Satellite
4. Internet Considerations (Need Implementer[s] Feedback from Public Health, Public Safety Community)
   4.1. Data Dictionary
            4.1.1. What Motivates the Developer's Use of the DD? (What App Types?)
        , Alert, .2.  Info, .3. Area, .4. Description, etc. ...
          4.1.2. How Does Developer Use DD as Normative Source?
         , Alert, .2.  Info, .3. Area, .4. Description, etc. ...
  4.2. XML Schema
        4.1.1. What Motivates the Developer's Use of the XSD? (What App Types?)
      , Alert, .2.  Info, .3. Area, .4. Description, etc. ...
          4.1.2. How Does Developer Use XSD as Normative Source? (What App Types?)
              , Alert, .2.  Info, .3. Area, .4. Description, etc. ...
5. GML Implementor's Note (Literal Drop In) CAP Alert Messages as GML FeatrueCollection
6. Examples(?)


Rex Brooks
GeoAddress: 1361-A Addison, Berkeley, CA, 94702 USA, Earth
W3Address: http://www.starbourne.com
Email: rexb@starbourne.com
Tel: 510-849-2309
Fax: By Request


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