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