[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [emergency-msg] Groups - EDXL-RM Information Model (EDXL-RM-Info-Model-2006-07-26.pdf) uploaded
Renato, I appreciate you taking on this task. Organizing the message types in this way has helped me clarify my thinking on what makes different message types unique. I have a few comments/suggestions that are detailed below. Page 1 Paragraph 1 Since we are still working through the matrix, some of this may need to be reworked, but it helps even in this draft from. Page 1 Paragraph 3 Your SimpleResponseMessage concept has me thinking. Maybe we don't need a different response message type for every type of message sent. Maybe we simply need a Message Response message type that has a Response element that can be either "Acknowledge", "Accept", "Decline", or "Conditional". We haven't dealt with a conditional response, but I think we need to give that as an option. If, for example, the Message Response message has a Response value of "Accept" and the OriginalMessageID is for a Request For Information message type, then the message would include the information requested. I think we would need to add an element OriginalMessageType as well to ensure unambiguous interpretation of message responses. Anyway, that's just a thought that can be discussed. I think Update, Cancel, and NotifyAuxiliaryRecipients message types needs to be included to minimize data integrity errors. Keep in mind that we cannot assume that the messages will be within an EDXL-DE message. Page 1 Paragraph 5 Keep in mind that there are schedules for more than one entity: Producers Anticipated time/location (when I need it and where I need it) Producers Actual time/location (when I got it and where I got it) Consumers Anticipated time/location (when I can send it and where I can send it from) Consumers Actual time/location (when I sent it and where I sent it from) Page 2 Figure 1 The element Contact should be ContactInformation, although I do like the name Contact better. We should discuss changing this. Also, it is optional - not required. The ContactInformation element, when present, must contain the sub-element Role. All of the other sub-elements are optional. In the DOM, we do not have FundingCode and FundingInfo elements within a Funding element, but I like this idea. In the DOM, we have FundCode with a multiplicity of [0..*], and we have FundingInfo [0..1]. Should these be consistent? Again, other areas for SC discussion. The resource element is not consistent with the DOM. We need to keep the structure consistent. Page 3 Paragraph 4 I agree that if the message is Cancel, Acknowledge or Decline, then the Resource element shouldn't be necessary. Page 3 Paragraph 5 I like this hierarchy, but I think the CommittedRM/UncommittedRM types need some clarification. I'm not sure from this document exactly how they work. Page 9 Paragraph 3 This is consistent with my comment on Page 1 Paragraph 3. I think we should eliminate redundant information from the message responses. Thanks for putting these together for us!! Patti Patti Iles Aymond, PhD Senior Scientist, Research & Development Innovative Emergency Management, Inc. Managing Risk in a Complex World 8555 United Plaza Blvd. Suite 100 Baton Rouge, LA 70809 (225) 952-8228 (phone) (225) 952-8122 (fax) -----Original Message----- From: renato@nicta.com.au [mailto:renato@nicta.com.au] Sent: Wednesday, July 26, 2006 1:24 AM To: emergency-msg@lists.oasis-open.org Subject: [emergency-msg] Groups - EDXL-RM Information Model (EDXL-RM-Info-Model-2006-07-26.pdf) uploaded Dear all - we have worked more on the information model for EDXL-RM and now seems a good time to release it and get some more comments and feedback. The model tries to articulate the resource message structure and relationships between the resources, types of messages, and schedule information for tracking. The document is not yet complete as we still need to drill down on all the message types and document this clearly. We have also added some example XML instances that we discussed from last week's teleconference. We can discuss some of the details at this week's teleconf. Renato & Karen -- Dr. Renato Iannella The document revision named EDXL-RM Information Model (EDXL-RM-Info-Model-2006-07-26.pdf) has been submitted by Dr. Renato Iannella to the EM Messages and Notification SC document repository. This document is revision #1 of edxl-rm-model-discuss-01.pdf. Document Description: This is a discussion document on the information model for EDXL-RM View Document Details: http://www.oasis-open.org/apps/org/workgroup/emergency-msg/document.php? document_id=19357 Download Document: http://www.oasis-open.org/apps/org/workgroup/emergency-msg/download.php/ 19357/EDXL-RM-Info-Model-2006-07-26.pdf Revision: This document is revision #1 of edxl-rm-model-discuss-01.pdf. The document details page referenced above will show the complete revision history. PLEASE NOTE: If the above links do not work for you, your email application may be breaking the link into two pieces. You may be able to copy and paste the entire link address into the address field of your web browser. -OASIS Open Administration IEM CONFIDENTIAL INFORMATION PLEASE READ OUR NOTICE: http://www.ieminc.com/e_mail_confidentiality_notice.html
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]