At PubSub.com, we’ve started generating “CAP over Atom” files. By this I mean we’re publishing using Atom files to encapsulate a stream of message which are encoded using the CAP (Common Alerting Protocol) format. See: http://www.oasis-open.org/committees/download.php/6334/oasis-200402-cap-core-1.0.pdf .

Because CAP is an XML format, we’re using atom:content elements with type=”text/xml”. In order to ensure that there is something for aggregators to display if they don’t understand CAP, we’re generating atom:summary elements that contain a textual summary of the CAP message which is in the atom:content. My hope is that aggregator developers will commonly implement a pattern of displaying the atom:summary rather then the atom:content in cases where they don’t understand the XML type of the content element.

I would appreciate any review comments that you might be able to make on our use of Atom in this application.

For a sample Atom feed containing CAP messages which describe recent earthquakes, please see:

http://atom.pubsub.com/c0/b8/bd62e8e48058c0425193b37ea6.xml

            A sample atom:entry extracted from this Atom Feed is below:

 

<entry>

<ps:nodeID>/pubsub/topics/301</ps:nodeID>

<title><![CDATA[ Earthquake: M 1.6 (D) NORTHERN CALIFORNIA 2005-02-04T02:00:43.100Z ]]></title>

<issued>2005-02-03T21:04:42-05:00</issued>

<modified>2005-02-03T21:04:42-05:00</modified>

<id>tag:pubsub.com,2005:CAP:nc51156375</id>

<link rel='alternate' type='text/html' href=''/>

<summary>An earthquake occurred at 2005-02-04T02:00:43.100Z. The magnitude 1.6 event has been located in NORTHERN CALIFORNIA. (This is a computer-generated message and should not be considered authoritative.) </summary>

<content type='text/xml'>

<alert xmlns="http://www.incident.com/cap/1.0">

      <identifier>nc51156375</identifier>

      <sender>[EMAIL PROTECTED]</sender>

      <sent>2005-02-03T21:04:42-05:00</sent>

      <status>Test</status>

      <msgType>Alert</msgType>

      <scope>Public</scope>

      <incidents>nc51156375</incidents>

      <info>

        <category>Geo</category>

        <event>Earthquake</event>

        <urgency>Unknown</urgency>

        <severity>Unknown</severity>

        <certainty>Unknown</certainty>

        <senderName>Pubsub Earthquake Service</senderName>

        <headline>Earthquake: M 1.6 (D) NORTHERN CALIFORNIA 2005-02-04T02:00:43.100Z</headline>

        <description>An earthquake occurred at 2005-02-04T02:00:43.100Z. The magnitude 1.6 event has been located in NORTHERN CALIFORNIA. (This is a computer-generated message and should not be considered authoritative.) </description>

        <web>http://earthquake.usgs.gov/recenteqsUS/Quakes/nc51156375.htm</web>

        <parameter>EventID=nc51156375</parameter>

        <parameter>Version=1</parameter>

        <parameter>Magnitude=1.6 MD</parameter>

        <parameter>Depth=2 km</parameter>

        <parameter>Verified=N</parameter>

        <area>

          <areaDesc>2 km depth at latitude 38.8168, longitude -122.7915 at location: NORTHERN CALIFORNIA</areaDesc>

          <circle>38.8168,-122.7915 0</circle>

        </area>

      </info>

    </alert>

</content>

</entry>

 

Note: I am aware of a few issues with our current use of Atom:

1.       We often issue files that contain more than one entry with the same atom:id. For instance, you might have a message which is followed in the file by an update concerning the same “incident” or a “Cancel” message for the event. I know this is a violation of the specification. We will eventually stop doing this… Please bear with us.

2.       We currently don’t provide an atom:link element with rel=”alternate” when we insert a CAP “Cancel” message into the feed. This is, of course, because we have no page to point to for a deleted or cancelled event. In the future, we’ll consider having all such Cancel messages point to a common static help page which explains a variety of reasons why a message may have been deleted.

3.       If you view the Atom feed in a web browser, the result may not be terribly pleasing… We’re still working on the style sheet. – Please pay attention only to the source of the feed… (i.e. do “View Source”).

 

This service compliments the Earthquake service that I recently mentioned on this list. We will be publishing both raw Earthquake messages/feeds as well as CAP messages/feed in the future. These two formats are targeted at different audiences.

 

Your comments and/or suggestions would be appreciated.

 

                        bob wyman

 

Reply via email to