Re: [emergency] Minutes: 2003.10.21

[Art Botterell <acb@incident.com>]

Just for clarity, there are a few points here that I take to 
represent the opinions of the Chair, but that probably shouldn't be 
mistaken in the record as findings of the TC as a whole:

>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.  I agree that criteria for tests ought 
have been agreed upon by the TC prior to asserting those tests to be 
a threshold item... but whether we would have set any different 
criteria than we actually applied is hard to know in hindsight.

Also:

>  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.  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).

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.

And:

>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.

- Art


At 7:54 PM +0000 10/21/03, emtc@nc.rr.com wrote:
>[Special Note]
>Karl Best joined our meeting today to help with questions regarding CAP....
>
>[CAP]
>* Karl clarifies that if we make any edits to teh current document 
>we must vote on it again as a CS.
>
>* Gary expressed concern that there are some schema structure issues 
>that could cause issues with some of the parsers. Question on if we 
>address now, or later? Karl lets us know that if their are 
>"substantive changes" we have to resubmit, but minor edits should 
>not be an issue. So, we can make these after the public review.
>
>* Group came to agreement that we should submit CAP now, rather than 
>performing
>any additional edits. We will use the list Walid started 
>(http://lists.oasis-open.org/archives/emergency/200310/msg00073.html). 
>Kwasi mentions that should include where the comment came from, so 
>we can even better understand the basis of the comments relative to 
>other events. Rex will send copy of format/template he has used 
>before.
>
>* Rick asks about our requirements for testing given the 2 tests 
>(internal and DC demo) ended up being a bit klunky from a process 
>perspective. Also wanted to understand/make comments on what the 
>OASIS process requires (3 members standing up saying they support 
>it) and how that plays in. Gary and Art share their thoughts on what 
>they think is required. To summarize, this is really 2 issues. One 
>is what OASIS requires - which we now understand as a group and is 
>defined in the OASIS documentation. Second is a lesson's learned 
>from the tests and more importantly the process y which the test was 
>executed. 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.
>
>[PPW Letter]
>* Now that we have made a final determination on CAP, Allen will 
>finish the draft and try to send out tonight.
>
>[Transport Requirements]
>* Rick still has not received any comments from the group. Rex asks 
>that we add VoiceXML.
>
>* Art asked for clarification on what this is. Rick talks about how 
>transmitting data applies to how things are sent around, such as 
>CAP. How you can transport things across systems.
>
>* Lots of discussion on trying to explain what this is. In a 
>nutshell, since CAP does not disclose "how" to send messages around, 
>we need to address this somehow. This could be in the form of 
>language added directly to CAP, in a separate spec, in an 
>implementation note, or other - and could either be normative or 
>non-normative.
>
>* Rick is going to take a stab at writing the requirements for the 
>committee to see and better understand.
>
>[Liaison]
>* Has sent out request to people at W3C and others.  Next steps are 
>to make as many connections (informal) as possible. Will shoot to 
>have recommendation to TC in 4 weeks.
>
>[MSG SC]
>* Discussion around best path for MSG SC going forward. Currently, 
>there are some outstanding Action Items in the SC that need to be 
>completed. We either need to  elect a new Chair, or close the SC and 
>absorb the Action Items into the TC. If anyone  is interested in 
>Chairing or nominating a Chair for this SC, please speak now. We 
>will have this point of discussion as our #1 topic for the next call.
>
>To unsubscribe from this mailing list (and be removed from the 
>roster of the OASIS TC), go to 
>http://www.oasis-open.org/apps/org/workgroup/emergency/members/leave_workgroup.php.