OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

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 

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]