[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [emergency-if] EDXL-AT & Situational Awareness
Rex, In response to your first item: I have not seen any e-mails regarding submission, collaboration, or coordination to the Infrastructure Sub-Committee (IF SC) with regards to the EDXL-AT. As co-chair of the IF SC, I facilitated an agreed upon agenda with an external group of DHS FEMA & USAF people about using the "Cursor on Target" as part of the PROPOSED EDXL-AT. Since that meeting that external group has been extremely disruptive and I do not see any e-mails from this particular group. That alone is very troubling. A lot of misinformation has been promulgated concerning the use of a small lightweight DoD component (Cursor on Target) into a larger submission through the Infrastructure Sub Committee (IF SC) that was tentatively called EDXL-AT. The EM TC sent out a letter to the FEMA contractor and others responsible for spreading incomplete or inaccurate information. This contractor has never participated in the OASIS EM TC and doesn't speak for or represent the IF SC in any way. For some reason that particular group has taken on the role of "uber-experts" on all situational awareness items and have been relentless in spreading their own views regardless of the current initiatives underway. This interference is unacceptable and must stop. I am now prepared to escalate this to higher levels within DHS and DoD if required. At this time, EDXL-AT is on hold pending an official sponsor. The search for a sponsor has been severely hindered by actions of a group bend on moving their own agenda above all else. When the IF SC gets sponsorship to move forward on the AT (current name but not officially recognized) the name WILL BE CHANGED since AT now has way too much "promised expectations". We will adhere to all of the work being done in the EM TC and will be fully compatible without being duplicative. The original goal for the AT is still to be modular to the EDXL suite. Regards, Tom Merkle Systems Engineering and Technical Assistance (SETA) US Department of Justice, Office of Justice Programs National Institute of Justice (240) 375-1966 Thomas.Merkle@usdoj.gov -----Original Message----- From: Timothy Grapes [mailto:tgrapes@evotecinc.com] Sent: Sunday, March 18, 2007 3:31 PM To: 'Rex Brooks'; tgrapes@evotechinc.com; emergency-msg@lists.oasis-open.org; emergency-if@lists.oasis-open.org Subject: RE: [emergency-if] EDXL-AT & Situational Awareness Hi Rex, I just wanted to ensure we are clear and have common expectations regarding your second point. Others on distribution are better equipped than I to address "EDXL-AT", except to say that EDXL-AT will be a separate and distinct submission (if and when it comes) from "Incident / Situation Reporting" (FYI, this next standard is simply being referred to as "incident/Situation reporting" due to the much broader range of requirements implied by the term "Situational Awareness"). The standards submission coming from DM/SWG/EIC certainly will adhere to the detailed requirements per the OASIS template, as was required after the fact for RM. In addition, integrated with those textual requirements will be a draft logical design. As I think you agree, this is essential in order to completely and accurately specify practitioner information needs for each required exchange (i.e. a draft data dictionary), and how the information elements must relate to one another (i.e. a UML diagram as you say). This will all be driven from use cases developed through rigorous exercise of scenarios that address all hazards, "incidents" from local/day to day through Disaster scale, and include participation from a range of emergency/disaster/public safety professions. As I said, this will be a logical design which must be adhered to. I fully agree with you that a technical design should not be attempted. The OASIS TC excels at taking the SWG artifacts and making the specification technically feasible and flexible, while meeting all practitioner requirements. I also believe some integration / common usage design will be needed between existing EDXL specs and this new one. This is another area where the TC would best serve the practitioners. I also agree that an EDXL reference info model is very important and should be formally addressed soon, and we have some ideas to contribute. I think your earlier write-up forms a great starting point for that task Best Regards, Tim -----Original Message----- From: Rex Brooks [mailto:rexb@starbourne.com] Sent: Saturday, March 17, 2007 8:15 AM To: tgrapes@evotechinc.com; emergency-msg@lists.oasis-open.org; emergency-if@lists.oasis-open.org Subject: [emergency-if] EDXL-AT & Situational Awareness Hi Tim, fellow SCers, I am not assuming this is true, but recent emails make it appear likely that we are going to get a formal submission for an EDXL-AT, though I hope it is through the Infrastructure SC. This is, if it happens, I assume, separate from Situational Awareness (it certainly SHOULD be since Assets are only one type of Situational Factor Category). Three things must be taken into account as this process moves forward: 1. Absolutely clear and unambiguous definitions of ASSET and RESOURCE, using the work already done on EDXL-RM "MUST" be written. This is simply not optional, and when people start getting hinky about it, just let them know that they will have nice, messy free text DESCRIPTION fields to make all the ambiguous shaghetti they feel they need. They can be counter-productive on their own dime in their own time. No amount of assurance that they "know" best is going to prevent some of us from finally digging in our heels and refusing to accept candidate specifications no matter how long or conscientiously any group or set of groups has diligently and expertly worked on them. 2. We are not accepting Candidate Specifications. Regardless, whether it is AT or Situational Awareness, or both we need to make it PAINFULLY clear to our SMEs that we are NOT looking for candidate specifications anymore. Please make sure they have our Requirements Specification Template. It remains in the RC Document Repository, I know because I sent it to the International Health Continuum TC this week for the same purposes reiterated below. We need them to build their Use-Cases as was done for EDXL-RM, and then build a rigorous set of requirements from those Use-Cases (diagrammed in UML if possible) with CONFORMANCE language built into it, e.g. "MUST," "MAY" and "SHOULD." EDXL-HAVE, in my opinion, proves beyond a shadow of a doubt that accepting candidate specifications by groups of SMEs is almost always a mistake. SMEs rarely fully understand how broad, yet rigorous, the specification-writing process needs to be. We have now had to PAINFULLY deal with the consequences of being persuaded that the SMEs know their area best and that means they are the best group to write a specification for that area, instead of carefully working through a rigorous requirements-writing process. 3. We are working toward developing a unifying EDXL Reference Information Model. Unfortunately, we don't have an EDXL-RIM yet, and that is the only thing that would make building and submitting a candidate specification marginally feasible. When we do develop and OASIS approves EDXL-RIM, we can ask them to conform to it, if they think they absolutely must waste their time and ours by writing another candidate specification. If at all possible, even if it means spending a lot of time in a crash project, we should build EDXL-RIM before or concurrently with any new specs. We need to get that EDXL-RIM sucker done yesterday! Lastly to repeat and rebeat this dead horse, regardless of how well SMEs write a candidate specification and how well their collective experience in the area informs them, anything they write is not going to be organized in the way we have developed, nor is it likely to conform to the specialized techniques and processes we have developed. I really don't want to go through this PAIN or these discussions and debates again, We have learned this lesson three times now. Let's not continue building the case for the necessity of Formal Requirements from Use-Cases. Trying to take a Stitch in Time, Rex -- Rex Brooks President, CEO Starbourne Communications Design GeoAddress: 1361-A Addison Berkeley, CA 94702 Tel: 510-849-2309 -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.446 / Virus Database: 268.18.12/724 - Release Date: 3/16/2007 12:12 PM -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.446 / Virus Database: 268.18.13/726 - Release Date: 3/18/2007 3:34 PM
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]