Re: [emergency] GJXDM vs EDXL Distribution isses - Daconta, Michael - org.oasis-open.lists.emergency

18 messages in org.oasis-open.lists.emergencyRe: [emergency] GJXDM vs EDXL Distrib...

From	Sent On	Attachments
Ham, Gary A	Dec 29, 2004 6:34 am
Rex Brooks	Dec 29, 2004 10:30 am
Gary Poindexter	Dec 29, 2004 10:55 am
Art Botterell	Dec 29, 2004 12:43 pm
Daconta, Michael	Dec 29, 2004 1:03 pm
Art Botterell	Dec 29, 2004 1:14 pm
Rex Brooks	Dec 29, 2004 2:51 pm
Daconta, Michael	Dec 30, 2004 5:02 am
Tom Merkle	Dec 30, 2004 5:57 am
Carl Reed OGC	Feb 5, 2005 7:38 am
Rex Brooks	Feb 5, 2005 8:04 am
Elysa Jones	Feb 5, 2005 8:27 am
gpoi...@wi.rr.com	Feb 5, 2005 10:06 am
Art Botterell	Feb 5, 2005 1:18 pm
Rex Brooks	Feb 7, 2005 7:35 am
gpoi...@wi.rr.com	Feb 7, 2005 4:20 pm
Robin Cover	Feb 10, 2005 5:06 pm
Rex Brooks	Feb 10, 2005 6:10 pm

Subject:	Re: [emergency] GJXDM vs EDXL Distribution isses
From:	Daconta, Michael (Mich...@dhs.gov)
Date:	Dec 30, 2004 5:02:13 am
List:	org.oasis-open.lists.emergency

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 <re...@starbourne.com> To: Art Botterell <ac...@incident.com>; Daconta, Michael <Mich...@dhs.gov>; emer...@lists.oasis-open.org <emer...@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.

Ciao, Rex..

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 appropriate.

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 <ac...@incident.com> To: emer...@lists.oasis-open.org <emer...@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 "eventType" 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 decades.

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

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.

	Start a set with this search
	Include this search in one of my sets
	Exclude this search from one of my sets