Re: [emergency-msg] CAP Channels

[Art Botterell <acb@incident.com>]

Rex -

>I get the feeling that I am supposed to be seeing formatted display 
>instead of code, but I don't know for sure, so I'm just asking.

You should be receiving an XML document with a <channel> root element 
and (most of the time) a few <item> elements... like this:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<channel xmlns="http://www.incident.com/channel";>
   <title>California EDIS Bulletins</title>
   <channelUrl>http://www.edis.ca.gov/cap_0.9/index.xml</channelUrl>
   <contact>acb@incident.com</contact>
   <channelUpdated>2003-00-11T12:50:45-07:00</channelUpdated>
   <item>
     <format>http://www.incident.com/cap/0.9a1</format>
     <identifier>106062122011743</identifier>
     <sender>EDIS@edis.oes.ca.gov</sender>
     <topic>EDIS DAILY SYSTEM TEST</topic>
     <sent>2003-08-11T10:00:00-07:00</sent>
     <posted>2003-08-11T10:00:00-07:00</posted>
     <expires>2003-008-11T16:00:20-07:00</expires>
     <itemUrl>http://www.edis.ca.gov/cap_0.9/1060621220.cap</itemUrl>
   </item>
   <item>
     <format>http://www.incident.com/cap/0.9a1</format>
     <identifier>106061785031416</identifier>
     <sender>xsjoes@edis.oes.ca.gov</sender>
     <topic>TEST</topic>
     <sent>2003-08-11T09:04:00-07:00</sent>
     <posted>2003-08-11T09:04:00-07:00</posted>
     <expires>2003-008-11T15:04:10-07:00</expires>
     <itemUrl>http://www.edis.ca.gov/cap_0.9/1060617850.cap</itemUrl>
   </item>
   <item>
     <format>http://www.incident.com/cap/0.9a1</format>
     <identifier>106063144418022</identifier>
     <sender>laoem@edis.oes.ca.gov</sender>
     <topic>LA COUNTY HEAT ADVISORY</topic>
     <sent>2003-08-11T12:50:00-07:00</sent>
     <posted>2003-08-11T12:50:00-07:00</posted>
     <expires>2003-008-11T18:50:44-07:00</expires>
     <itemUrl>http://www.edis.ca.gov/cap_0.9/1060631444.cap</itemUrl>
   </item>
</channel>

What appears on your screen depends on how your browser handles 
text/xml responses... some parse them and lay them out, while others 
suppress the tags and you need to View Source to see the whole thing. 
(That's what I have to do in Safari, for example.)  The .cap files 
return from that server as text/plain so they may be more 
browser-friendly.

Remember that the channel file isn't intended for a browser... it's 
meant for an XML-aware client in an automated process.  A human with 
a browser does just fine with a directory listing... although how 
many humans want to look at raw CAP XML anyway?

>As to the RSS-like indexing, I'm also at a loss as to why this is desireable.

Think about how you'd support an automated process that polled for 
new messages.  You could build all the current messages into one big 
file and make every client download every message every time, but 
that would be inflexible and relatively inefficient.

Alternatively you'd need to provide at least the filenames for 
available messages... and once you've done that it wouldn't be a lot 
more work to provide a few details that let the client decide which 
messages it wanted to download.   And then you could use the same 
format for aggregation, filtering and even discovery.

>However, I would think that a simple Web Services Registry lookup 
>either in UDDI or ebXML would do the job handily in finding a 
>service, and then registering it so that when one fires up a 
>connection to that service, one gets the info (portlets in portals 
>in the model I use most) in the format desired, be it html, xml, 
>voiceXML, etc.

I'd agree... except maybe with describing that approach as "simple." 
Certainly this whole arrangement could easily be described in WSDL 
and registered in UDDI and/or ebXML.  But even then, seems like many 
request-response (including archival) services might get performance 
gains from indexing.

>This doesn't require considering whether the messaging requested by 
>the receiver is either push or pull since receivers don't receive 
>anything until they ask for it. One can set up an automatic 
>connection where appropriate so that the needed info is always 
>there, and it can be set up to perform whatever kind of alert is 
>required.

Did I neglect to stress that this idea doesn't preclude more 
sophisticated implementations, if and when we have the 
infrastructure?  It's just that at least a couple of actual CAP 
content providers have already expressed a need for a truly simple 
way to expose their messages, particularly in the near term.

- Art