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] 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]