OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

emergency-if message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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]