OASIS Emergency Management TC

 View Only

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

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

    Posted 10-09-2003 01:11
     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


    On Wed, 2003-10-08 at 18:36, Art Botterell wrote:
    > 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).
    
    Keep in mind that getting what you ask for also means you get things you
    didn't plan for.
    
    As a reminder, the problem with adding this is that it breaks other
    things - it breaks things from the majority of our members building
    applications. Note that I am not saying apps crash - I am saying
    business processes no longer work, and the mediums across which we
    exchange data may not be able to handle these just by "adding a single
    optional element."
    
    For instance, you say it is optional - but what if it is not? What if
    the image itself is the payload carrying the "intent"? What then? It
    means that a CAP supporting app, which supporting the schema/spec,
    fails. It means that assets or lives could be lost, because what was in
    that photo (say a mug shot of a murder) was the only important data. And
    this doesn't even begin to address the infrastructure issues, which we
    have not fully assessed.
    
    And what if the inline attachment is 1MB in size? Or maybe 1GB or a
    terrabyte? My point isn't of what is extreme or not, but that much like
    legal documents, standards have to think about how to handle, and
    therefore address these kinds of things. Additional language,
    potentially elements or attributes, and certainly tests have to be
    performed to ensure what we say works. Nothing is "little".
    
    Anyway, I am confused why this is being brought up again, because the TC
    agreed on this back at the mini-f2f. I even mentioned that the need
    could be addressed by including the image in the same envelope, as in
    SOAP, and the URI being relative. When stated I was told "that will
    work". What changed?
    
    > 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.
    
    You know, this entire statement is not only unfair to the work of the
    whole TC, but inappropriate. I am ashamed to even see that in our list.
    The team here has worked incredible hard, including you, to create a
    standard that applies to the industries and organizations we represent.
    We have brought together a diverse group of people, experience, and
    minds to do the best we can. We have put faith, blood, and tears into
    the democratic process at OASIS, and we have voted on issues as a whole
    that impacted our efforts. Even during trying times we have stuck it
    out, come together, and progressed. To even imply, let alone state, that
    somehow exercising some patience with how to address broadcast media in
    the best possible, and least damaging way is a failure....well, I
    wholeheartedly disagree.
    
    > - 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
    > >
    > >