MHonArc v2.5.0b2 -->
emergency message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Open CAP Issues (was RE: [emergency] Meeting Minutes: 2003.10.07)
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]