RE: [emergency-msg] ICS form req's draft

[Allen Wyke <emtc@nc.rr.com>]

The combination of this and our chat clarifies the intention - thanx for
taking the time to help me understand. As promised, here is a suggestion
on how to reword the section of discussion in the "Requirements for an
Incident Briefing message based on the ICS-201" document
(http://lists.oasis-open.org/archives/emergency-msg/200307/msg00005.html):

The Incident Briefing message SHOULD:

  * Attempt to leverage the knowledge gained when defining the
    <alert> section of the Common Alerting Protocol (CAP). Exactly
    how this will actually be leveraged (copy, reference, import,
    influence, etc.), will be determined at a later time.

On Fri, 2003-07-18 at 11:18, Art Botterell wrote: 
> At 8:33 AM -0400 7/18/03, Allen Wyke wrote:
> >Maybe I am not understanding "how" you are planning on using the 
> >subset. Are you proposing to use the same structure as used in CAP, 
> >OR are you saying to use CAP ("connection" implies use CAP)?
> 
> How can I  say this any more plainly? Nobody has suggested importing 
> any structure from any other schema.  (In fact, structure hasn't been 
> discussed at all... that's a later step in the SC's agreed-upon 
> process.)  All that has been suggested is that certain elements that 
> were used elsewhere might also be useful in the new (ICS-201) schema. 
> To enumerate, we're talking about some or all of:
> 
> Message ID (identifier)
> Sender ID (sender)
> Sent Date/Time (sent)
> Status (status)
> Scope (scope)
> Type (msgType)
> Password (password)
> Operator/Device ID (source)
> Restriction (restriction)
> Address (address)
> Handling Code (code)
> Note (note)
> Reference ID (reference)
> Incident ID (incident)
> 
> If (and only if) we decide that some or all of those elements would 
> be useful in the ICS format, then the next question will be how best 
> to implement that.  We could create a joint data dictionary, as has 
> been suggested on several occasions.  Or we could create a 
> spaghetti-plate of inter-schema references, although that wouldn't be 
> my recommendation.  Or we could simply include identical element 
> names and definitions in the new spec, which would be inelegant, 
> perhaps, but quick and simple for purposes of discussion, and easily 
> transformed into a more elegant formulation later.
> 
> But those are two separate questions; until we decide there's 
> actually a need for some or all of those elements, it seems premature 
> to argue about the mechanics of including them.  What's on the table 
> right now is a requirements document, which by definition focuses on 
> "what" rather than "how."
> 
> Of course, if someone in the TC or the IF SC wants to bring forward a 
> constructive process proposal on how the TC should do this sort of 
> thing globally, that would be wonderful.  But this SC has been asked 
> to move ahead, and in the absence of a TC policy we've tried to do so 
> in the simplest, quickest and most transparent way we can devise.
> 
> I appreciate everyone's cooperation and assistance in getting so much 
> productive work done so quickly so far, and I very much hope we'll be 
> able to proceed in the same spirit.
> 
> - Art
> 
> 
> --
> To unsubscribe, e-mail: emergency-msg-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: emergency-msg-help@lists.oasis-open.org

-- 
R. Allen Wyke
Chair, Emergency Management TC
emtc@nc.rr.com
http://www.oasis-open.org/committees/emergency