EDXL common distribution element

[Elysa Jones <ejones@warningsystems.com>]

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

EDXL Standards IssuesProblems.doc