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


Help: OASIS Mailing Lists Help | MarkMail Help

emergency-msg message

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

Subject: RE: [emergency-msg] Notes from Spec Work

I've made changes per below for a couple suggestions but commented on others...



Tim Grapes






-----Original Message-----
From: Rex Brooks [mailto:rex.brooks@ncoic.org]
Sent: Monday, October 11, 2010 1:35 PM
To: emergency-msg@lists.oasis-open.org
Subject: [emergency-msg] Notes from Spec Work


  Hi Everyone,


I just uploaded the first full Working Draft (WD01) version. I decided to wrap it up before I send this message so I can include it all in one message, of which I suggest you save a copy for reference during the face to face meetings. The WD01 does not yet have a complete Data Dictionary. However, I left placeholders for the remaining 129 (+ or -).

I only got 21 entries done for that, but Tim has the original of that from which I am working, and I will keep a copy of that with me, which I can update as we go along, and make sure that the correct entries are used in the document of record. I tried to get this to you before 11:00 a.m. Eastern Time, but I'll just have to be satisfied with getting it out to you before noon Eastern Time.


Needless to say there is much that needs to be written yet, but I've pulled together enough the specification document so that we can work with it as a whole even if it isn't complete yet. I thought that was important for setting the stage for us to keep our eyes on the objective of getting the first review draft done as soon after the f2f as is feasible with doing the best we can.


As usual, I would suggest we take the position of trying not to let the perfect be the enemy of the good enough. This is a complex little bundle. I have already noted that we need to include "Requests" for each situation report message type, and you will see that I have allowed for that. We can still do it whichever way we choose, but at least it is not missing" here at the start.


I wanted to call your attention to a few items that we will only get into IF we go through the Notes I have collected while working on aligning the EA model with the Data Dictionary and with preparing an initial WorkingDraft (WD01) of the Spec for our Face-to-Face meeting. (I will upload WD01 a little later today) Since going through that document is not a given, and not something I think we need to do in depth immediately, I don't want these three issues to get lost in the mountain of stuff we have to go through.


·         First, I suggest we add four new elements to give each of the predefined situation report messages their own root element.  [Timothy Grapes] The “MessageReportType” should address this need. The MessageReportType tag value MUST be one of the following:

o   Field Observation

o   Management Reporting Summary: Situation Summary

o   Management Reporting Summary: Incident Decision Support Information

o   Situation Information

o   Response Resources

o   Casualty and Illness Summary   


We already have FieldObervation so we only need SituationInformation, ResponseResourcesSummary, ManagementReportingSummary and CasualtyAndIllnessSummary. This also makes the diagrams for these situation report type messages work better because otherwise there is no element through which the message is "realized." Regardless of the UML term for it, since each message needs a root element, we have to do something to make that work. I have noted this in my "Notes" for the redundantly minded.


The second item is how we refer to the Situation Report Root element throughout the Data Dictionary. Currently we have 'SitRep "Root" element / container' and I think we should just use the actual name of the root element of the whole specification, which I suggest should be "EDXLSituationReportRoot"[Timothy Grapes]  DONE or  "EDXLSituationReportReferenceType" to use the same naming as that used in EDLX-RM either of which is both shorter and more specific and leaves less room for anyone to get confused about what we are referring to.


The third item is closely related to the second one above. I suggest that whenever we refer to an instance of a message from the spec we use a completely generic uncapitalized series of three terms: situation report message. This is also helpful whenever we want to refer to a specific kind of situation report message, for instance: "... we use textual descriptions for the situation report message type titled FieldObservation."[Timothy Grapes] Can easily edit once agreed.


I would like to avoid using "/" between any two terms if we can avoid it because it immediately invites the reader to ask "what do you really mean by that?"


Regardless, while I would prefer these items to handled as I've noted, I'm not about to be roadkill for it. We've got waaaay too much to do to get wrapped around any axles.






To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at:



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