[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [emergency] Groups - EDIT of emergency-CAPv-1.1
Changing the "Category" element to be "required" in CAP 1.1 will force us to change our CAP implementation and specifically to make changes to our database schema (something we are never too excited about unless we absolutely have to). Of course there are workarounds that we will most probably implement such as always setting the "Category" element to the value "Other", which actually defeats the whole purpose of having the Category as a "required" element.
Finally, at Blue292, we have not developed specific user requirements that allow us to articulate, from a business standpoint how this should be resolved in the standard. Having said that, in our incident activation process, we keep the number of data elements required for defining the incident to an absolute minimum. Our customers appreciate that and caution us against putting them through a process where an exhaustive list of data elements must be completed/selected every time a new incident is logged.
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
> > 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?
>To unsubscribe, e-mail: firstname.lastname@example.org
>For additional commands, e-mail: email@example.com
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com