It's simply two things:
1. With the reference element, the software has a
standard way to notice different systems.
2. Without the reference element, the different
systems can't interoperate.
That's not rocket science. It's JIT conversions
vs dark spots in the coverage. You have to decide
if the reduced performance of some nodes is worth
including them in a network of responders for which
the majority have optimum response times and the
minority will evolve predictably toward the optima.
That is, better some than none.
What you want to know is the cost of that given
different approaches and the actual impedance
mismatches (semantics and format) of the different
systems. XSLT is cheap but would you run that
on the sensor? No. You would put that in the
smart aggregators that sit between the sensor
and the consoles.
The economics are a little less clean. If a vendor
proposes that the system not enable standard
software to notice different systems, then
goes to a local market and *discovers* that the
local procurement requires support for the
legacy system, that vendor will add a proprietary
extension to the standard to enable that, thus
locking in the customer to the proprietary solution
for the lifecycle of the system. The lifecycle
of public safety purchases is approximately 12 years.
len
From: Rex Brooks [mailto:]
Offhand, I would say that including validation checks as a mandatory
item in RFPs also makes sense to me. Assuming that good practices
will be followed sounds like a train wreck waiting to happen. Making
demonstrable, and accurate interoperability with a given set of CRS
might give a few vendors heartburn, and make some project managers
grumble, but, while it isn't trivial by any means, it aint QUITE
rocket science or brain surgery. It may be just a bit more important
at the time of response coordination, though.
