[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [emergency] Re: Circle and Polygon
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:email@example.com] 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.