OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

emergency message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [emergency] The Modularization of CAP?

I would rather discuss this in the call, or 
schedule a longer session for it. I've seen part 
of one such effort, taking VRML97, the ISO 
standard to X3D, the new version, which does what 
Allen is suggesting. Of course it was an early 
such effort and took from 99 till this year to 
happen, and that is only for a very basic set of 
modular profiles, so I've fallen, along with all 
the rest, into some of those pits along the way 
before I had to let it slide for a couple of 
years until the single-mesh humanoid standard got 
done in 2001-2002, and I took it up again late 02 
and the first half of last year, adding my own 
extension which I plan to make an openly 
available module itself. So, while I am for 
modularization, I happen to be aware of some of 
the pitfalls, and a lot of arguments I would just 
as soon not replay. I have a bunch of catching up 
to do after an intense week and a family reunion, 
so I will just leave it till maņana. Like a lot 
of things, I bet it will still be there when I 
get to it tomorrow morning, along with the rest 
of the untended tomato patch.


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 
>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
>To unsubscribe from this mailing list (and be 
>removed from the roster of the OASIS TC), go to 

Rex Brooks
GeoAddress: 1361-A Addison, Berkeley, CA, 94702 USA, Earth
W3Address: http://www.starbourne.com
Email: rexb@starbourne.com
Tel: 510-849-2309
Fax: By Request

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]