OASIS Emergency Management TC

Re: [emergency] Minutes: 2003.10.21

  • 1.  Re: [emergency] Minutes: 2003.10.21

    Posted 10-21-2003 23:48
     MHonArc v2.5.0b2 -->
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    

    emergency message

    [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]