Re: [emergency] The Modularization of CAP?

[Art Botterell <acb@incident.com>]

We actually flirted with this approach in the earlier ICS-201 
experiment... as I recall, reusing CAP elements and structures was 
surprisingly controversial at that time... but it seemed to work out 
OK in that very limited application.  Personally, I think it's a good 
idea, with one caviat:

The obvious risk is that, having created a reasonably successful 
mouse, we might turn it into an unsatisfactory elephant though the 
familiar processes of 'creeping featuritis.'  Whatever elegance and 
efficiency the CAP design has now stems largely, IMHO, from its clear 
focus on interoperability of alert messages.  It was never intended 
or designed to be the singular answer to all emergency 
interoperability needs.

Maybe we'd be smart to frame this as a second, distinct project... a 
"Common Emergency Coordination Language," say... starting with such 
modules as can be abstracted from CAP, but with its own explicit set 
of objectives and requirements.  Then, once CECL is framed, we can 
see whether CAP 2.0 can be implemented efficiently as a CECL profile.

Meanwhile... since as Rex points out, this could be a lengthy 
process... we could iterate CAP in the 1.x series if necessary to 
address any urgent requirements identified by the user community. 
Hopefully such upgrades would be designed with an eye to where CECL 
is headed.

- Art

PS - Of course, if we call it "Cecil" we may be accused of turning a 
mouse into a sea-serpent.  Still, I think by keeping the two efforts 
distinct for now we may serve both current and future users better, 
while providing a clear path for unification down the road.


At 5:42 PM -0400 6/14/04, R. Allen Wyke wrote:
>I have been spending the last 3 or 4 weeks reading over the CAP 
>spec, the comments that have come in, countless articles, and 
>watching various groups embrace CAP in many different respects and 
>ways. At the same time I have tried to look deeper into where CAP is 
>in the grand scheme of things and where it could go in the future - 
>trying to do my part at thinking long term, while applying energy 
>now to help CAP, the group, and all those involved benefit from the 
>EM TC work.
>
>While it would be easy to digress into a discussion about whether 
>CAP should go this way or that way, that is not the purpose of the 
>TC. Our objective is to stay true to our Charter and "design, 
>develop, and release XML Schema-based standards that begin to solve 
>[these] real-world problems" in the areas of incident preparedness 
>and response. And even more specifically to "provide a framework for 
>data exchange, but also for functionality and service accessibility, 
>all with the common goal of seamless application and data 
>interoperability". Its a tall order, I know.
>
>With that frame of mind/perspective on looking at CAP, I would like 
>to propose we look into the possibility of modularizing CAP. Why? 
>Well, the reason is actually fairly simple. It is to, in a way that 
>would ensure backward's compatibility with 1.0 (of course), break 
>CAP into a set of discrete modules that not only provided a better 
>framework for future versions, but it also creates a wonderful 
>"platform" for our on going standards development by allowing groups 
>in the TC to focus on areas of domain expertise. Basically, it would 
>allow, for instance, the IF SC to take the "infrastructure" elements 
>in CAP, such as <identifier>, <sender>, <sent>, etc., and develop 
>out a more feature rich and widely accepted means of transporting 
>CAP messages from A to B and even relaying to C. The GIS SC could 
>focus on the <area> elements and making sure those are in a place 
>that maximizes their usage. Not to mention the fact that any work 
>done in this fashion could then be used in other efforts more easily 
>- ours as well as others, such as GJXDM for example.
>
>I first saw this tactic used by the HTML Working Group over at the 
>W3C. After reformatting HTML 4.01 as an XML application in XHTML 1.0 
>(http://www.w3.org/TR/xhtml1/), they modularized it 
>(http://www.w3.org/TR/xhtml-modularization/). Once modularized, not 
>only did it provide a more flexible standard to building XHTML 
>compliant profiles/languages for things such as mobile phones and 
>other devices, but it also gave them a better framework for XHTML 
>1.1 (http://www.w3.org/TR/xhtml11/).
>
>So, why do this? Why now? Our group, while sometimes challenging to 
>get everyone on the phone (hint, hint), has grown to include quite a 
>group of members from different companies/agencies and different 
>domains of expertise. We often spend a lot of timing going back and 
>forth trying to condense years of domain expertise into a sentence 
>for someone from a different domain - we try, very hard, but it does 
>not always work.
>
>Not only would doing this put CAP in a place to work with countless 
>new applications (by providing implementers a powerful framework 
>they have some control over, rather than locking them into a 
>specific schema), but it would allow the TC to create small focus 
>groups where members would be parts of efforts that are more related 
>to their domain. Thereby creating a happier and more productive 
>group :) Right now we are all kinda in a big pot that is a bit hard 
>to stir (or hard to stop stirring, like a hornet's nest, if the case 
>may be :)
>
>Anyway - its just an idea I thought I would throw out to see what 
>people thought. Rex, I am sure you will understand where this 
>mentally projects to, and both the IF SC and GIS SC can probably see 
>how their efforts could even be more powerful. Again, the objective 
>is nothing more than trying to put CAP in a place where it can reach 
>and even greater audience and the TC can be in a position to support 
>larger demands from this increased reach.
>
>Comments welcomed and encouraged - Allen
>
>-------------------
>R. Allen Wyke
>Chair, OASIS Emergency Management TC
>emergency-tc@earthlink.net
>
>
>To unsubscribe from this mailing list (and be removed from the 
>roster of the OASIS TC), go to 
>http://www.oasis-open.org/apps/org/workgroup/emergency/members/leave_workgroup.php.