[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [emergency] Groups - EDIT of emergency-CAPv-1.1
Ok. I understand your position, I think. As long at the standard is not reapplied outside that scope, then as Kon states, it is a an issue of keep the simple part simple but enable growth where growth is likely and not a local variants issue. For the police systems world, local variants are the rule, not the exception. It means dispatch and police records can't run out of the same database; they have to be interfaced. (For performance reasons, they shouldn't be the same db anyway, but a surprising number of RFPs ask for that because of the pervasive mythology of 'update once; share everywhere' which is better in theory than practice. But that means one should not reapply this language. It's scope is precisely as you say and don't attempt to reuse it elsewhere. The Air Force approach to its command and control schema was/is, only standardize the shared parts of C2 and deliberately leave out any local variants. It limits the depth but increases the reach. I do agree with Kon, though. One doesn't have to put it all in one schema monolith (regardless of who does updates). That hasn't worked well for SGML in the past and I don't think it is good XML practice. The versioning issue is real. The TAG is still at that one too. len From: Art Botterell [mailto:acb@incident.com] Len, I think you're getting close to the central issue here. I believe we've achieved so much so quickly with CAP precisely because we kept it simple and focused. So I'm having a little trouble wrapping my head around the idea of "parts which are variant by local jurisdiction." We aren't talking about local response codes here... we're talking about a standard, high-level, and hopefully global categorization of emergent threats and events. Hopefully we'll revise and improve that taxonomy over time... but if we aren't all using the same taxonomy at the same time, how will we have achieved our goal of interoperability? (Note that the ability to revise the list globally, though the standards process, is very different from the ability to revise it locally, at will. We have the former; I'm not sure we really want the latter.) - Art At 10:27 AM -0600 3/18/05, Bullard, Claude L (Len) wrote: >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 > --------------------------------------------------------------------- To unsubscribe, e-mail: emergency-unsubscribe@lists.oasis-open.org For additional commands, e-mail: emergency-help@lists.oasis-open.org
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]