Open CAP Issues (was RE: [emergency] Meeting Minutes: 2003.10.07)

[Art Botterell <acb@incident.com>]

Walid -

Looking through my personal file "CAP Issues" email file, I see the 
following pending issues:

* Categorization of threats:  The SC having tried unsuccessfully to 
locate or devise a taxonomy for threats which satisfied them as being 
both broad enough and specific enough to be useful in automated 
processing in all-hazards applications, the current committee draft 
has the <event> element as optional.  Some implementers have 
expressed a desire for a reliable (i.e., required) way to categorize 
messages according to threat.

* Categorization of responses:  The committee draft doesn't attempt 
to encode responses into categories, but some implementers have 
expressed a desire to be able to automatically slot the recommended 
response <instruction> into one or more machine-readable (i.e., 
coded) categories.

* Geographic targeting codes:  The <geocode> element, which was 
included to provide backward compatibility with existing systems 
(notably EAS and NOAA Weather Radio, but also many local systems) 
also adds a bit of complexity.  It seems possible that in an ideal 
world all areas would be in pure geospatial terms (<polygon> and 
<circle>) but that may be a leap too far ahead of the current state 
of the art to allow updake of the standard.  In the meantime, one 
suggestion has been to restrict the use of <geocode> to certain 
well-known coding schemes... although it's been argued that doing so 
could create a barrier to adoption in existing systems that use their 
own predefined alerting or response zones.

* Other GIS inputs: I'm attaching some recent notes from the GIS SC 
that explore some possible refinements and extensions, although I 
didn't understand any of them as urgent action items.  (Maybe Carl 
Reed can point out any that require immediate attention.)

* Binary resources over one-way transport: This has been raised by 
various TC members including, most recently, by the Board of the 
Partnership for Public Warning on behalf of its membership (see 
attached letter).  It also was raised in comments from at least one 
outside commenter (NDSAmerica).

* ISO code royalty flap: The current spec provides for use of ISO 
language codes to identify multilingual versions.  ISO has recently 
asserted an interest in collecting royalties for use of those codes 
(among others)... this is a subject of debate internationally (see 
<http://xml.coverpages.org/ni2003-09-20-a.html>).  Unless this issue 
is resolved very shortly, some disclosure of this issue probably 
needs to be included in the specification document.

* Name attributes in schema: It's been suggested that the schema 
ought to provide explicit name attributes in <simpleType> 
declarations.

Of course, other folks may have other items they'd like added, but 
that's my list.  Thanks!

- Art

PPW_Letter.PDF

GIS_notes_for_CAP.doc