RE: [emergency] RE: EDXL common distribution element

["Tom Merkle" <TMerkle@capwin.org>]

The following is my personal opinion (aka $.02 worth):

The initial press articles about EDXL raised the expectations of the
first responder community and the subsequent demonstrations did not
clarify the magnitude of a complex problem. Speaking strictly as a
member of the EM TC, I believe we need to carefully review the current
status of the EDXL and how it can be (or not) integrated into the
National Information Exchange Model (NIEM) work. 
I feel Mike Daconta's comments are appropriate and insightful. EDXL (or
a distribution element of some type) should exist, but must be fully
vetted with the various user groups. The current EDXL model needs much
more work and does not fully support the user community. 
I suggest the EM TC and the DHS/DOJ representatives schedule a meeting
as soon as possible to fully review the EDXL and NIEM status. NIEM is a
reality that will evolve at a rapid rate and will benefit from a
distribution element. 


Regards,
 
Tom Merkle
 
-----Original Message-----
From: Elysa Jones [mailto:ejones@warningsystems.com] 
Sent: Monday, March 28, 2005 5:06 AM
To: Rex Brooks; Daconta, Michael; David Aylward;
emergency@lists.oasis-open.org
Cc: Hines, Chip; Tom Merkle; gordon.fullerton@dhs.gov;
mwalton@eteam.com; pembley@mstar2.net; Patrick Halley;
tgrapes@evolutiontechinc.com; Sukumar Dwarkanath;
bill.kalin@associates.dhs.gov
Subject: Re: [emergency] RE: EDXL common distribution element

Michael, Rex and others,

Yes, what you suggest and what Rex added makes good sense.  I would very
much like to follow a more rigid requirements definition process and I
think the DM program would be interested in the same.  They have asked
for guidance on how to provide future direction to the standards
organization and I like what Rex suggests.  However, I am concerned for
the time it will take to develop the "standard" for the standard
requirements and we have been asked to move this along as soon as
possible in the interest of EM.  Maybe some of those that are working on
the next requirement for "resource" would be interested in supporting
Rex in his work?

We have talked about the first pass at the distribution element being a
bit of a trial balloon to see if we could get good comments from which
to work.  We have not specifically answered the observations that came
out of the demonstrations and should certainly do so.  We have spent our
time, instead working through the issues of structure for the schema and
enumerated types.  I am not opposed to the priorities Michael suggests
below .  Others?

Regards,
Elysa Jones, Chair
OASIS EM-TC
Warning Systems, Inc.
256-880-8702 x102

At 10:03 AM 3/27/2005, Rex Brooks wrote:
>My $.02 FWIW:
>
>I actually agree with Michael even though I have been doing my own 
>diligent best to help move this effort forward as fast as it was 
>originally asked of us to move it by EIC and the ad hoc EDXL group that

>first recognised the need. (Please overlook the "s" in place of and due

>to the lack of a lower case Z).
>
>Over the last year and half I have been working on a recommendation for

>an informal standard for developing standards, even for diverse problem

>areas such as device and messaging independence.
>
>It is similar to what Michael suggests, though different, but it starts

>with the kind of survey suggested, moves to developing real-world 
>scenarios that follow well-known processes as far as they can be 
>modeled, then builds UML Use-Cases for the range of known necessities, 
>and from those models builds a formal Requirements Document, with a 
>base UML model of the combined use-cases. From such a starting point 
>any specification can then be checked against the Requirements to be 
>certain that the actual requirements have been addressed. There are 
>other features of this evolving recommendation which make this easier 
>all around for both the standards-writers and the implementors, but I 
>won't go into that particular song and dance (thanks be!).
>
>Just my $.02.
>Rex
>
>At 9:06 AM -0500 3/27/05, Daconta, Michael wrote:
>>Hi Everyone,
>>
>>I think the summary observations on the interoperability demonstration

>>should be taken very seriously.
>>If you compare the specific comments (like "it became evident that 
>>each group defined their own implementation of the fields and values 
>>in the EDXL header") of the document against the purpose of
"interoperability"
>>-- It does not sound like a successful demonstration.
>>Have these observations been responded to with a course of action to 
>>correct each deficiency?
>>
>>Elysa you state below that you are trying to get the "distribution 
>>element moved through quickly".  I do not think that is the right 
>>course of action given the issues with individual fields.  Also, does 
>>the TC have a document that details specific use cases for the
distribution element?
>>
>>I would again urge the TC to consider changing its priorities:
>>1. Move the Distribution element to a "hold state" until after at 
>>least 3 specific exchanges have been created, tested and deemed 
>>successful.  In the meantime, research can move forward to develop use

>>cases and refine the fields in the distribution element.
>>2. Canvas the emergency response community on their requirements for 
>>specific exchanges and develop a prioritized list.
>>3. Develop 3 specific exchanges leveraging reusable components from 
>>the NIEM.  For types not in the NIEM, nominate new types to the NIEM.
>>4. Take the lessons learned from the specific exchanges to refine and 
>>finalize the distribution element.
>>
>>Regards,
>>
>>  - Mike
>>
>>________________________________
>>
>>From: Elysa Jones [mailto:ejones@warningsystems.com]
>>Sent: Sun 3/20/2005 7:45 AM
>>To: Daconta, Michael; David Aylward; emergency@lists.oasis-open.org
>>Cc: Hines, Chip; tmerkle@capwin.org; gordon.fullerton@dhs.gov; 
>>mwalton@eteam.com; pembley@mstar2.net; Patrick Halley; 
>>tgrapes@evolutiontechinc.com; Sukumar Dwarkanath; 
>>bill.kalin@associates.dhs.gov
>>Subject: EDXL common distribution element
>>
>>
>>
>>Hello Mike,
>>
>>First, let me say that I have modified the "reply all" list for this 
>>message to include only those of whom I am aware are active in the 
>>OASIS TC process since I am also posting this on the EM-TC list and I 
>>deleted the discussion that lead up to your comments and request.  
>>Also, Sukumar at ComCARE is an individual member and that membership 
>>does not provide the ability for the other ComCARE members to address 
>>the list.  However I included you guys since you are active in the 
>>process.  Please send any comments you have through Sukumar.  I did 
>>want to be sure your (Mike's) comments are presented to the group as 
>>you are a TC member.  BTW - DHS is too.
>>
>>Please find the attached Issues list provided to the EM-TC after the 
>>fall EDXL Distribution Element demonstrations as you requested.  This 
>>is the only summary of results that has been posted to the OASIS web 
>>site although there may be more.  I understand your concern for the 
>>magnitude of the effort and the TC is diligently working through the 
>>issues, some of which you have pointed out.  The senderID represented 
>>as a URI has been discussed and seems to be our consensus although not

>>firmly decided in meeting notes.  We are also discussing the need for 
>>a hierarchy in structure for the enumerated types and are seeking 
>>specific input.  The targetArea element will certainly be in concert 
>>with OGC and our GIS subcommittee is working that detail now.  The EM 
>>community is in need of getting the distribution element moved through

>>quickly as voiced by the DM program.  We are making every effort to
support that request.
>>
>>Thank you for your comments and we welcome your input to the process.
>>
>>Regards,
>>Elysa Jones, Chair
>>OASIS EM-TC
>>Warning Systems, Inc.
>>256-880-8702 x102
>>
>>PS:  ICS=Incident Command System
>>
>>At 08:00 AM 3/19/2005, Daconta, Michael wrote:
>>>Hi David,
>>>
>>>I have heard about EDXL demonstrations.  Do you have any results or 
>>>studies from implementing the EDXL distribution element?
>>>
>>>I have been examining the EDXL SMF draft you sent (dated 9/23/2004) 
>>>and I have concerns almost about every single field in the proposal.
>>>Let me list a few:
>>>* Sender ID -- current format is an email address.  Is the purpose of

>>>this identification (in which a URI would suffice), or as a POC for 
>>>communications.  If the former, a dereferenceable and unique URL 
>>>describing the sending organization would be better.  Email addresses

>>>are most commonly used to identify individuals and not organizations.
>>>* SenderType -- the enumerated list for this is riddled with 
>>>inconsistency.  There are varying granularity levels 
>>>(Government/Coast Guard), mixed metaphors (functions vs organizations

>>>vs aggregations), and  overlapping categories.
>>>* messageStatus -- the values for this are not status (which is a 
>>>singular state in a series of states) but purpose.
>>>* messageType -- What about other types like Query?  Seems to me we 
>>>need a "theory of message types" ... could be done by surveying the 
>>>many different messaging systems (I believe NLETS have a different 
>>>set of message types).
>>>* incidentID -- this should not be the Name or identifier.  A name is

>>>different than a unique identifier.  This should just be identifier 
>>>(since it is an ID field) and you could add another optional field 
>>>for incidentName or incidentLabel.
>>>* eventType -- again, this enumerated list has many problems.  Also, 
>>>these "type" categories should allow for both generic and specific 
>>>categories (a class hierarchy).
>>>* eventEtiology -- would prefer a simpler label like "eventTrigger" 
>>>or "eventCause".  Also, besides a type an event may be referred to by

>>>a label or specific identifier.
>>>* icsBranch -- excuse my ignorance of this acronym.  What does ICS 
>>>stand for?  The document does not spell this out.
>>>* confidentiality -- there are more complex requirements than this 
>>>for privacy and security.
>>>* targetArea -- assume this is in compliance with OGC.
>>>
>>>This is not my exhaustive list of issues -- because of the broad 
>>>scope of this standard -- every field will require detailed 
>>>understanding, use cases and design.  I see this document as a 
>>>strawman that is only illustrative of the basic concepts.  Because of

>>>that, I do not believe it is ready to be standardized.  A rush to 
>>>move this from illustrative to normative, without putting in the 
>>>required study, rigor and testing, would
>>  >be counter-productive.
>>>
>>>Which brings me to a more general issue -- why is the EDXL TC taking 
>>>on this task first?  To me, it is akin to trying to swallow the whale

>>>in one bite.  I would recommend a more narrowly focused effort to 
>>>analyze the communities exchange requirements and craft specific 
>>>exchanges as a better approach.
>>>In my opinion, specific exchanges with narrow scopes that "digitize"
>>>currently manual or time-consuming processes (pain points) has a much

>>>higher probability of success.
>>>
>>>Regards,
>>>
>>>   - Mike
>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: emergency-unsubscribe@lists.oasis-open.org
>>For additional commands, e-mail: emergency-help@lists.oasis-open.org
>
>
>--
>Rex Brooks
>President, CEO
>Starbourne Communications Design
>GeoAddress: 1361-A Addison
>Berkeley, CA 94702
>Tel: 510-849-2309
>