The Modularization of CAP?

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

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