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

Timestamp:

06/26/12 18:47:06 (13 years ago)

Author:

g0wda

Comment:

--

Event/2012/GSoC/CAPBroker

@@ -47 +47 @@
 Hi Shashi et al,
 
-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.
+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.
 
 First, some comments on the Create CAP Alert form
 1) <Alert> segment = Create CAP Alert
-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
-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).
-c) <scope> - need to build in the logic for each of the values: Public, Private, Restricted. 
+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~~ -- Seems very apt! CAP Templates and Profiles retain CAP though.
+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).~~
+    -- Here prefix is configurable, defaults to domainname, sequence is the potential alert id, postfix is configurable defaults to "".
+c) ~~<scope> - need to build in the logic for each of the values: Public, Private, Restricted. 
      If "Public", then control(<Restriction> && <Recipients>) = disabled
      If "Restricted", then control(<Restriction>)=enabled && control( <Recipients>)=disabled
-     If "Private", then control(<Restriction>)=disabled && control( <Recipients>)=enabled
+     If "Private", then control(<Restriction>)=disabled && control( <Recipients>)=enabled~~
+     -- Done but these things are optional and not disabled as per CAP, correct?
 d) <Reference> - if <reference> is empty, then <reference> = <identifier>; else leave whatever it already is.
+    -- which identifier? :/ isn't reference supposed to refer to other alerts which are these if the field is empty? (shashi)
 e) <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.