MHonArc v2.5.0b2 -->
emergency-msg message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [emergency-msg] CAP Channels
At 12:26 PM -0400 8/15/03, Eliot Christian wrote:
>In my model, the RSS file of available CAP alerts is just a "table
>of contents". All actual CAP alert content would not be in RSS
>format; it would be in CAP format.
Absolutely. For another example, the index file I'm experimenting
with for the California EDIS channel
(<http://www.edis.ca.gov/cap_1.0/>) has this structure:
/channel (container for this index document)
/channel/title (a name for the channel)
/channel/channelUrl (the location of this channel index)
/channel/contact (an email or other contact info for the channel admin)
/channel/channelUpdated (date/time this index was last updated)
/channel/item ([multiple] pointer to individual messages)
/channel/item/format (namespace for this message type)
/channel/item/identifier (message id)
/channel/item/sender (message sender id)
/channel/item/topic (a descriptive name - e.g., from cap:headline)
/channel/item/sent (date/time the message was originally sent)
/channel/item/posted (date/time the message became available on
this channel)
/channel/item/expires (date/time the message expires)
/channel/item/itemUrl (URL for the message itself
This is very similar to an RSS document... the chief technical
difference being the increased detail in the <item> structure.
>One way to make an RSS channel would be to compile RSS items by
>extracting CAP message at the "alert/info" level.
Hmmm... I guess that's true, but it breaks the one-message-one-URL
principle that I'd adopted, mainly for simplicity. Also, language
isn't the only principle for having multiple <info>s... there's also
the concentric watch/warning area scenario, for example. And in that
latter case, seems like breaking the association between those two
elements might actually be counter-productive, since the "rule of
primacy" within a message allows receivers in an overlap zone to
decide which section applies to them.
> I think it would fit what RSS news readers are expecting.
This is the bit that troubles me about using RSS per-se (at least in
the generalized channel transport model)... the implication that the
channel is going to be directly readable by RSS news readers. Most
of those are oriented toward locating and then displaying HTML
content.
Which, again, isn't to say that an RSS feed pointing toward
HTML-transformed versions of CAP messages might not be quite useful
as a public delivery mechanism. But in that case the HTML
transformation would be a critical bit.
- Art
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]