MHonArc v2.5.0b2 -->
emergency message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: The Modularization of CAP?
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]