Changes between Version 12 and Version 13 of Event/2012/GSoC/CAPBroker


Ignore:
Timestamp:
06/26/12 18:47:06 (9 years ago)
Author:
g0wda
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Event/2012/GSoC/CAPBroker

    v12 v13  
    4747Hi Shashi et al,
    4848
    49 Final Deliverable should be a set of forms with appropriate work flows to create a CAP message and then produce an XML file. Thereafter, we would validate that XML file with Googl.org's CAP validator. Trying to build one that can handle multiple languages may be too ambitious, therefore, we'll restrict it to English for now. However, we should still assume we'll need multiple <info> segments that can be populated in English. If we are to deliver a CAP-enabled alerting module that can be utilized, then we would need the Profile and Template components to work.
     49Final Deliverable should be '''a set of forms with appropriate work flows to create a CAP message and then produce an XML file'''. Thereafter, we would validate that XML file with Googl.org's CAP validator. Trying to build one that can handle multiple languages may be too ambitious, therefore, we'll restrict it to English for now. However, we should still assume we'll need multiple <info> segments that can be populated in English. If we are to deliver a CAP-enabled alerting module that can be utilized, then we would need the Profile and Template components to work.
    5050
    5151First, some comments on the Create CAP Alert form
    52521) <Alert> segment = Create CAP Alert
    53 a) Given that CAP already contains the word Alert in it we can possibly simply call it "Create Alert" or "Create Message", where CAP is simply the underlying data structure
    54 b) <identifier> - typical format is prefix + dateTime + timezone + sequence + postfix; e.g. scdmc-20120626T19:30:00+8:00-005-2.49.0.1.144.2. The prefix = "scdmc-", postfix="-2.49.0.1.144.2", and sequence="005" (we may issue more than one alert in one day).
    55 c) <scope> - need to build in the logic for each of the values: Public, Private, Restricted.
     53a) ~~Given that CAP already contains the word Alert in it we can possibly simply call it "Create Alert" or "Create Message", where CAP is simply the underlying data structure~~ -- Seems very apt! CAP Templates and Profiles retain CAP though.
     54b) ~~<identifier> - typical format is prefix + dateTime + timezone + sequence + postfix; e.g. scdmc-20120626T19:30:00+8:00-005-2.49.0.1.144.2. The prefix = "scdmc-", postfix="-2.49.0.1.144.2", and sequence="005" (we may issue more than one alert in one day).~~
     55    -- Here prefix is configurable, defaults to domainname, sequence is the potential alert id, postfix is configurable defaults to "".
     56c) ~~<scope> - need to build in the logic for each of the values: Public, Private, Restricted.
    5657     If "Public", then control(<Restriction> && <Recipients>) = disabled
    5758     If "Restricted", then control(<Restriction>)=enabled && control( <Recipients>)=disabled
    58      If "Private", then control(<Restriction>)=disabled && control( <Recipients>)=enabled
     59     If "Private", then control(<Restriction>)=disabled && control( <Recipients>)=enabled~~
     60     -- Done but these things are optional and not disabled as per CAP, correct?
    5961d) <Reference> - if <reference> is empty, then <reference> = <identifier>; else leave whatever it already is.
     62    -- which identifier? :/ isn't reference supposed to refer to other alerts which are these if the field is empty? (shashi)
    6063e) <incidents> should be related to the same incidents list in the IRS module. Example: a mass movement that causes an accident, then incidents would be ="rock slide", "train derailment". I believe "rock slide" and "train derailment" may be archetypes of "mass movement" and "accident", respectively.
    6164