RE: [emergency-if] EDXL-AT & Situational Awareness

[Rex Brooks <rexb@starbourne.com>]

Thanks Tom,

Understood. With what Tim has reported, I think we have a good handle 
on how to move forward with those initiatives that have sponsors and 
further into the future. I agree that this should be pushed upstairs 
in order to prevent an inappropriate juggernaut to get started by 
those who seem to be of a mind that if they say a thing often enough 
and loudly enough, it will become true.

Cheers,
Rex

At 5:09 PM -0400 3/18/07, Tom Merkle wrote:
>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
>


-- 
Rex Brooks
President, CEO
Starbourne Communications Design
GeoAddress: 1361-A Addison
Berkeley, CA 94702
Tel: 510-849-2309