[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Element-Message Matrix, Revised ERM, Notes on Data Dictionary
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]