Re: [emergency-cap] Resend, Reply Requested: Official Title for CAP Even

Rex

Iâm back from my trip away and I have commentsâ

The abstract is quite good. Well written and describes the issue correctly in my mind.

I would however not want to tie this event terms list to CAP 1.2. In my mind it should beâ

Title:

ÂÂÂ Common Alerting Protocol Event Terms List Version 1.0

Abbreviation:

ÂÂÂ cap-etl-v1.0-cn.docx

The list should survive a 1.3 or 2.0 CAP effort and be versioned independently like you have with the 1.0 reference.

Norm

From: emergency-cap@lists.oasis-open.org <emergency-cap@lists.oasis-open.org> On Behalf Of rexbroo
Sent: May 31, 2019 11:49 AM
To: emergency-cap@lists.oasis-open.org
Subject: [emergency-cap] Resend, Reply Requested: Official Title for CAP Event Terms List

Hi Everyone,

This is a resend of the email posted to this SC on 5-21-2019. Please review and reply with changes/edits by end of day Monday, 3 June 2019. I need to include the title and abstract for the TCAdmin Request for a Committee Note Template. I didn't receive any comments from the first posting, but I want to be sure we have agreement on this to have the template ready by the June 14, 2019 meeting.

Thanks,
Rex

I didn't go through the entire history of meeting notes for the EM-CAP SC to find the official title of the Event TermsÂ List and other incidental information needed to request a template, so I'm asking if we can agree on:

Title:

ÂÂÂ Common Alerting Protocol Version 1.2 Event Terms List Version 1.0

Abbreviation:

ÂÂÂ cap-v1.2-etl-v1.0-cn.docx

Abstract:

The variety of practices employed regarding âeventâ types in CAP messages makes it difficult to compare messages from different sources. The problem has been presented as an interoperability issue where some consumers of CAP struggle to compare differences in language and meaning of the terms used in the <event> element in CAP.

The <event> element is the focus for this effort as it is the only required element in CAP directly associated with the subject event for a CAP message. Aligning practices surrounding this element, as opposed to other possible candidate elements, is the choice adopted in this work product for addressing this interoperability concern.

However, the <event> element is a free form text element meant to communicate with the final audience and not necessarily for the automated systems that process CAP. The only constraint on <event> is that it be in the same language as indicated by the <language> element in the <info> block the <event> element is found in. Therefore, for consumers, the ability to rely on this element for uses other than just display is not possible.

With this in mind, the concept of a mapping table where CAP originators and CAP consumers can contribute âeventâ lists has been conceived. With this table, language terms can be mapped to each other as a reference for client consumers thus allowing some measure of interoperability to be possible.

End of questions requiring consensus.

We should be in agreement on this before I complete the TC Admin Document Template Request.

Cheers,
Rex

--

Rex Brooks

Starbourne Communications Design

Email: rexb@starbourne.com

GeoAddress:

1361 Addison St. Apt. A

Berkeley, CA 94702

Phone: 510-898-0670

Virus-free. www.avast.com

emergency-cap message