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] RM elements - Ross/Jon Skeels

Title: Re: [emergency-msg] RM elements - Ross/Jon Skeels
I'm comfortable with ContactInfo structure as we have it now as long as we add an element that indicates what role the contact has in the resource procurement process.
I'm more interested in grouping elements together based on what role provides them. I think having resource producer elements grouped together, resource distributor elements grouped together, resource owner elements grouped together... etc. would clarify what elements are appropriate for what message type. For example, elements associated with resource owner would never be used for a "Request Resource" message.

From: Rex Brooks [mailto:rexb@starbourne.com]
Sent: Mon 8/28/2006 8:49 AM
To: Renato Iannella; Aymond, Patti; Tim Grapes
Cc: Emergency_Mgt_Msg_SC
Subject: Re: [emergency-msg] RM elements - Ross/Jon Skeels


Perhaps we should place ResourceConsumers, ResourceDistributors and
ResourceOwners into their own category: ResourceActors?

That way they are grouped together and the distinctions between and
amongst them such as that between Owner and Distributor can be made
clear in relation to the others.


At 2:57 PM +1000 8/28/06, Renato Iannella wrote:
>On 26 Aug 2006, at 02:24, Aymond, Patti wrote:
>>Looking at this I realize that we don't have elements that identify
>>the requestor and the provider. I think we need to add that
>>distinction. I see the general "ContactInfo" as contact information
>>relating to the sender of the message, which may not be the
>>requestor of the resource or the provider of the resource. One
>>thought is to add a "ContactType" element in "ContactInfo" that can
>>have the values "MessageSender", "Resource Requester", or
>>"ResourceProvider" - or something like that.
>We should define two roles within the RM structures.
>1 - Resource Consumers - those that request and need resources
>2 - Resource Distributors - those that have resources, or have
>access to them, or manage them for others, and can provide/dispatch
>resources (to Resource Consumers)
>My assumption has been that the ContactInformation is always the
>sender of the resource message, and hence in some cases
>it is the RC and others the RD - those distinction simply depends on
>the message type.
>So the question is:  Do we need more roles than these two?
>For example, do we need a "Resource Owner" who maybe different than
>the RD - for example: Owning/HomeDispatch/HomeUnit
>If yes, then we need some Ref Model changes.
>If no, then we don't need this info - we assume that the RD is
>responsible for all aspects of the Resource management.
>(In this case, if the HomeDispatch is "Collins Dispatch Center" then
>this would only appear in one of the arrival/departure Locations
>elements, as this is the important bit of information...)
>I think the important design-philosophy is that we are not trying to
>replicate an entire back-end resource management/logistics system,
>but the interoperability between resource consumer/distributor.
>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.

Rex Brooks
President, CEO
Starbourne Communications Design
GeoAddress: 1361-A Addison
Berkeley, CA 94702
Tel: 510-849-2309


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