Re: [emergency] Packaged CAP

[Jacob Westfall <jake@jpw.biz>]

> After CAP workshop in Rome, the following link was sent to me:
> http://www.rfs.nsw.gov.au/feeds/majorIncidentsCAP.xml with the question - is
> this a CAP message?  Our friend Eliot Christian adamantly says NO - it

I've looked at a couple days worth of data from this so called feed and found significant concerns.  When it comes to the question of being valid CAP, you'd need to look at schematic validity versus functional validity.  By and large this "feed" contains schematically valid DE and CAP elements.  However there are significant functional problems with both the DE and CAP elements and how they are implemented such that its functionally invalid. Both the DE and CAP specs have non-normative sections detailing design principles, which this feed does not follow.  Even viewed as an Atom/RSS inspired feed, it contravenes their design principles as well.  I would argue this "feed" is an example of "poor" (vs best) practices for the DE and CAP.

At the risk of a semantic argument, I wouldn't say this system offers a "feed" of CAP "messages".  It really is a just a capture of the "state" of its system at a particular date/time.  Its more like a KML file or an HTML page, capturing some content and geographical information.  For those of you who've been around for a while, when CAP was in development, there were some very early implementations where multiple <info> blocks were used for different incidents, resulting in a single CAP "message" with regularily changing content.  This system is very much like that.  Here are some of the problems I noted, there are likely more...

- The EDXL DE elements don't describe a message.  The distributionID and dateTimeSent values change with every load of the file.  So there is no way to access the same message by two different users.  I can't say to you, look at message XYZ for the update to the alert, because there is no way for you to ever see that message.  It really defeats the entire purpose of the DE as a way to interop with another system.

- There is never any Update to a DE message.  Many elements are static with only the time value changing.  So you lose the ability to determine when something is new versus changed versus old.

- The CAP elements don't describe a message either.  You can't link to, or even reliable point to a location in the DE, a particular CAP message and say "this alert" when you want to interop with another system.

- There is never an Update to a CAP message.  The identifier/sent times will randomly change.  Other major elements of the CAP message will also randomly change, like the eventCode, or the area.  There is no message consistency or immutablity.

- The CAP-AU profile isn't being followed, nor is the CAP implementation note about character entities.

-- 
Jacob Westfall <jake@jpw.biz>