Fwd: RE: EDXL-Reference Information Model

[Rex Brooks <rexb@starbourne.com>]

Hi Everyone, Renato,

I am forwarding to the TC list Karen's reply to the message I sent 
out last week to Karen and Renato and this list, and copying Renato. 
I haven't heard back yet from Renato, but I did want to let the TC 
know that I hope we can have a Requirements Document ready for the 
Face-to-Face.

I want to take this opportunity to anticipate what I think may well 
be the central discussion around which specific topics will be 
addressed.

I think we will have two primary lines of thought wrt the EDXL-RIM:

1: Defining Abstract Concepts (with Reference URLs where appropriate) 
for Common Components:
	EDXL-DE Dependency;
	ValueListTypes with Keywords (hopefully using XMDR and ISO 11179 NDR);
	geo-oasis: Where for TargetArea - Location citing 
OpenGeospatial Consoritum GML;
	ContactInformation  using CIQ;
	Scheduling Types reusing what we have developed for EDXL-RM;
	Conceptual Conformance to DRM 2.0 as feasible;
	Conceptual Conforimance to NIEM as feasible;
2: Abstract Information Modeling:
	Hierarchical DOM-like Modeling of Information Structure;
		EDXL-DE Message Routing;
		Security and Non-Repudiation;
		Individual Specification Content Payload;
	Message Exchange Patterns;
	More

I would expect that the structure of the RIM will resemble the 
EDXL-RM Information Model Renato contributed to the Document 
Repository 2006-07-26 
http://www.oasis-open.org/apps/org/workgroup/emergency-msg/download.php/19357/EDXL-RM-Info-Model-2006-07-26.pdf

Cheers,
Rex



>Date: Tue, 27 Mar 2007 13:46:24 +1000
>Thread-Topic: EDXL-Reference Information Model
>Thread-Index: Acdu+akDuSHfQd0OQTu+kkCNo8WyxwBJEdQQ
>From: "Karen Robinson" <Karen.Robinson@nicta.com.au>
>To: "Rex Brooks" <rexb@starbourne.com>
>X-SA-Exim-Connect-IP: 129.94.151.12
>X-SA-Exim-Rcpt-To: rexb@starbourne.com
>X-SA-Exim-Mail-From: Karen.Robinson@nicta.com.au
>Subject: RE: EDXL-Reference Information Model
>X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100)
>X-SA-Exim-Scanned: Yes (on ajax.nicta.com.au)
>X-Rcpt-To: <rexb@starbourne.com>
>X-DPOP: Version number supressed
>
>
>Hi Rex,
>
>Thanks for sending the EDXL-RIM requirements document you produced so
>far.  I suspect that this week is not very good for Renato for a
>teleconference - he will be on leave until Wednesday and then still out
>of town on Thursday-Friday.  I am available this week, but I think it
>would probably be more useful to wait until Renato is available, since I
>know he has some good ideas about what should be in the EDXL-RIM. 
>
>Just so you know, I will be going on maternity leave in late May (and
>will probably be quite busy up until then).  Hopefully I can dial in for
>some of the afternoon discussions during the face-to-face meetings in
>San Diego, but unfortunately I won't be able to be involved in the
>development of the EDXL-RIM in the longer term, as I'll be taking at
>least 9 months of maternity leave (perhaps a full year, depending how
>things work out!).
>
>Karen.
>
>>  -----Original Message-----
>>  From: Rex Brooks [mailto:rexb@starbourne.com]
>>  Sent: Monday, 26 March 2007 2:21 AM
>>  To: Renato Iannella; Karen Robinson
>>  Cc: emergency@lists.oasis-open.org
>>  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
>>  least.
>>
>>  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
>>  specifications.
>>
>>  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.
>>
>>  Regards,
>>  Rex
>>
>>  --
>>  Rex Brooks
>>  President, CEO
>>  Starbourne Communications Design
>>  GeoAddress: 1361-A Addison
>>  Berkeley, CA 94702
>>  Tel: 510-849-2309


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