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

[Rex Brooks <rexb@starbourne.com>]

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