OASIS Emergency Management TC

  • 1.  Packaged CAP

    Posted 10-06-2015 15:19
    Friends,   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 cannot be expressed as a news feed and time will be wasted and lives can be lost while critical information is being unpacked.  However, if you look at the contents of the DE shown, valid CAP is there packaged nicely in the DE 1.0.  What are your thoughts?   Best regards, Elysa Jones, Chair OASIS EM-TC


  • 2.  RE: [emergency] Packaged CAP

    Posted 10-06-2015 16:52
    Semantics…   So to be accurate, NO, this is not CAP.   The CAP message contained within could be extracted and then it could be considered a CAP message but that takes a layer of understanding that doesn’t exist in any system that is expecting pure CAP.  So from a CAP perspective, it’s a no.   From a system that understands the DE wrapper, it is still a no until the wrapper is removed.   Norm   From: emergency@lists.oasis-open.org [mailto:emergency@lists.oasis-open.org] On Behalf Of Elysa Jones Sent: October 6, 2015 11:16 AM To: emergency@lists.oasis-open.org Subject: [emergency] Packaged CAP   Friends,   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 cannot be expressed as a news feed and time will be wasted and lives can be lost while critical information is being unpacked.  However, if you look at the contents of the DE shown, valid CAP is there packaged nicely in the DE 1.0.  What are your thoughts?   Best regards, Elysa Jones, Chair OASIS EM-TC


  • 3.  Re: [emergency] Packaged CAP

    Posted 10-06-2015 18:19
    I agree, while the content may contain valid CAP, its in a DE which could contain anything.   Rob 805-551-6232 From: Paulsen,Norm [Ontario] <Norm.Paulsen@ec.gc.ca> To: Elysa Jones <elysajones@yahoo.com>; emergency@lists.oasis-open.org Sent: Tuesday, October 6, 2015 9:51 AM Subject: RE: [emergency] Packaged CAP Semantics…   So to be accurate, NO, this is not CAP.   The CAP message contained within could be extracted and then it could be considered a CAP message but that takes a layer of understanding that doesn’t exist in any system that is expecting pure CAP.  So from a CAP perspective, it’s a no.   From a system that understands the DE wrapper, it is still a no until the wrapper is removed.   Norm   From: emergency@lists.oasis-open.org [mailto:emergency@lists.oasis-open.org] On Behalf Of Elysa Jones Sent: October 6, 2015 11:16 AM To: emergency@lists.oasis-open.org Subject: [emergency] Packaged CAP   Friends,   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 cannot be expressed as a news feed and time will be wasted and lives can be lost while critical information is being unpacked.  However, if you look at the contents of the DE shown, valid CAP is there packaged nicely in the DE 1.0.  What are your thoughts?   Best regards, Elysa Jones, Chair OASIS EM-TC


  • 4.  Re: [emergency] Packaged CAP

    Posted 10-13-2015 18:16
    > 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>