How To Format Your CAP Alert For Digital Signage

Organizations can create their own CAP alerts to deliver urgent, location-specific information directly to their digital signage screens in real time. By publishing standardized alerts through your CMS, you ensure messages are consistent, highly visible, and instantly distributed across all relevant displays. This gives teams a fast, reliable way to communicate time-sensitive updates that improve awareness, safety, and response across your facility.

The CAP alert Content App will accept any CAP URL that conforms to the following structures in CAP Version 1.2.

What You'll Need

• An Active Select Suite Subscription
• Internet Connectivity For Your Device

Single Alerts (1 File)

• The individual alert must be available at a public URL and can be used directly in the Mvix CMS when adding the CAP alert URL.
  
  • The alert must contain the XML structure as defined below, with the following required fields:
    
    • <category>
      
      • Required by the protocol but will not be displayed in the actual alert. The placeholder “Met” will suffice.
    • <msgType>
      
      • Also required by the protocol but not displayed in the actual alert. The placeholder “Original” or “Alert” will suffice.
    • <effective>
      
      • Contains a timestamp that specifies when the alert is considered valid. Alerts with a timestamp set in the future will not be displayed until that time passes.
      • Timestamp must be formatted as “YYYY-MM-DDThh:mm:ssXzh:zm”
        
        • YYYY-MM-DD is the standard year-month-day indicates the year
        • MM indicates the month
        • DD indicates the day
        • T indicates the symbol “T” marking the start of the required time section
        • hh indicates the hour
        • mm indicates the minute
        • ss indicates the second
        • X indicates either the symbol “+” if the preceding date and time are in a time zone ahead of UTC, or the symbol “-‘ if the preceding date and time are in a time zone behind UTC.  If the time is in UTC, the symbol “-“ will be used.
        • zh indicates the hours of offset from the preceding date and time to UTC, or “00” if the preceding time is in UTC
        • zm indicates the minutes of offset from the preceding date and time to UTC, or “00” if the preceding time is in UTC
        • For example, a value of “2002-05-30T09:30:10-05:00” would indicate May 30, 2002 at 9:30:10 AM
    • <headline>
      
      • Main alert Title that will be seen when displayed
      • 160 characters max
    • <description>
      
      • Longer alert description to be shown below the headline

Here is an example XML structure:

<?xml version = '1.0' encoding = 'UTF-8' standalone = 'yes'?>
<alert xmlns="urn:oasis:names:tc:emergency:cap:1.1">
    <identifier>1234567899001</identifier>
    <info>
   	 <category>Met</category>
   	 <msgType>Original</msgType>
   	 <effective>2018-01-01T00:00:00-23:59</effective>
   	 <expires>2099-01-18T00:00:00-23:59</expires>
   	 <headline>Sample Alert Title!</headline>
   	 <description>Description goes here and can be as long as needed.</description>
    </info>
</alert>

Multiple Alerts (2+ Files)

• Widget URL used in cms.mvix.com must point to a primary CAP Index file, which contains links to all available alerts
  
  • Please note the URL inside the <link> element is embedded in the “href” attribute (inside quotes), whereas the <id> element just contains the URL directly inside (see structure below)
  • This is a standard Index file, formatted in XML, that contains <entry> </entry> elements for each separate CAP alert to be displayed.
    • Each <entry> element must contain 2 child elements <id> and <link> that both reference the same separate alert URL:
• Each Individual alert(s) available at its respective public URL
  
  • This public URL must match the URL referenced from the original Index file
    • Each alert must contain the XML structure as defined below, with the following required fields:
      
      • <category>
        
        • Required by the protocol but will not be displayed in the actual alert. The placeholder “Met” will suffice.
      • <msgType>
        
        • Also required by the protocol but not displayed in the actual alert. The placeholder “Original” or “Alert” will suffice.
      • <effective>
        
        • Contains a timestamp that specifies when the alert is considered valid. Alerts with a timestamp set in the future will not be displayed until that time passes.
        • Timestamp must be formatted as “YYYY-MM-DDThh:mm:ssXzh:zm”
          
          • YYYY-MM-DD is the standard year-month-day indicates the year
          • MM indicates the month
          • DD indicates the day
          • T indicates the symbol “T” marking the start of the required time section
          • hh indicates the hour
          • mm indicates the minute
          • ss indicates the second
          • X indicates either the symbol “+” if the preceding date and time are in a time zone ahead of UTC, or the symbol “-‘ if the preceding date and time are in a time zone behind UTC.  If the time is in UTC, the symbol “-“ will be used.
          • zh indicates the hours of offset from the preceding date and time to UTC, or “00” if the preceding time is in UTC
          • zm indicates the minutes of offset from the preceding date and time to UTC, or “00” if the preceding time is in UTC
          • For example, a value of “2002-05-30T09:30:10-05:00” would indicate May 30, 2002 at 9:30:10 AM
      • <headline>
        
        • Main alert Title that will be seen when displayed
        • 160 characters max
      • <description>
        
        • Longer alert description to be shown below the headline
• Both XML files must have the “Content-Type” header set to “application/rss+xml”
  
  • This is important in ensuring the file is interpreted correctly by the software. Please note the “rss+xml” portion as the end, as there are many similar older variants of this out there, and not all will be recognized the same.

Here is an example XML structure:

Index File (With two separate alerts)

<?xml version = '1.0' encoding = 'UTF-8' standalone = 'yes'?>
<feed>
    <entry>
   	 <id>FIRST_INDIVIDUAL_ALERT_URL</id>
   	 <link href="FIRST_INDIVIDUAL_ALERT_URL"/>
    </entry>
    <entry>
   	 <id>SECOND_INDIVIDUAL_ALERT_URL</id>
   	 <link href="SECOND_INDIVIDUAL_ALERT_URL"/>
    </entry>
</feed>

Individual Alert File

Please Note: The URL forthis alert would be reference above in the FIRST_INDIVIDUAL_ ALERT_ URL portion.

<?xml version = '1.0' encoding = 'UTF-8' standalone = 'yes'?>
<alert xmlns="urn:oasis:names:tc:emergency:cap:1.1">
    <identifier>1234567899001</identifier>
    <info>
   	 <category>Met</category>
   	 <msgType>Original</msgType>
   	 <effective>2018-01-01T00:00:00-23:59</effective>
   	 <expires>2099-01-18T00:00:00-23:59</expires>
   	 <headline>Sample Alert Title!</headline>
   	 <description>Description goes here and can be as long as needed.</description>
    </info>
</alert>

Next Steps

Once your CAP Alerts are set up, you'll be able to add them to the Mvix CMS.

Please follow our CAP Alert article for more information.

Need Additional Help? If you have any further questions, problems, or corrections you would like to see made, please open a support ticket.