OASIS Emergency Management TC

Re: [emergency] Re: [emergency-comment] PPW letter re CAP

  • 1.  Re: [emergency] Re: [emergency-comment] PPW letter re CAP

    Posted 10-08-2003 22:35
     MHonArc v2.5.0b2 -->
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    

    emergency message

    [Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


    Subject: Re: [emergency] Re: [emergency-comment] PPW letter re CAP


    Carl -
    
    We aren't talking about something that needs to cause a delay... this 
    could be resolved very quickly by adding a single optional element to 
    the spec, with requisite caveats and restrictions set forth in its 
    definition.  The mechanism involved has already been tested and 
    proven in a number of XML applications, and implementation could even 
    be defined as optional for most implementers (those not contemplating 
    connections via one-way data links).
    
    And I should remind us all that we aren't talking about an 
    enhancement here... we're only talking about meeting our own stated 
    requirements.
    
    This is a question of balancing the real, explicitly stated needs of 
    a significant stakeholder community against speculative hazards... 
    hazards that generally haven't materialized in other applications of 
    the same method, and ones that in any event are easily mitigated with 
    a few lines of specification text.
    
    Regardless of how we might spin it, if we don't provide a solution 
    that responds to users' stated needs I'm hearing from PPW member 
    companies and others that market forces will require them to stop 
    waiting for CAP and devise their own solutions in the very near 
    future.  That would be a profoundly regrettable failure of the 
    standards process, especially since it's so easily avoidable.
    
    - Art
    
    
    At 2:59 PM -0600 10/8/03, Carl Reed wrote:
    >Art -
    >
    >We run into these issues all the time in our specification process at the
    >OGC. It is impossible to satisfy every requirement for every application in
    >every industry. There is an interesting balance between getting a spec out
    >for use and getting one out that is also useful! I think the old 80/20 rule
    >applies.
    >
    >Anyway, perhaps a more positive way to position the CAP spec is to say that
    >this is version 1 (one) and that future (new) requirements and change
    >proposals will be considered and incorporated. This is the way we deal with
    >the enhancement issue at the OGC. We accept change proposals, instantiate a
    >spec Revision Working Group, work the suggested changes, and then put the
    >modified spec up for member vote and adoption. Some of our specs have
    >already gone through 5 or 6 revisions in 2 years. This does raise an issue
    >of backwards compatibility and deprecation. But how is this different from
    >any vibrant piece of technologies life cycle management?
    >
    >Cheers
    >
    >Carl
    >
    >