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

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: 
> For additional commands, e-mail: 

--
R. Allen Wyke
Chair, Emergency Management TC

http://www.oasis-open.org/committees/emergency