[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [emergency-if] EDXL-AT & Situational Awareness
Thanks Tim, This is much more clear now, and I am happy with everything here. Cheers, Rex At 3:31 PM -0400 3/18/07, Timothy Grapes wrote: >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 > -- Rex Brooks President, CEO Starbourne Communications Design GeoAddress: 1361-A Addison Berkeley, CA 94702 Tel: 510-849-2309
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]