Re: [emergency] The Modularization of CAP?

[R. Allen Wyke <emergency-tc@earthlink.net>]

On Jun 14, 2004, at 8:29 PM, Art Botterell wrote:

> 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.

Point well taken, and I agree completely with what your statement is  
protecting. Regardless of what we do, be it anything with  
modularization or even the next version, the net result must be a  
simple and easy to use markup language that stays true to its purpose.

> 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.

Ok - I follow that as well. Can you elaborate just a touch more on this  
though? I have a mental picture/definition of what a coordination  
language and/or profile is, but I want to make sure we are using those  
terms in the same way.

> 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.

Completely agree with this, which is why I suggested it  
(modularization, CECL, or whatever) as a separate focus group/effort.  
Don't want to disrupt 1.x at all.

> - 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.
>