[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [emergency-msg] RM elements - Ross/Jon Skeels
Just so you know, I was already getting push-back on this, and I was trying to avoid several more complex issues (and headaches I've gone cross-eyed over in WSRP TC), when I suggested "StatusOf" to give a clear reference to the exact previous message being referenced, with a new value of "Pending." The use case is: Resource Request comes in for 5 water trucks. Response comes back with "We can supply two now, three possibly later." Requisition comes in for 5 water trucks. Five are committed. Two are shipped immediately." Four days later the original requester sends RFI: "Status of three remaining water trucks from Requisition 20060828AlamedaCA94702-1706?" Situation: One truck had a breakdown returning to homebase before redistribution order arrived. It is waiting for a replacement part between last deployment and homebase. Two trucks returned to homebase for quick maintenance check, fluid top offs, etc, but another emergency has arisen with a closer neighboring jurisdiction with whom the homebase has a common reciprocal mutual aid logistics agreement. A decision hasn't been made yet because those in authority are very busy. The mutual aid agreement requires at least one truck, but could use and would requisition two if it could, while the status of the third is that it is intransit at a garage in a neighboring disrict and has no idea when the part will arrive because it is back ordered. According to the EDXL_DE, I would make the distributionType Report, not Ack, Update, or Cancel.since I think of Updates as definitive changes in the situation. I wouldn't consider lack of a decision to be an Update. Also, I would guess that this set of statuses would have to be covered in the MessageDescription, That's not something I like, but could live with, still only one of the water trucks has a definite status: Delayed (one we might want to add along with Pending). Remember, a decision has not yet been made, and there will be lawyers from insurance companies involved on all sides. This totally ignores issues such as caching, non-repudiation, latency in the system, and does not allow for automatic messaging when state changes are reported. I leave all that out because we are dealing with v1.0 and we need to stay with the simplest cases, but I bet status is going to be kicked back into our laps if we don't make allowance for the above use case, since we know we are going to see it, especially when in conjunction with cascading infrastructure failures with power outages, spotty onsite generators for back-up power, etc. I guess the question is: Is this kind of use case important enough for us to allow for it? Cheers, Rex At 2:41 PM +1000 8/28/06, Renato Iannella wrote: >On 26 Aug 2006, at 02:24, Aymond, Patti wrote: > >>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. >> > >I totally agree with Patti - I think we cover the necessary status >with our current message structures. > >Adding another status will definitely confuse. > >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]