emergency-msg — archive

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

From: Allen Wyke
To: [email protected]
Date: Fri, 18 Jul 2003 21:58:00 -0000

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: [email protected] > For additional commands, e-mail: [email protected] -- R. Allen Wyke Chair, Emergency Management TC [email protected] http://www.oasis-open.org/committees/emergency