OASIS Emergency Management TC

 View Only

RE: [emergency] Groups - EDIT of emergency-CAPv-1.1

  • 1.  RE: [emergency] Groups - EDIT of emergency-CAPv-1.1

    Posted 03-08-2005 14:00
     MHonArc v2.5.0b2 -->
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    

    emergency message

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


    Subject: RE: [emergency] Groups - EDIT of emergency-CAPv-1.1


    I fully concur with Gary's comments. I would like to see an example of
    what Kon is suggesting. 
    
    
    Regards,
     
    Tom Merkle
     
    CapWIN:        www.capwin.org 
    Phone:        (301) 614-3720
    Cell Phone:   (240) 375-1966
    Fax:          (301) 614-0581
    e-mail:        tmerkle@capwin.org
     
    CapWIN
    6305 Ivy Lane Suite 300
    Capital Office Park
    Greenbelt, MD 20770
    
    -----Original Message-----
    From: Ham, Gary A [mailto:hamg@BATTELLE.ORG] 
    Sent: Tuesday, March 08, 2005 8:52 AM
    To: Paul Embley; Elysa Jones; Kon Wilms; Art Botterell
    Cc: emergency@lists.oasis-open.org
    Subject: RE: [emergency] Groups - EDIT of emergency-CAPv-1.1
    
    My question for Kon.  Are you suggesting lookups in the manner of the
    GJXDM?  Or are you leaving the table out of the spec altogether.  For
    me, at least, to understand the problem I need to look at you suggested
    solution as a schema snippet.  Art's approach is OK by me, but so is the
    GJXDM approach to lookups.  Art's approach has the benefit of
    straightforward accountability.  The GJXDM approach has better
    encapsulation, making maintainability and reuse more effective.  Is
    yours a third approach? If, so what does it specifically look like?
    
    Respectfully,
    
    Gary A. Ham
    Senior Research Scientist
    Battelle Memorial Institute
    540-288-5611 (office)
    703-869-6241 (cell)
    "You would be surprised what you can accomplish when you do not care who
    gets the credit." - Harry S. Truman
    
    
    -----Original Message-----
    From: Paul Embley [mailto:pembley@mstar.net] 
    Sent: Tuesday, March 08, 2005 6:59 AM
    To: 'Elysa Jones'; 'Kon Wilms'; 'Art Botterell'
    Cc: emergency@lists.oasis-open.org
    Subject: RE: [emergency] Groups - EDIT of emergency-CAPv-1.1
    
    
    The GJXDM uses quite a few lookup tables.  The biggest problem we've had
    is trying to get authoritative sources to take responsibility for them.
    An example is the FBI and the NCIC code lookups.  Only recently have
    they committed to take on this task.  Other examples are some FIPS, ISO
    and USPS tables.  We reference them externally. 
    
    Paul S. Embley
    Practitioner Resource Group
    G&H International Services, Inc.
    502.695.7733 (office)
    502.545.0127 (cell)
    502.695.0055 (fax)
    pembley@ghinternational.com
     
    
    -----Original Message-----
    From: Elysa Jones [mailto:ejones@warningsystems.com] 
    Sent: Tuesday, March 08, 2005 5:26 AM
    To: Kon Wilms; Art Botterell
    Cc: emergency@lists.oasis-open.org
    Subject: Re: [emergency] Groups - EDIT of emergency-CAPv-1.1
    
    Okay guys - truce!  Let's hear from some other implementors.  What about
    
    it?  David Ellis, Gary Ham, Rob Torchon, Tom Merkle, Paul Embley,
    Michelle 
    Raymond, Walid Ramadan, Jeff Kyser, Sukumar and you folks as IEM as a 
    minimum - what do you think???  Elysa
    
    At 10:44 PM 3/7/2005, Kon Wilms wrote:
    >On Mon, 2005-03-07 at 21:56 -0500, Art Botterell wrote:
    > > At 2:31 PM -0800 3/7/05, Kon Wilms wrote:
    > > >I've asked a number of times in this thread for clarification as to
    
    > > >why such a method would not be a good idea - all I've received has 
    > > >been
    what
    > > >seems like an unwillingness to listen.
    > >
    > > Please don't confuse not agreeing with not listening.  The TC isn't
    >
    >You don't have to agree, but you do have to give me a good answer why 
    >you think it won't work and/or is a bad idea. I have yet to see even 
    >one, even after I have listed both advantages and disadvantages to this
    
    >approach. 'Things will not interoperate' doesn't qualify as a valid 
    >answer (or excuse).
    >
    > > obliged to accept a change just because someone suggests it.  If you
    
    > > want a change, it's up to you to persuade the TC that it's a good 
    > > idea.
    >
    >This is right up there with accusing me of using this to push an 
    >implementation issue to the standards level. What's up with this?
    >
    > > >However, with a lookup table in place people like Dave would be 
    > > >able to make use of their CBRN category immediately without being 
    > > >out of spec.
    > >
    > > We aren't trying to make it easy to add new categories... in fact, 
    > > we're trying to make it hard.  Our goal is interoperability, which 
    > > wouldn't be served by letting some systems adopt random categories 
    > > that others won't understand.
    >
    >I'm constantly amazed at how the concept of lookup table usage is 
    >equated to allowing people to insert random categories into their 
    >messages and creating some sort of interop disaster. Please stop the 
    >FUD.
    >
    > > CAP isn't meant to be everything to everyone... it's meant to be the
    
    > > SAME thing to everyone.
    >
    >Same as above.
    >
    > > If Dave DIDN'T feel he needed to interoperate he could just make up 
    > > his own XML format and not bother constraining himself to the CAP 
    > > spec.  But the last thing we'd want would be messages floating 
    > > around that claimed to be CAP, but actually were non-interoperable 
    > > variants.
    >
    >Same as above.
    >
    >The theme here seems to be that of portraying the usage of a lookup 
    >table to be something that would be a source of all manner of 'very bad
    
    >things', none of which are based in fact.
    >
    >Please explain to me how a fixed lookup table for categories would 
    >allow for random category insertion.
    >
    >I have to ask - are you intentionally muddying the water because you 
    >don't like this proposal, or is there a solid technical reason for this
    
    >being a bad approach to solving this problem?
    >
    >Cheers
    >Kon
    >
    >
    >
    >---------------------------------------------------------------------
    >To unsubscribe, e-mail: emergency-unsubscribe@lists.oasis-open.org
    >For additional commands, e-mail: emergency-help@lists.oasis-open.org
    
    
    
    
    ---------------------------------------------------------------------
    To unsubscribe, e-mail: emergency-unsubscribe@lists.oasis-open.org
    For additional commands, e-mail: emergency-help@lists.oasis-open.org
    
    
    
    
    ---------------------------------------------------------------------
    To unsubscribe, e-mail: emergency-unsubscribe@lists.oasis-open.org
    For additional commands, e-mail: emergency-help@lists.oasis-open.org
    
    
    ---------------------------------------------------------------------
    To unsubscribe, e-mail: emergency-unsubscribe@lists.oasis-open.org
    For additional commands, e-mail: emergency-help@lists.oasis-open.org
    
    


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