[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]