[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [emergency] GJXDM vs EDXL Distribution isses
I have received some very good comments on GJXDM from some OGC members. They have asked me to bundle the comments up and pass them on. I was wondering what the best mechanism would be to properly share these comments with the GJXDM folks? Thanks for any guidance. Carl ----- Original Message ----- From: "Daconta, Michael" <Michael.Daconta@dhs.gov> To: <rexb@starbourne.com>; <acb@incident.com>; "Daconta, Michael" <Michael.Daconta@dhs.gov>; <emergency@lists.oasis-open.org> Sent: Thursday, December 30, 2004 6:02 AM 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 > <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. > > 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. >> >>- 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 "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 >>>-- >>>Art Botterell >>>Common Alerting Protocol Program Manager >>>Partnership for Public Warning >>>www.PartnershipForPublicWarning.org >>>(707) 750-1006 >>> >>>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. >> >> >>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. > > > -- > 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 > 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]