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: Conference line to help move RM forward


The subcommittee has discussed the need not only for a F to F to move RM
forward, but in the short run to schedule a couple of special conference
calls (2-3 hours in duration) to focus on review of the detailed artifacts.

Chip Hines has agreed to provide the DM conference line to support this.  

Rex, I would like to touch base on the phone with you Monday to discuss and
recommend some dates to the group.


Tim Grapes
Evolution Technologies, Inc.
Disaster Management egov Initiative
Science and Technology Directorate/OIC
Department of Homeland Security
Office:  (703) 654-6075
Mobile:  (703) 304-4829
-----Original Message-----
From: Tim Grapes [mailto:tgrapes@evotecinc.com] 
Sent: Friday, August 04, 2006 10:17 AM
To: 'Rex Brooks'; 'Renato Iannella'; 'Patti Aymond'
Cc: 'Emergency_Mgt_Msg_SC'
Subject: Help to move RM forward


I agree that we need to slice out 2-3 hour meetings in order to move this

I sent a message to Chip Hines to ask permission to use the DM conference
line to support a couple of good long calls.  I suspect he'll support that -
will let you know.



-----Original Message-----
From: Rex Brooks [mailto:rexb@starbourne.com] 
Sent: Thursday, August 03, 2006 11:52 PM
To: Renato Iannella; Rex Brooks; Patti Aymond; Tim Grapes
Cc: Emergency_Mgt_Msg_SC; Karen Robinson
Subject: Re: Minutes for Monday's Meeting

I replied, but neglected to hit the "reply to all", so please excuse 
the duplication, Renato:

Yup. Thanks, Renato,

It would really be fantastic if we had a sponsor for a multi-hour 
telecon so we could really work through a number of these since it 
seems like we only getting started when we have to rein in to keep 
from going more than a half hour beyond our scheduled time. I suspect 
that a two and half hour session would see us get up to speed at 
about 45 minutes and start slowing down at two hours. However, that 
is going to rack up much too large a single long distance charge for 


At 10:27 AM +1000 8/4/06, Renato Iannella wrote:
>[NOTE: It still looks like the OASIS email servers is down, as these 
>messages are not appearing in the archive]
>>2.3 We made a major change in the element RequestAcceptDecline, 
>>which will be reflected in the DOM. RequestAcceptDecline is being 
>>renamed Response and DeclineReason is being renamed ResponseReason. 
>>These two elements are being placed into a new subelement of 
>>ResourceInfo named RequestResponse. The enumerated list of values 
>>for Response has expanded to include "Conditional" in addition to 
>>the previously defined values "Accept" and "Decline". If Response 
>>has a value of "Conditional", then "ResponseReason" is mandatory. 
>>If Response has a value of "Accept" or "Decline" then 
>>"ResponseReason" is optional.
>A nicer way to represent this is within the "RequestResponse" there 
>is one, and only one of:
>  - Accept
>  - Decline
>  - Conditional
>The latter contains a string indicating what the conditions are.
>>2.4 We made another major change which will be reflected in the DOM 
>>in the elements in ResourceInfo related to schedule, These are 
>>being collected together into a new subelement named 
>>ResourceSchedule. These elements include RequestedArrivalDateTime, 
>>AnticipatedReturnDateTime, AvailableDateTime, ComittedDateTime, 
>>EstimatedDepartureDateTime, ActualDepartureDateTime, 
>>EstimatedArrivalDateTime, and ActualDateTime.
>Again, a nicer way to represent this is to say that there is a 
>Schedule (of dates) and a Role that applies to those dates.
>This will allow for more roles latter - instead of an never ending 
>list of fooDateTime elements.
>>2.5 Elements needed by the firefighting community related to 
>>resource ownership are being added in a subelement of ResourceInfo 
>>named OwnerInfo. This element will contain the elements Owner, 
>>HomeDispatch, and HomeUnit. All three of these elements are 
>>Optional for the three message types that the SC has reviewed.
>It would be good if we could generalise these. Can someone give an example?
>>3 We had neither the time nor a sample message schema to review. It 
>>is also, given the depth of the discussions we find necessary, 
>>unlikely now that we will conclude the work necessary to produce 
>>the next full working draft of the specification before the end of 
>>August, unless the issues we uncover begin to decrease after we 
>>take decisions such as those necessitated in this discussion.
>We have examples instances in the "Information Model" document.
>But it is pretty clear that as we look into the detail, the devil is 
>showing ;-)
>Cheers...  Renato Iannella
>National ICT Australia (NICTA)
>This email and any attachments may be confidential. They may contain
>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

No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.10.5/407 - Release Date: 8/3/2006

No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.10.5/407 - Release Date: 8/3/2006

No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.10.5/407 - Release Date: 8/3/2006

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