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] GJXDM vs EDXL Distribution isses

Rex conveys my feelings as well. The OASIS EM TC just started comparing
the Common Alerting Protocol (CAP)ver 1.0 & draft ver 1.1, GJXDM, EDXL,
and the IEEE 1512 series to identify differences and commonalities. This
should provide a clearer picture of potential problem areas and allow
for open constructive discussions. 
I do not believe anyone from the various groups is looking for a "turf"
battle, rather now is the time to thoughtfully review all sections of
our (all groups) work and adopt the best practices as agreed to by all

Tom Merkle
CapWIN:        www.capwin.org 
Phone:        (301) 614-3720
Cell Phone:   (240) 375-1966
Fax:          (301) 614-0581
e-mail:        tmerkle@capwin.org
6305 Ivy Lane Suite 300
Capital Office Park
Greenbelt, MD 20770

-----Original Message-----
From: Daconta, Michael [mailto:Michael.Daconta@dhs.gov] 
Sent: Thursday, December 30, 2004 8:03 AM
To: rexb@starbourne.com; acb@incident.com; Daconta, Michael;
Subject: Re: [emergency] GJXDM vs EDXL Distribution isses

Hi Everyone,
I will email the group later with more thoughts on GJXDM.  In general, I
agree with Rex's position below.  My concern I expressed yesterday was
because I have seen it many times before where groups favor invention
over reuse.  I know the GJXDM is not perfect but I also  believe it is
well worth the effort to fix, improve and reuse it. 
Sent from my BlackBerry Wireless Handheld

-----Original Message-----
From: Rex Brooks <rexb@starbourne.com>
To: Art Botterell <acb@incident.com>; Daconta, Michael
<Michael.Daconta@dhs.gov>; emergency@lists.oasis-open.org
Sent: Wed Dec 29 18:53:42 2004
Subject: Re: [emergency] GJXDM vs EDXL Distribution isses

Just to add my $.02 a bit further, I don't think there is much chance of
us adopting a "not-invented-here" parochialism. Since a few of us are
trudging through the entire GJXDM to discover what and where the
differences are with the work we've done so far, I suspect that we will
most likely recommend best practices for implementors to use the
appropriate namespaced term.  To do that we must first do the diligence
of comprehensive comparison so  we can then look at similarities,
duplications and differences and make our recommendations.

And just to add a bit more, while I am keeping my mind open to
alternatives, I suspect we will end up settling on the use of an
ontological approach to making our recommendations: for uses in
inontology/taxonomy x, use schema a, for uses in ontology/taxonomy y,
use b, etc. I am personally in favor of using existing work whereever it
doesn't require too many extensions to cover the requirements we have
scoped for the particular piece of work.


At 1:14 PM -0800 12/29/04, Art Botterell wrote:
>Michael, it's not my intent to disturb you.  However, I assume you'd 
>agree that there's also a risk in trying to force what may prove to 
>be unlike concepts into like boxes just for short-term convenience.
>We need to look carefully at the realities of the real-world 
>applications and processes before reflexively adopting prior art 
>just because "it was there first."  I'm sure you're not suggesting 
>the latter approach.  Nor have I ever objected to reuse where it's 
>- Art
>At 4:04 PM -0500 12/29/04, Daconta, Michael wrote:
>>This email thread is disturbing... I would hope this TC can avoid 
>>the "not invented here syndrome" and focus on reusing schema 
>>elements where the concepts are equivalent or can be aligned.
>>Sent from my BlackBerry Wireless Handheld
>>-----Original Message-----
>>From: Art Botterell <acb@incident.com>
>>To: emergency@lists.oasis-open.org <emergency@lists.oasis-open.org>
>>Sent: Wed Dec 29 15:43:52 2004
>>Subject: Re: [emergency] GJXDM vs EDXL Distribution isses
>>At 9:34 AM -0500 12/29/04, Ham, Gary A wrote:
>>>To be GJXDM compliant we would probably have to change the
>>>to something more akin to "EmergencyEventTypeCode"...
>>I'm not sure whether "compliant" is the right criterion.  Our
>>functional goal is "compatible"... framing it in terms of compliance
>>transforms a technical issue into a political one.  I'm not sure
>>that's either necessary or wise.
>>Not necessary because we have the mechanism of namespaces to allow
>>domain-specific element design choices to be made "close to the
>>ground," nearer to functional concerns and farther from bureaucratic
>>ones.  It gives us a viable alternative to the
>>grand-unified-data-model-of-everything approach, which I'm afraid may
>>be self-defeating in its scope.
>>And not wise for several reasons:
>>1) Adopting a stance of "compliance" to one user group... in this
>>case, the justice community... necessarily distances us a bit from
>>others... fire, transportation, health, etc.  While I realize that
>>Justice is ascendant in post-9/11 America, we're part of an
>>international standards organization and those of us who've been at
>>this for awhile have seen these trends shift back and forth over the
>>2) There's a learning curve here.  As Gary points out, just because
>>the GJXDM was the earliest and largest doesn't mean it got everything
>>right.  We need to leave the door open for learning and improvement.
>>(After all, the US had the first color television standard in the
>>world... and as a result spent the next forty years looking at the
>>worst color tv pictures in the world.)
>>3) As mentioned above, the wider the scope of a data model, the more
>>technical and political inertia it accumulates.  Keeping a degree of
>>compartmentalization lends flexibility, so long as there's a
>>mechanism (e.g., namespaces) for preventing collisions.
>>Now I'm not arguing against adopting an ISO 11179-based naming
>>scheme.  I'm just suggesting that we ought to think carefully and
>>explicitly before slipping into an assumption that we're somehow
>>obliged to comply with some other group's scheme.
>>- Art
>>Art Botterell
>>Common Alerting Protocol Program Manager
>>Partnership for Public Warning
>>(707) 750-1006
>>To unsubscribe from this mailing list (and be removed from the 
>>roster of the OASIS TC), go to 
>To unsubscribe from this mailing list (and be removed from the 
>roster of the OASIS TC), go to 

Rex Brooks
President, CEO
Starbourne Communications Design
GeoAddress: 1361-A Addison, Berkeley, CA, 94702 USA, Earth
W3Address: http://www.starbourne.com
Email: rexb@starbourne.com
Tel: 510-849-2309

To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to

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