[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [emergency-msg] Minutes for Mtg 08-24-06
Rex, I noticed that the decision to create some example messages before proceeding to develop the XML schemas was not captured in the minutes of the last teleconference. Renato and I already created an example "Request Resource" and "Response to Request Resource", but they were based on the hybrid information model we developed, not the current DOM/RMRM: http://www.oasis-open.org/apps/org/workgroup/emergency-msg/document.php? document_id=19605 We put a fair bit of thought into how to accept a subset of a request and conditionally accept or decline other parts. This is why we incorporated an "id" for resource requests and an "idref" for responses in our hybrid model. The ids make it possible to identify which parts of the request are being accepted/declined/conditionally accepted, without having to repeat the entire resource description from the original request. It should be helpful to look at these request/response examples now, however I think we also need to keep going with the water truck example we discussed in the meeting. I suggest that we first deal with a simple example where we request potable and non-potable water trucks as discussed in the meeting, and get back a partial accept, partial decline (perhaps only the non-potable water trucks can be supplied). Later we could look at Rex's more complex use case where resources are deployed at different times and a truck breaks down (assuming we decide to tackle such complex use cases). Karen. -----Original Message----- From: Rex Brooks [mailto:email@example.com] Sent: Saturday, 26 August 2006 12:52 AM To: firstname.lastname@example.org Subject: [emergency-msg] Minutes for Mtg 08-24-06 Hi Everyone, Here are the Minutes of our last meeting, Please see PLEASE NOTE: below. EM-Msg Meeting August 24, 2006 Minutes Roll: Voting Members: Rex Brooks, Tim Grapes, PattiAymond, Karen Anderson, Tom Merkle We had a quorum, and the minutes for the previous meeting were accepted. Agenda: 1 We accepted the Meeting Notes from the previous meeting. 2 We reviewed the ExampleMsgSemantics document Renato submitted and the list of Standard Resource Messages Patti included in the last update of the specification document. We decided to combine the formats in a sample for a single MessageType so that a listing for the first message would begin as Section 3.2.1 Resource Request and be followed by 188.8.131.52. Overview and Description combining Renato's overview text and the descriptive text Patti assembled in the last version of the specification. This would be followed by 184.108.40.206 Table of Message Elements as Renato developed, with the addition of a fifth column for the EDXL_DE Distribution Type associated with the MessageType from Patti's listing. This will incude the numbered Rules as shown in Renato's example. This will be followed by 220.127.116.11.Message Flow per Renato's sample. This will be followed by 18.104.22.168. Resource Request DOM/Reference Model (the name for which remains to be settled: see 3). We did not make a final decision on whether this model will be carried over for the final draft specification because we want to see how useful it will be and how we might divide up the total number of specification components for each MessageType, which is expanded considerably in this sample. We also asked that an example .xsd XML Schema file be included in this first full sample for a specific Message Type. We did not decide that it should be included here or simply included with the other Message Schemata in a single complete .xsd for the entire specification, or if we should include each schema separately. This set of work was handed off to Karen to work with Renato for the next meeting in two weeks (which as of now, would be scheduled to follow the TC meeting at 12:30 p.m. ET (US). PLEASE NOTE: We should probably reschedule this for another Thursday Afternoon session rather than ask Renato and Karen to attend a meeting at 2:30 a.m. ET Australian time. It should also be noted that the updating of the specification (not required for the next meeting) has now been handed off to Renato. We expressed our gratitutde to Karen to extend to Renato for taking on this set of tasks. 3 Lastly, we discussed changing the name of the DOM to something like Reference Model and making it clearly understood that it is not intended to be used for generating program code, even though it could be translated into formal UML 2.0 and used that way. We tabled the discussion with the understanding that we need to double check that there is no OASIS requirement or mandate for including a DOM per se. No one seems to think that there is, but we want to be certain. The meeting adjourned. -- Rex Brooks President, CEO Starbourne Communications Design GeoAddress: 1361-A Addison Berkeley, CA 94702 Tel: 510-849-2309 -------------------------------------------------------------------------- This email and any attachments may be confidential. They may contain legally privileged information or copyright material. You should not read, copy, use or disclose them without authorisation. If you are not an intended recipient, please contact us at once by return email and then delete both messages. We do not accept liability in connection with computer virus, data corruption, delay, interruption, unauthorised access or unauthorised amendment. This notice should not be removed.