[CAP] cap implementations

Mick Jagger lists at jpw.biz
Wed Oct 5 05:41:33 PDT 2005


Hi,
	"Warning, long message" 
	I'm just finishing up a quick generator for an atom index for CAP alerts.  If I get some time this evening, I'll create an executable and make it available to the rest of the list.  It works by feeding in a list of current cap alerts, either via file or web input, and each active alert is an entry in the index.  
	Attached is a quick sample of output.  A few issues have popped up and I was wondering what the rest of the list's thoughts were on them.  
	First is the index feed's id.  The spec calls for this to be regenerated each time the index is.  However, this goes against the outline for an atom feed.  The feed id is supposed to be a unique id for that feed that doesn't change over time.  I was curiuos why the spec called for the opposite of the atom recommendations.  In my example I have used the CAP site's URL.
	For each entry ID I have used the taguri scheme instead.  For most CAP messages I'm expecting that people are using a unique id of sorts, "A123456789" or something, that gets
incremented for each new CAP message.  
	For the title for each entry, right now I'm using the headline entry as per the spec, however, I think this could be changed.  Headline is not a required item, and if there are multiple infos, how do you pick?  So maybe the title should be "$scope $msgType, $event".  With the CAP elements Scope, msgType and Event used instead.  Multiple info elements would instead add their Category names instead of Event.  This way a quick title summary is done, and I also like the idea of using Status and putting "Test" in the title when Test is used to allow people to disregard.
	Which leads into using a summary field too.  For each info element in the alert, the summary field would show the following CAP elements,  event, headline, web, and area description in blocks.  
	I've left off the location for now.  Multiple info elements make this even more difficult.  Maybe there is a shortform instead of lat/long that can be used by a CAP client to quickly filter by location?
	The main idea here is making this atom feed accessible to non-CAP fluent feedreaders, so it can be easily syndicated and CAP clients use it for finding the latest CAP updates, and for quick filtering.


<?xml version="1.0" encoding="UTF-8"?>
<feed xmlns="http://www.w3.org/2005/Atom" xmlns:cap="urn:oasis:names:tc:emergency:cap:1.1">
  <id>http://www.test.com/cap</id>
  <title>CAP Alert updates</title>
  <updated>2005-10-05T08:59:58-05:00</updated>
  <author>
    <name>Alert Authority</name>
  </author>
  <link href="http://www.test.com/cap/index.atom" rel="self" />
  <generator>JPW CAP AtomIndex Generator</generator>
  <entry>
    <id>tag:test.com,2005-10-05:/CAP/11285100680975</id>
    <author>
      <name>NWS_EKA at edis.oes.ca.gov</name>
    </author>
    <link href="http://www.edis.ca.gov/cap_1.0/1128510068.cap" rel="alternate" />
    <title>FROST ADVISORY FOR INTERIOR MENDOCINOTRINITY RIVER AND THE</title>
    <updated>2005-10-05T04:01:00-07:00</updated>
    <cap:status>Actual</cap:status>
    <cap:msgType>Alert</cap:msgType>
    <cap:category>Met</cap:category>
    <cap:urgency>Expected</cap:urgency>
    <cap:severity>Minor</cap:severity>
    <cap:certainty>Likely</cap:certainty>
  </entry>
</feed>

-- 
jake at jpw.biz
--


More information about the CAP-list mailing list