Re: [emergency-msg] Groups - EDXL-RM Information Model (EDXL-RM-Info-Model-2006-07-26.pdf) uploaded

[Renato Iannella <renato@nicta.com.au>]

On 28 Jul 2006, at 05:19, Aymond, Patti wrote:

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

The reason for the "simple" message type was to make it easier to  
specify simple
messages - as they don't have much content. The other message types  
are more complex
and warranted their own entity/class.

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

The original Requirement#1 states that the RM is dependent on a  
routing mechanism
(specifically, the DE) - so I think we can assume this??
We don't want to get into routing/distribution in the RM, so we  
should leave it to the DE.

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

We think we can support this, and will make it clearer in the next  
version.
We do, however, need to define Producer/Consumer more clearer...

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

The association between Contact and Keyword is the "role" - we will  
add this...

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

We haven't shown the cardinalities on the class attributes (elements)  
yet...next version...


> The resource element is not consistent with the DOM. We need to  
> keep the
> structure consistent.

They probably will never be exact as we are creating an *Information*  
Model.
For example, Quantity is more related to the Resource, than  
ResourceInfo.

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

Yes, we will add more...

Cheers...  Renato Iannella
National ICT Australia (NICTA)



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