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

["Bullard, Claude L (Len)" <len.bullard@intergraph.com>]

Maybe I misunderstand this, Tom, but it seems to be a choice 
between a standard that won't be implemented ubiquitously 
and rules that can't be enforced.  It is usually a bad idea 
to write requirements that can't be enforced because of the 
limited reach of the authority that sanctions the standard. 
If my understanding of your point is wrong, please dismiss 
what follows here.

It can be a good idea to present the use scenarios.  I think 
what happens is that the easily shared portions of CAP will be 
shared and that those parts which are variant by jurisdiction 
have to evolve and/or converge according to local implementations. 
For that reason, it is better to isolate them to enable that 
process to occur rather than sink the standard. That this introduces 
implementation complexity is a given.

When the CALS program attempted to legislate MIL 28001 across 
the tri-services, it failed pretty miserably because the size 
and depth of that standard was such that it could not cost 
effectively or politically be enforced.  Some parts did succeed 
and mostly where native, that is, the parts based on 
MIL-38784, which had been used by the US Army in particular for 
many years.  Competing efforts and changes in the technology 
(eg, HTML and the migration to non-print-based systems) altered 
the environment.  Then PDF came along and swept most of the 
print-based systems aside, and the capability to drive SGML 
28001 to PDF (a print driver technology) for firm-fixed formats 
emerged.  This works but it was not the original plan.

For CAP to be successful, it has to be adaptible in those 
parts that are undergoing change for whatever reason where 
that reason is beyond the control of this working group 
and even DHS.  At the global scale, one needs simulations 
to ensure the critical real time aspects of the system work 
as envisioned.  At the local scale, feedback and lessons 
learned have to be incorporated in a timely fashion.  

Again, unless I misunderstand, this isn't an issue of 
change management here, but at the locus of the liaison 
standards.  These cannot be controlled from here so it 
seems better to isolate them from the main CAP spec, 
measure results, and act accordingly.  This is why most 
standards efforts don't end until the technology itself 
is obsoleted.

len


From: Tom Merkle [mailto:TMerkle@capwin.org]

I completely agree with Rex. We are at a point where we can no longer
assume "black box" standards will support CAP messages as those
standards continue to evolve. 
I am concerned that the issue of change management visibility is
non-existent with any other standards that interact with CAP. A good
example of that is when W3C moved to XML 2.0, while CAP is XML 1.0
based. Had the W3C change not been backyard compatible it could have
created quite a mess, and not just for CAP but the GJXDD, IEEE 1512, et
al. as well. Changes made to any of the "GJXDM-proxy/imported
standards/code lists" may produce an unexpected reaction that could
severely limit system performance.