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


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]