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


Help: OASIS Mailing Lists Help | MarkMail Help

emergency message

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

Subject: EDXL-Reference Information Model

Hi Renato, Karen,

I'm writing to get the task of building the EDXL Reference 
Information Model started (EDXL-RIM). The TC voted last week to make 
this a priority and to spend a large proportion of the upcoming 
Face-to=Face meetings at the OASIS Symposium 2007 on establishing 
Scope and Requirements. I volunteered to work with you to build a 
EDXL Framework or Skeleton document from which we can work in the 
meeting to get this effort underway. We are scheduling these 
discussion for Afternoon in San Diego, California so that, hopefully, 
you can participate as much as possible. I will also be attending via 
teleconference, so I expect the pace will necessarily have to 
accommodate us. While it is not optimal, it is doable.

I am attaching the Requirments Specification Template as a place to 
start. I know my own initial impetus is the same that I consistently 
warn other groups about. I feel like I know enough about this family 
of specifications from having been involved with it from the start 
that I can just jump in and start reeling off requirements, and I 
will certainly be making initial suggestions.

However, I think we should eat our own cooking, so I am going to 
start with the need to establish clear scope and requirements. I 
would like to avoid the temptation to start diagramming information 
classes and relationships between these classes for the time being at 

Although I am attaching my bare-bones start of a Requirements 
Specification, I am including a first pass at the first text section:
Document Scope and Purpose
This document states the Functional Requirements for the overall 
family of Emergency Data Exchange Language specifications. As such, 
these requirements should be formulated as the abstract principles 
which govern the enumerated elements within the individual 

For Instance, the Emergency Data Exchange Language Distribution 
Element 1.0 Specification (EDXL-DE.Spec_v1.0) specifies <targetArea> 
for geospatial or political area with specific information regarding 
the originator's intent with regard to the routing of an EDXL message.

It used a naming convention with an initial lower camel case letter 
that has since been replaced a convention that uses an initial upper 
camel case letter. This document should explicitly state the broad 
naming and design rules that have been adopted.

Moreover, the EDXL-RIM SHOULD define the concept of <TargetArea> or 
<Area> as an abstraction that can be used for the EDXL-DE or the 
EDXL-Resource Messaging (EDXL-RM) specifications, or any future EDXL 
specifications. Such a definition SHOULD be sufficently broad and 
abstract to allow the basic concept to be used consistently across 
the spectrum of EDXL specifications. As such, this  requirements 
specification SHOULD NOT include as a requirement the most concrete 
level of information, such as the originator's intent or specifically 
that both geospatial and political MUST be included because that 
would not be true for the element <TargetArea> in EDXL-RM that does 
not include political information nor an area defined by intent.
I don't want to go any further than this right now. I would like to 
set up a time for a teleconference with you if I can so we can add 
just enough to the Requirements document to use as a Framework to 
channel discussion in the Face to Face meeting. We need to have the 
TC's input.

Hopefully we can decide which SC should carry this work forward. 
While the Messages and Notification SC has handled the EDXL family so 
far, I am fairly sure we will see a specific sponsored recommendation 
coming from the Infrastructure TC which will fall within EDXL as 
well, so it is a decision that needs to be taken carefully. However, 
since we have championed this concept for a while, we should help get 
it launched in the best way we can.


Rex Brooks
President, CEO
Starbourne Communications Design
GeoAddress: 1361-A Addison
Berkeley, CA 94702
Tel: 510-849-2309


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