Re: [emergency] Minutes: 2003.10.21

["R. Allen Wyke" <emtc@nc.rr.com>]

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