[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
>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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]