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