RE: [emergency] Subcommittee Assignments

[Rex Brooks <rexb@starbourne.com>]

Thanks, Patti,

I concur for the most part, with quibbles of course. I think the rest 
of the committee needs to absorb the Requirements Supplement which I 
just went on and on and... etc, about. Yup, we thought about these 
very issues, but it is best that folks arm themselves with the facts 
which are there in the red lined version you can download. Y'all can 
ask those of us who attended the f2f more about what we discussed in 
detail.

I look forward to Tuesday's meeting. I should be in better shape for 
actually discussing things by voice by then, but if I'm not please 
don't misconstrue any apparent lack of my usual participation with 
consent. I'm just being post-pneumonia careful.

My first night out of the hospital was very instructive. I may just 
have to wait till the chair asks for final comments before a vote to 
speak up to avoid treating us all to an awful-sounding coughing fit 
every time I try to speak. It's at the point of sounding worse than 
it is, thanks be.

Ciao,
Rex

At 9:38 AM -0600 11/4/05, Aymond, Patti wrote:
>Renata brings up a good point that we need to consider. At the 
>face-to-face, we learned that the premier requirement for the RM is 
>that the RM be embedded in a DE because it is dependent on some of 
>the DE information. What happens when payloads are carved up and 
>forwarded to different recipients? The information from the DE is 
>lost.
>
>I suggest that all of the standards (CAP, DE, RM, ...) be autonomous 
>- fully containing all of the information that it needs even if it 
>means having redundant information in the DE and the payloads. The 
>DE should be sufficiently robust to handle any type of payload, CAP 
>should be a complete A&N message, and a RM message should contain 
>all of the information needed to manage resource procurement, 
>stockpiling, prepositioning, deployment, tracking, and disposition.
>
>As far as the speed of progress. I agree that it would be great to 
>take our time and produce a standard that is "right", but given the 
>gaping hole in EM capability and the devastating consequences it can 
>have, I think we're right in taking the heuristic approach. We may 
>not produce an optimal solution, but it will be good enough to be 
>useful, and with each iteration, we will get closer to the "right" 
>standard.
>
>O.K. I'll step down off of my soapbox now...
>
>Patti
>
>
>From: Renato Iannella [mailto:renato@nicta.com.au]
>Sent: Thu 11/3/2005 8:52 PM
>To: Emergency_Mgt_TC TC
>Subject: Re: [emergency] Subcommittee Assignments
>
>
>
>On 4 Nov 2005, at 03:52, Elysa Jones wrote:
>
>>  1.  Infrastructure SC - The DE has now completed the comment period 
>>  and we reviewed an overview of the comments received.  Mary 
>>  provided a URL to the comment list.  Art is putting together the 
>>  spread sheet with all comments for consideration.  As Mary stated 
>>  on the call, for the EDXL DE 1.0 to be voted on this calendar year, 
>>  it will have to be approved by the TC to go forward no later than 
>>  Nov 7.  I would like for the IF-SC to work diligently over the next 
>>  few days to provide a recommendation to the TC as to the dispense 
>>  of these comments.  I will call a special meeting of the TC on 
>>  Tuesday Nov 7 from 11-12 EST for the IF-SC to make their 
>>  recommendations.  Provided we have a quorum and can agree to the IF-
>>  SC dispense, we could vote at that meeting to go forward with a ballot
>
>My concern is that we seem to be pushing thru EDXL-DE when we have no 
>experience on
>how (or if) the work we now commence on EDXL-RM will impact on it.
>
>This was the case for CAP and EDXL - changes proposed in EDXL were 
>rejected because
>CAP did things in certain ways.
>
>I am concerned the same will now happen with EDXL-RM - since its 
>dependency on EDXL-DE is high.
>
>I suggest the EDXL-DE stay at committee draft for a longer period 
>until we are more clear
>on the technical integration with EDXL-RM. This would be the best 
>outcome for the community we represent.
>
>
>>  2.  Messaging SC - Now that the requirements for Resource has been 
>>  through the review, I would like to see the messaging SC take over 
>>  that work.
>
>Where are these Requirements? Were these discussed at the last f2f?
>
>
>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.
>
>---------------------------------------------------------------------
>To unsubscribe from this mail list, you must leave the OASIS TC that
>generates this mail.  You may a link to this group and all your TCs in OASIS
>at:
><https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups..php
>
>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


-- 
Rex Brooks
President, CEO
Starbourne Communications Design
GeoAddress: 1361-A Addison
Berkeley, CA 94702
Tel: 510-849-2309