Element-Message Matrix, Revised ERM, Notes on Data Dictionary

[Rex Brooks <rex.brooks@ncoic.org>]

  Hi Everyone,

I have uploaded the first draft of The Element-Message Matrix, a Revised 
ERM,  and a set of Notes on writing the spec based on updating the ERM 
and the Element-Message Matrix with the Data Dictionary up to today's 
date. Tim uploaded this version 3.2 last week. I recorded the 
corrections, suggestions and comments as I caught up with Tim's work and 
pushed on to make sure we have something concrete to work against while 
I'm out next week.

I have also gotten through much of the first draft of the first couple 
of sections in the spec document. I sent it along to Tim this weekend to 
ask for an update of the origins of the EDXL family to be sure we are in 
step with the changes in DHS, especially wrt the DM Program.

You will notice that I have significantly changed what the ERM looks 
like, with a set of packages which "realize" the five (5) report types 
rather than staying with the previous diagrams which gave our specs the 
appearance of having a DOM. Even when we say it is non-normative and 
intended to give the reader an illustration of the datamodel structure, 
it looks that way.  If it looks like a DOM but it isn't, I think it 
detracts from the readers' understanding rather than adding to it. 
However, if we want to go back to that approach, I can do that since I 
haven't deleted the previous model, yet.

I'm not sure adding a Common Elements category of classes to this 
specification helps us much. However, I think it would be okay to add 
"new" common elements, such as "Remarks" as standalone classes in the 
Common Elements package inside the SupportingElementsModel.  As of now I 
have left it there.

Common Elements is planned to be its own spec or set of specs, but it is 
not yet ready to stand on its own as a separate published Committee 
Specification from the RIM SC. We are working on it there. By including 
it in that package we leave the RIM in a position to incorporate these 
standalone classes in a Common Elements package which can then be used 
by any other EDXL deliverable without rewriting any of the Common 
Elements on a spec by spec basis, or what is worse in my opinion, 
referencing one of purpose-specific specifications as a Common Elements 
model just to reuse one of these elements.

Anyway, I know you don't have enough time to read through the Notes in 
detail, I put it together as a checklist that can be used later to 
ensure that these things are correct in the spec before we take it to 
Public Review.

Cheers,
Rex

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