Title: Re: [emergency] Groups - EDIT of emergency-CAPv-1.1
Elysa,
To answer your question, our implementation of CAP 1.0 relied on the Category field being an optional
field. When we posted our incident to DMIS as CAP-formatted messages, we
did not capture "Category" at all, since it was optional.
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.
Hope this helps
Walid
From: Elysa Jones
[mailto:]
Sent: Tue 3/8/2005 5:25
AM
To: Kon Wilms; Art Botterell
Cc:
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:
>For
additional commands, e-mail:
---------------------------------------------------------------------
To
unsubscribe, e-mail:
For
additional commands, e-mail:
