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
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]