| | 36 | == Feedback == |
| | 37 | |
| | 38 | This is the received feedback: |
| | 39 | |
| | 40 | Nuwan: |
| | 41 | |
| | 42 | Hi Shashi et al, |
| | 43 | |
| | 44 | 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. |
| | 45 | |
| | 46 | First, some comments on the Create CAP Alert form |
| | 47 | 1) <Alert> segment = Create CAP Alert |
| | 48 | 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 |
| | 49 | 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). |
| | 50 | c) <scope> - need to build in the logic for each of the values: Public, Private, Restricted. |
| | 51 | If "Public", then control(<Restriction> && <Recipients>) = disabled |
| | 52 | If "Restricted", then control(<Restriction>)=enabled && control( <Recipients>)=disabled |
| | 53 | If "Private", then control(<Restriction>)=disabled && control( <Recipients>)=enabled |
| | 54 | d) <Reference> - if <reference> is empty, then <reference> = <identifier>; else leave whatever it already is. |
| | 55 | 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. |
| | 56 | |
| | 57 | |
| | 58 | Work flow you need is discussed in this ticket: http://eden.sahanafoundation.org/ticket/1026#no1 . Read the Attachments section and the Change History. For the create CAP Alert; specifically refer to the paragraphs beginning with Scrn03_CAP_Msg.png. Disregard the images added by Nostraa , you may get confused. |
| | 59 | |
| | 60 | Some notes on Scrn03_CAP_Msg.png |
| | 61 | |
| | 62 | Scrn03_CAP_Msg.png: the image shows the <info> segment given at the bottom. One option would be to create tabs in the Create CAP Alert form. Put the <Alert> segment attributes in the first tab and the <Info> segment attributes in the second tab. Since there is a 1-to-many relationship between the <Alert> segment and the <Info> segments, in the image: Scrn03_CAP_Msg.png, the related <info> records are displayed in a table. The table shows only a selected set of elements to guide the user to enter in to that particular <info> block. The instances that create multiple <info> segments are Language and Updates. |
| | 63 | |
| | 64 | Example: The Met depart may detect a cyclone developing in the Bay of Bengal. The Tamil Nadu DMC would issue an alert in English, French, Hindi, and Tamil, that's 4 <info> segments. Then every six hours they would issue an update of the same alert but with the new position, wind-speed, trajectory, etc. These updates would need to be issued in the 4 languages. Assuming there are 5 updates before it hits land, then that particular message would have 20 <info> segments. |
| | 65 | |
| | 66 | We'll discuss the subsequent developments such as the <info> segment logic and layout when you get to that point; i.e. Scrn031_CAP_msg_Info.png, etc. |
| | 67 | |
| | 68 | |
