[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've been slow to chime in because I see merit in both positions. I find that lookup tables are appropriate in the following contexts: * When redundant data needs to be "normalized" to ensure data integrity. This occurs when an enumeration is used in more than one location in the schema. * When data needs to be generalized for extensibility. This gives the users of the schema the power to create their own extensions to the enumeration without requiring a change in the schema specification. The problem with this is, of course, interoperability. * When data needs to be mapped to various nomenclatures. This can be quite useful when communicating between and among multi-lingual organizations. Having said that, there are a few things that need to be considered: * A system designed to ingest CAP compliant messages should be able to not only parse (syntax) but understand (semantics) the message received. A message that includes a value for an enumeration (whether in a look up table or in a string representation) that is not universally recognized by the CAP community, then it should not be recognized as a CAP message. * Emergency messages - especially notification messages - need to be self contained. The message should not include codes that assume the recipient has the decoder ring - or the most recent version of the decoder ring. Lookup tables should be contained in the message itself. Mapping from the standard nomenclature to the recipients nomenclature is an implementation issue that needs to be addressed by the recipient's parsing software. * The enumeration may prove to be incomplete or insufficiently refined for effective use, and we don't want the standard to hinder effective communication. There should be a mechanism in place to convey the necessary information where it can be understood by the recipient, but still meet the standard. For example, response to Chem can be very different from response to Bio, and simply identifying CBRN may prove to be insufficient. Waiting to have CBRN broken out into Chem & Bio in a subsequent standard adoption is probably not the best solution. Maybe we should allow "Other" values for enumerations and add an optional element for further qualification. If a new value needs to be added to the enumeration, a message would have the "Other" enumeration value for the field and the optional element would qualify to what other is referring. If an existing enumeration values needs to be further refined, the message would have the existing enumeration value for the field and the optional element would specify the finer resolution qualification. Just a thought... Well, as you can see, I'm not sold on either approach. I guess I'm leaning more toward string representation rather than a look-up table, but my mind remains open. I would rather consider this a CAP 2.0 issue rather than trying to rush to resolution without thoroughly exploring the options. IMHO, Patti Iles Aymond, PhD Senior Scientist Bioterrorism Preparedness & Response Innovative Emergency Management, Inc. Managing Risk in a Complex World 8555 United Plaza Blvd. Suite 100 Baton Rouge, LA 70809 (225) 952-8228 (phone) (225) 952-8122 (fax) -----Original Message----- From: Elysa Jones [mailto:ejones@warningsystems.com] Sent: Tuesday, March 08, 2005 4: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 IEM CONFIDENTIAL INFORMATION PLEASE READ OUR NOTICE: http://www.ieminc.com/e_mail_confidentiality_notice.html
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]