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


Hi Everyone,

I agree for the most part with Patti. However, I think the issue of 
"Status" still hasn't resonated with me beyond the ROSS system, where 
it makes sense in the system context Patti mentions. I'm still 
thinking that what is intended across the spectrum of messages hasn't 
been well defined, but I'm not sure there isn't a need for a 'status' 
directly related to a specific previous message, like the various 
"response to..." messages, where values such as those in ROSS below, 
might be needed or helpful.

Obviously, status would not apply to the "request..." messages, and 
Acknowledge, Update and Cancel are taken care of by the DE. However, 
that begs another question.

Might this not be where the specific responses intended in 
"acknowledge, update, cancel" from the face to face in SF might serve 
a necessary purpose?

We might need to add a "StatusOf" field that takes a MessageID within 
Status as well as a value. For values, I think Pending (as in 
'pending decision'), Scheduled (see schedule for more info), Sent 
(for RFIs and RFQs, DeploymentStatus, ExtendedDeployment) and Filled 
(see schedule for more info) provide the info that other elements 
don't.

It could be argued that other elements either cover the information 
explicitly or implicitly, but I don't think it would overburden 
processing and might be helpful.

My thinking here is that one thing I would do in building an 
application to use this standard is to provide a quick digest of the 
message that can be read quickly to discover if the status of a 
requested resource is pending. This is the most problematic, and 
allows the recipient to immediately inquire further if the need is 
great or increasing, or other sources need to be contacted. As of now 
we have Scheduled and Filled or Sent covered, and a digest can be 
built from existing values by inference, i.e. if there is an 
EstimatedDepartureDateTime, then it is Scheduled and if there is an 
ActualDepartureDateTime, then it is Filled, and if there is a 
SentDateTime, it was Sent, but we don't have Pending covered,

Cheers,
Rex

At 11:24 AM -0500 8/25/06, Aymond, Patti wrote:
>Tim,
>
>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.
>
>It sounds to me like "Resource Message" "Status" is system 
>functionality not message content. I think the other elements in the 
>message provide sufficient information for any resource management 
>system to provide the status functionality by tracking resource 
>messages.
>
>Patti
>
>
>From: Tim Grapes [mailto:tgrapes@evotecinc.com]
>Sent: Fri 8/25/2006 9:49 AM
>To: Emergency_Mgt_Msg_SC
>Subject: [emergency-msg] RM elements - Ross/Jon Skeels
>
>All,
>I completed some research on the 4 "OwnerInfo" elements in the RM 
>design.  The background information below is presented from the 
>Wildland Fire / ROSS system perspective. 
>
>It appears that all 4 elements are "organization" information.  I 
>recommend that "Owner" and "OwningJurisdiction" be combined into one 
>element as they represent the same thing.  "HomeDispatch" and 
>"HomeUnit are distinct enough to keep.  Documentation frequently 
>uses the term "dispatch unit" generically.
>
>"Owner" / "OwningJurisdiction"
>Resource Owner Organization.  The organization (government or 
>private) who owns the resource.
>
>HomeDispatch
>Resource Home Dispatch Name - The description used to identify the 
>dispatch unit that has primary responsibility for maintaining 
>information on the resource (e.g., Ft. Collins Dispatch Center, 
>Rocky Mountain Area Coordination Center).  The HomeDispatch fills 
>Requests for Resource
>(although it's not totally clear, this element also appears to be 
>organization info)
>
>HomeUnit
>Resource Home Unit - The description used to identify the office, 
>district, etc. (organization), where the resource typically works 
>out of (e.g., Manti-Lasal National Forest/Sanpete District).
>*          e.g. When released from the detail assignment, the 
>resource's  "release-to location" will be the location designated by 
>the resource's home unit.
>*          E.g. Status of "Released" - The assigned resource has 
>departed the event and has been released to the home unit or 
>reassigned unit.
>
>OTHER RELATED INFO - FYI
>
>Organization:  A company, office, or agency referenced in ROSS. 
>Includes government and private organizations.
>*          Organization has:
>*          Unit Identifier Code              (State Code + 4-Letter Unit ID)
>*          Organization Name  (e.g. Boise National Forest,
>*          Organization Location          (City, State)
>*          Organization Contact Info    (Address, Phone, Email, FAX, etc.)
>*          Organization Type   (Federal, State, Private)
>*          Organization Administrative Affiliations
>*          Organization data includes Agency and Unit Name.
>
>Dispatch Organization 
>*          The dispatch office responsible for obtaining resources 
>to support the incident/project.
>*          Dispatch Organization   (Who has resource ordering responsibility)
>*           Requestor        The originating dispatch office
>*           Provider           The dispatch office with whom the 
>request is placed and/or assigns the resource.
>
>---------------------------------------
>On the side in reference to our "ResourceMessage" "Status" - this is how
>Request Status - A description of the current state of a request.
>*          Open    Request has been logged; no action has been taken.
>*          Pending            Request has been reviewed by the 
>decision maker and some activity has occurred.
>*          Cancelled          The request has been cancelled by the 
>requestor prior to assignment.
>*          Selected           A resource has been selected to fill 
>the request, but has not departed.
>*          Filled-Closed     A request has been filled with a supply 
>item that does not require further tracking.
>*          Filled    A resource has been dispatched to fill the 
>request and request will remain active until
>             the resource has been released.
>*          Released          The assigned resource has departed the 
>event and has been released to the home
>             unit or reassigned unit.
>*          Unable to Fill     The request was not filled due to lack 
>of resources based on availability or
>             management priorities.  Final disposition; request is 
>considered "closed".
>
>Request Status - Selected vs. Filled
>*          When a resource is selected to fill a request, the 
>Request Status is set to "Selected".  The request status is changed 
>to "Filled" when the resource departs for the assignment.
>*          Once Request Status is "Filled", the resource is 
>considered "committed" to the incident and must be released before 
>being selected for another assignment.
>*          This feature allows the resource to be shown on an 
>availability list in cases where the reporting date of the first 
>request is in the future and a second request's ending dates are 
>prior to that reporting date.
>
>Tim Grapes
>Evolution Technologies, Inc.
>Department of Homeland Security
>Science and Technology Directorate/OIC
>Disaster Management egov Initiative
>Office:  (703) 654-6075
>Mobile:  (703) 304-4829
><mailto:tgrapes@evotecinc.com>tgrapes@evotecinc.com
><mailto:tim.grapes@associates.dhs.gov>tim.grapes@associates.dhs.gov
>
>IEM CONFIDENTIAL INFORMATION PLEASE READ OUR NOTICE:
><http://www.ieminc.com/e_mail_confidentiality_notice.html>http://www.ieminc.com/e_mail_confidentiality_notice.html
>
>--
>No virus found in this outgoing message.
>Checked by AVG Free Edition.
>Version: 7.1.405 / Virus Database: 268.11.6/427 - Release Date: 8/24/2006


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