RE: EDXL common distribution element

["Daconta, Michael" <Michael.Daconta@dhs.gov>]

Hi David,
 
Getting defensive over this does not solve the legitimate problems noted in the report.  I know very well my strategic imperative and I assure
you it intersects with this effort. More importantly than that is achieving interoperability across domains which I also know a few things about.
So, when you propose an element in a message that is ambiguous and can be misinterpreted, I have a problem with it.  When you a propose an 
element in a message without a use case to judge its utility, I have a problem with that.  As for 9 months of discussion, is there any documentation on those discussions?  I would like to see it.
 
So, let's focus on the technical issues.  In fact, let's look at what the W3C does for new specifications -- they publish a use cases document.  If you look at the specificity in document like http://www.w3.org/TR/xquery-use-cases/  -- I would recommend a similarly rigorous process.
 
 - Mike
________________________________

From: David Aylward [mailto:daylward@comcare.org]
Sent: Mon 3/28/2005 11:02 AM
To: Daconta, Michael; Elysa Jones; 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; Tincher, Lee; tgrapes@evolutiontechinc.com
Subject: RE: EDXL common distribution element


Mike:
 
It might be helpful if we arrange a briefing for you on the EDXL process. You seem to be under the mistaken impression that a couple of folks got together and invented the need for a Distribution Element, whipped up a draft spec without reference to other standards work (e.g. GJXDM), demonstrated it, and threw it into the TC to figure out.  Each of those impressions is understandable, but wrong.  You also seem to be under the mistaken impression that demonstrations have to be perfect to be valid.  We find them to be helpful when they point out improvements that are needed.
 
The October EDXL demonstration had almost all the web-based EOC tool competitors (and several others) exchanging messages using the DE, and CAP as the content.  If you spend any time in the emergency response space, one of the first things you run into is people talking about the need for "EOC to EOC interoperability" (although both the demonstration and user requirements make it clear that that is a far too narrow definition of the need).  
 
We solicited the reactions of all the participants, and organized the process that produced the criticism memorandum of that demonstration you just read.  In this case, the EIC member companies that built to the EDXL draft distribution element and participated in the demonstration said it was not a big deal to do it, but would have been easier if there were "an implementation guide".  Gary Ham of Battelle was tasked by DM to write that and is working on it.     
 
The "canvassing of the emergency response community" is a detailed and intensive on-going process, including formal meetings of the DM Practitioner Working Group run by Touchstone (which initiates high level requirements), the Standards Working Group facilitated by ComCARE, and lots of detailed conversations in between.  The key conclusion from 9 months of discussion about the DE was its value would be that it was not narrow , not designed for a "3 specific use cases".  The whole point is for the range of emergency agencies to be able to communicate with each other, without creating a new interface for their CAD system for each new message that comes along; almost by definition that will not fit in three specific use cases.  Your suggestion flies in the face of the strategic imperative these agencies share.  That is a different strategic imperative than the one your Center has, but there is no reason they cannot co-exist, and indeed be mutually supportive.    
 
We can and should do a much better job documenting all of this, writing up specific use cases as we discussed, and exploring other specifics.  But I don't think that requires putting aside this project. 
 
David Aylward
Director
The ComCARE Alliance
1701 K St., N.W., Suite 400
Washington, DC 20006
202-429-0574 Extension 201
202-296-2962 (fax)
202-255-3215 (mobile)
 
-----Original Message-----
From: Daconta, Michael [mailto:Michael.Daconta@dhs.gov] 
Sent: Sunday, March 27, 2005 9:07 AM
To: Elysa Jones; 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: RE: EDXL common distribution element
 
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