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:]
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.
