ICS-201 dictionary v2: some notes for discussion

[Art Botterell <acb@incident.com>]

Dave et al. -

Just a few notes from a quick review of this excellent draft:

* I notice that we haven't borrowed the <scope> , <restriction> and 
<addresses> elements from CAP.  That's fine, so long as we don't 
anticipate needing to assert constraints on the dissemination of a 
message, e.g., a security classification (one possible use of a 
<restriction> element) or any sort of explicit addressing.

* Seems like we've used the same rather general definition for both 
<objective> and <action>.  Might I suggest something like, for 
<objective>, "A description of an operational goal or objective for 
the incident" and, for <action>, "A description of a specific 
activity being undertaken in response to the incident"?

* In <resourceDesc> we have both number and type in a single 
element... that  doesn't seem right somehow.  If there's more than 
one component to the asset being described, shouldn't it have a 
singular aggregate entity, e.g., "task force"?

* In <isOnScene> seems like we could define "false" as encompassing 
both "not on scene" or "unknown", since both have the functional 
effect of the asset not being at the Incident Commander's disposal.

* In <positionTitle> and <positionResports> I think we could be a bit 
more prescriptive here... ICS provides an enumeration of position 
names... and allowing free-form text descriptions can cause heartburn 
for implementers which, in this case, might be avoidable.

* Rather than allow "other descriptive information" in the <name> 
element, might we consider going ahead and adding an optional <vCard> 
element (perhaps per  <http://www.jabber.org/jeps/jep-0054.html> )? 
Note that this would involve quoting the opencontent.org copyright 
and license language in the OASIS document... but that's allowed.

* In the <polygon> and <circle> elements the definition refers to a 
WGS-84 note, which has not been appended yet and which includes some 
important specifics about the format.  Probably need either to bring 
in that note or to pull those specifics (e.g., coordinate order) into 
the definition itself.

* I'll note for the record that we haven't provided a way to transmit 
binary resources (map sketches, in particular) over one-way links. 
(I'll also note that both the Jabber and W3C vCard formats do provide 
for an inline binary photo.  The W3C RDF version also supports inline 
binary audio, logo (graphic) and encryption keys.)

Just a few quick observations for discussion among the team...

- Art