OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

emergency message

[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]