To some extent the deep issue here parallels the existing distinction between the <description> and <instruction> blocks. The most common use of the <area> structure is to describe the desired geographic scope of the <instruction>. However, sometimes there's also a desire to annotate the <description> of the causal event(s) in more precise geospatial terms.

So... one possible approach might be to convert both <description> and <instruction> from simple free-text elements into more complex elements with both the text field and some optional geospatial descriptions... possibly using some version of the <area> structure. In that case the geospatial elements of the expanded <instruction> block would be equivalent to the existing <area> usage... but less ambiguous.

This would be a structural... read "CAP 2.0"... change, but that might be a good thing in terms of making the difference clear.

A few key points:
1. Emergency officials affected by an event often (if not more often than not) receive their situational awareness at the same time as the public, from a the public alert. Communications between officials is far from good!
2. Emergency officials are presenting alerts on maps as situational awareness. They want to know where the event is located in addition to what the public has been told to do, often in this order, given so few of them play a communications role.
3. Use cases such as a chemical fire with a large notification area, wildfire with a large evacuation area, protest route with a buffer notification area, etc. have two distinct areas to be communicated: Event area and notification.
4. Canada, and others, have had to deal with the ongoing challenge of distinguishing subject even and alert area, event duration and message expiry, etc. The introduction of a elements, blocks, etc. can help put the ongoing issues behind us, given that all stakeholders will be discussing specific elements and not <parameter> variables. E.g. This morning I learned that a key stakeholder has introduced an event location <parameter> to help overcome their challenge, when Canada has already adopted a documented <parameter> solution they should be using.

My prefence is to leave the elements <description>, <instruction>, and <headline> alone (i.e. no constraints beyond the obvious minimal few that there are) . So for those that want to include event information within these elements, they are free to do so oin their own way. For those that feel that event information is useful, optional elements like <onset> can exist or new ones can be made to exist.

Right now, Env. Can. does not put in event information but we do forecast by event. Warnings for these vents aren't 1 to 1 so however many <info> blocks are needed to divide the warning up; by <instruction>, <urgency> , <severity> or whatever, we have the option to do so and we use it often. But in the end we keep getting asked to include event details that automated systems can process. Event location and motion are highly desired details. So if elements were to exist to that end, and we had the info, we would use them.

But we would not want the <discussion> to be constrained to anything for this use (content or format) as that is not what we feel the <discussion> was intended for. So we would rather create a <parameter> and house that information there or if CAP 2.0 had an optional element we would use that.<discussion> should be for the alert.

But it all comes down to how best to input extra info that people want. Since the event and the alert are two separate objects, the info that goes with those objects should be grouped separately so that elements can coupled without having to be qualifed to the same object (CAP uses no qualifers).

An additonal consideration goes to what an issuing authority uses CAP for. If it is for primarily public alerts, then no need for all the event info spliced out. If it is used for Situational Awareness then I can see how event info could easily be included.

As it is Env Can. uses CAP more for situational awareness rather than public alerting but what we actually do is use it to create situation awarenss about the alert (not the event). In other words we often describe the Alert all in one CAP file (with its many divisions - primarily based on <instruction>).

This allows us to solve another problem we, and the NWS, refer to as bifurcation. A secondary benefit is the "continuity" problem that also gets solved - especially with large moving storms. Those two are another discussion, but the point is that we use CAP for situational awareness a lot. So extending CAP to include situational awareness information on the event itself is rather easy for us (if and when we collect such info and should a schema for elements comes along). If one doesn't come along, we can easily create some <parameters> to do so.

Finally, for those that want to use CAP purely for public Alerts - understand that we create our CAP so that channel specific customizations can easily be built by selectively taking the necessary information out of what we consider to be, our more comprehensive CAP. The NWS works off a different model where their alerts are more Public Alert like than ours. It makes our two relationships with LMD's quite different.

So back to the topic....Event Location and Motion information is secondary to us, but when we do get that stuff collected (not way far off), we will be able to include it without to much trouble, given our approach, and theoretically without "bifurcation" and "continuity" issues there too. But in the end, its not a critcal piece for us - what's critical is the mechanism that we end up setttling on for adding any ancillary information, regardless of what it is about.

I've drafted CAP <element> content for discussion purposes, and posted to CAP SC documents because I could not find a means of posting here in JIRA.

Doug's "locationarea" proposal can be found at https://www.oasis-open.org/apps/org/workgroup/emergency-cap/download.php/53772/CAP%20Event%20Location%20da140807.docx