[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [emergency] Minutes: 2003.10.21
I apologize for the confusion Art. I *guess* your intent is to propose some clarification on the what the minutes were attempting to capture. The edits are inline... On Tue, 2003-10-21 at 18:27, Art Botterell wrote: > >Looking back, we should have defined and completed the test before > >we a) certified CAP as a Committee Spec, and b) reached out for > >external implementation demos as soon as we did. We should have > >taken more time to ensure CAP was where it needed to be before we > >released it. > > Of course some of us think the testing process actually went pretty > well, all things considered. This comment was not intending to comment on the testing process, but rather (going forward) adhering to a process that does a better job at fostering constructive comments at a time when they can be addressed. In this case, before approval of the spec vs. after. > I agree that criteria for tests ought > have been agreed upon by the TC prior to asserting those tests to be > a threshold item... I *think* your saying that you agree we should have defined and completed the tests before voting on CAP as an Committee Spec (aka "threshold item"), which is exactly what the comment intended to state. A lesson we learned. > but whether we would have set any different > criteria than we actually applied is hard to know in hindsight. Don't think anyone would argue here. > > In a nutshell, since CAP does not disclose "how" to send messages > >around, we need to address this somehow. > > Again, that's one point of view. Unfortunately, that is not a point of view, but rather a fact that has come from the comments we have collected. The lengthy debates and discussions around how to apply CAP in one-way broadcast, Web Service, etc. environments support the need to make available some kind of guidance (normative or non-normative) to implementors. What that is, and how that is done is being worked on by the IF SC in their Transport Requirements. Its not just about technical transport requirements, but also how to apply them in the best away across our efforts (and maybe other). Any thoughts, ideas, comments, and concerned like these focused on providing details to the IF SC for incorporation. I am sure they would welcome them. > I'll restate my own belief, which > is that to associate CAP with any particular "how" would be to lose > sight of our goal of defining a data format that's independent of any > particular implementation. The CAP spec provides a set of functions > and usages (not just Alerts but also Cancellations, Updates, > Acknowledgements and Errors)... that can be used in a set of message > contexts (Test, System and Exercise in addition to Actual) and > dissemination scopes (Public, Restricted and Private). Keep in mind that these scenarios are not mutually exclusive. Providing guidance on transport does not inherently limit CAP. And based on the conversation today and in other threads, no one has proposed or even suggested an intent to do otherwise. Based on this, I would ask that we avoid going into this rat hole again, and we put our energy in addressing the actual concerns in the Transport work the IF SC is doing. > Beyond making those specified options available, trying to specify > how they are be used in any particular context risks drawing us into > implementation particulars. Such specifics ought to be addressed in > their own application domains, not as attributes of CAP. Again, this is exactly what the IF SC is helping define/take care of with the Transport Requirements. > >We either need to elect a new Chair, or close the SC and absorb the > >Action Items into the TC. > > There's a third alternative, of course, which would be to bring > certain particular Action Items back to the TC, while allowing the SC > to continue with its other activities. And a fourth, which would be > for the TC to review certain Action Items to see if they might need > to be recast in more specific terms. I am sure most all of the TC would love to hear any alternative proposals from the Chair of the SC in this regards, but at the same time it is important to point out that we should not make a habit of "bringing back" Action Items from the SC. Assuming the SC is unable to perform these tasks, for whatever the reason, we would need to understand what Action Items does the SC need help on, or would like to hand back to the TC? Which ones simply need to be recast? We talked about the compliance test suite - is that it? -- R. Allen Wyke Chair, OASIS Emergency Management Technical Committee http://www.oasis-open.org/committees/emergency
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]