CAP Channels

[Art Botterell <acb@incident.com>]

Friends -

Until now most of our work has focused on the CAP alert message 
format itself.  But building a demonstration CAP 0.9 source has led 
me to experiment with an idea developed by Robert Bunge and Eliot 
Christian about one way to move CAP messages around.

Many CAP transmissions will occur in "push" mode, of course... 
possibly using SOAP messaging over the Internet, or perhaps some sort 
of data broadcast.  But sometimes a provider of CAP traffic may want 
simply to post all its current messages on a web server... to enable 
catch-up by a client that's just been turned on, for example... or to 
support polling clients behind firewalls and/or with dynamic network 
addresses (both of which make push more difficult)... or just to 
avoid the costs of creating and maintaining  explicit subscription 
records for a push service.

In such arrangements a list of current messages must be visible to 
the clients.  In early prototypes we posted a simple text list of 
filenames... basically just a directory listing.  Later experimenters 
used an RSS file as an index to the current messages... but RSS was 
designed with HTML content in mind and doesn't strike me as an 
entirely comfortable fit here (although my mind remains open about 
that).

So what I'm testing now (see 
<http://www.edis.ca.gov/cap_0.9/index.xml>) is an RSS-like index file 
customized for indexing operational XML messages.  A client can 
retrieve this "channel" index and determine which messages, if any, 
are a) new to that client, and b) not yet expired.  Then it can 
retrieve those messages for further evaluation and use.

A few random notes about this arrangement:

* An unlimited number of sources and devices could expose some or all 
of their current state in the form of channels, either to the general 
public or (perhaps using HTTPS with authentication) to a restricted 
community of viewers.

* For security and to reduce local network traffic some sources might 
choose to publish their channels via off-site servers (as California 
does for EDIS.)

* The channel index can reference messages from other servers and 
sources, so a specialized channel could link to selected messages 
from one or several sources... e.g., as a channel of messages 
targeted to a particular region, or of a particular type.  (RSS is 
used that way frequently to aggregate Web content according to some 
particular editorial principal.)

* The <item> element includes the source and identifier of the 
message, which together  form a unique ID for that message (at least 
in the case of CAP)... so a client looking at multiple channels could 
resolve any duplications it encountered.

* The <item> includes a <format> element populated with the default 
namespace for the target document... so a channel could expose 
multiple types of XML messages, not just CAP alerts.  (Of course, a 
specialized channel client could filter out all but a particular 
format.)

* An <item> can refer to another <channel>, so a "channel of 
channels" might provide a basic means of discovering data sources. 
(Of course, "recursive" channel clients would want to implement loop 
detection, just in case.)

Again, I want to stress that the channel concept doesn't preclude any 
other dissemination options or architectures... but for simple 
implementations it may be a convenient and flexible approach.

Your thoughts?

- Art