EM CAP Profiles SC

Hi,
	As volunteered I'm trying to boil down the rationale for multiple info blocks into these 3 points so they can be added to the spreadsheet for future reference.  I've tried to summarize all the use cases discussed today and identify the drivers for multi-infos, in this case language, location, time and the associated following elements that provide the reasoning that accompanies the driver.  Clear as mud right... comments welcome

Rationale for multiple info blocks:

- express event info in multiple languages with the language element being used to denote the language of the info block and free form text element values changing accordingly
- express event info intended for different geolocations with the area blocks changing between info blocks in concert with some other elements such as responseType, instruction, headline, description, and effective/onset/expires.  Not to be confused with using multiple area blocks in a single info block.
- express event info that changes in time with the effective/onset/expires elements changing between info blocks in concert with some other elements such as Urgency/Severity/Certainty, responseType, instruction, headline, and description.

-- 
jake@jpw.biz
--

OK, I've noted our conclusion from this week's call and summarized
Jake's language in the worksheet; we can use his full language later in
a more expansive document.

That said... I do anticipate we may get some pushback on this point as
we move through the comment process.  The use of info blocks for various
languages seems fairly uncontroversial, but I suspect some delivery
systems may not want to buffer delayed-onset alert-segments in their own
systems, or to need to route different parts of a single message to
different target audiences using their own technology.  

We'll see, but personally I don't think it would be unreasonable to ask
originators to create separate CAP messages for distinct audiences
(language excepted).  And I think life might be a lot easier for
distributors, without being that much harder for originators, if all
messages could be assumed to be for immediate distribution (of course,
the description and instruction could still address a timeline for the
actual event) rather than asking them to hold message content for later
(by which time it might have been updated or canceled, or even just
forgotten by the originator in the rush of events... you see how it can
get complicated.)  

Certainly we had a theoretical basis for allowing these more esoteric
uses of the info block in the CAP spec, and one certainly can imagine
use-cases for them, I don't believe I've ever seen them occur in actual
practice.  That's why I'm thinking we may be called upon to reconsider
whether they're necessary enough to justify putting the accompanying
complexity on IPAWS infrastructure and dissemination components.

Again, just my personal thoughts.

- Art



Art Botterell, Manager
Community Warning System
Contra Costa County Office of the Sheriff
50 Glacier Drive
Martinez, California 94553
(925) 313-9603
fax (925) 646-1120

> languages seems fairly uncontroversial, but I suspect some delivery
> systems may not want to buffer delayed-onset alert-segments in their own
> systems

The issue of delayed messages isn't just a multi-info block issue.  I had raised this point in my comments to the EAS profile group and had intended to again raise this issue when we got to the info block time elements in the crosswalk document.  So I think it could be resolved in general and will therefore trickle down to other use cases like multi-info.

> We'll see, but personally I don't think it would be unreasonable to ask
> originators to create separate CAP messages for distinct audiences
> (language excepted).  And I think life might be a lot easier for

Distinct audiences, ie areas/responses, is a very common occurrance.  I'm not sure how the burden is different processing 3 distinct messages, versus 1 message with 3 info blocks.  If anything the burden is higher since you must have some way to associate the 3 distinct messages as being part of the same event, track updates/cancels independently, and run the risk of message overlap and conflicting instructions.

-- 
jake@jpw.biz
--

>>> Jacob Westfall 

> It's not unusual, but the use of multiple info blocks to address it
> hasn't turned out to be common in practice, at least not anywhere I've
> seen.  

That speaks more to the current state of CAP origination and implementation than the actual use cases.  More than 60% of publically available CAP messages fail basic validation tests.  Simple things like dateTime values, missing elements, invalid characters, etc.  So its not multi-infos and complex messages that are tripping people up right now.

> So I'm thinking this might be an area where the profile might
> simplify things for implementers at both the origination and
> dissemination ends.  

I've got a number of examples that can show this doesn't simplify things, but actually creates more problems and would be willing to contribute them.  Although via email might be lengthy, more suited to a powerpoint or whiteboard app discussion instead.  I'm also interested in any examples that do show how this simplifies things, does anyone have some?

-- 
jake@jpw.biz
--