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
