[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [emergency] Subcommittee Assignments
Yup. I think what we are recognizing here is the rather daunting need to maintain a process of Continuous Improvement. Naturally, we always want to do our best, but my personal experience, and, indeed, the genesis of the EDXL framework in the first place, shows that often our mistakes or errors or fits and starts turn up the most valuable lessons. So, I think we do ourselves a service by allowing for moving through these processes of: learning from practice (documenting issues in process); evaluating issues for commonality; abstracting principles from this learning and evaluating, applying those principles (v.1 -> v.x); and returning to learning from practice. The difficulty, of course, is that this requires a different attitude from "Let's just get this done and move on to the next thing." It is a more fundamental attitude that looks at just about everything as an on-going work in progress. That's what makes it daunting as a neverending task, but it is also liberating because it allows us to accept that we may have to revisit this or that issue again. Of course, it will always be better to get these initial framework structures as general, effective and adaptable as we can so that we don't have to revisit the basics, though I think we need to be flexible enough to do that, too, if needed. Ciao, Rex At 12:18 AM -0500 11/5/05, Art Botterell wrote: >Yes, I think this is a key point... the EM TC is not a closed >system. Formalization is just one stage in a spiral development >process. No matter how clever we try to be, we're bound to learn >things from experience. And we want to stay open to that, which >means not taking any of our notions too seriously until they've been >proven in practice. > >I also think Patti points out an important consideration as regards >dependencies. Personally I've always been a bit "iffy" on whether >the DE should be an encapsulating structure (a "wrapper") or a >standardized included structure (an "element") for use within >various functional message types. Or maybe both. > >This is one of those things I don't think we're really in a position >to judge yet, since it depends on network architectures and >application frameworks that are themselves still evolving. As >usual, my personal preference would be to keep our options as open >as possible for as long as possible. > >That does leave a lot of wiggle room within the specs, which in turn >means that some details may need to be negotiated as usage profiles >among the implementers and then formalized once "best practice" >becomes clear... but I think that's probably better than locking >ourselves in prematurely to unproven assumptions. > >Generally speaking, I think every creative act requires a certain >quota of mistakes, and thus the faster we can make and recognize >mistakes, the quicker we'll get to a quality product. Trying never >to make any mistakes is, in my experience, the one sure way to >stifle creativity. If we can just avoid any truly fundamental >mistakes on the first go-round, that's probably a good job of work. > >- Art > > >On Nov 4, 2005, at 11:45 AM, Ham, Gary A wrote: > >>Perfection is the enemy of "good enough." Lets just make sure that >>it is truly good enough. >> >>Gary A. Ham >>Senior Research Scientist >>Battelle Memorial Institute >>540-288-5611 (office) >>703-869-6241 (cell) >>"You would be surprised what you can accomplish when you do not >>care who gets the credit." - Harry S. Truman >> >> >> >>From: Aymond, Patti [mailto:Patti.Aymond@ieminc.com] >>Sent: Friday, November 04, 2005 10:38 AM >>To: Renato Iannella; Emergency_Mgt_TC TC >>Subject: RE: [emergency] Subcommittee Assignments >> >>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 >> >> >>IEM CONFIDENTIAL INFORMATION PLEASE READ OUR NOTICE: >>http://www.ieminc.com/e_mail_confidentiality_notice.html > > >--------------------------------------------------------------------- >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 -- 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]