Re: [emergency] Comment #30: Suggested Language

[Rex Brooks <rexb@starbourne.com>]

I haven't made up my mind yet, because I would like to hear from 
Gary/Rick et al if they think there is any overhead performance cost 
implications for scalability considerations in this. Reluctantly, and 
wishing we had a more secure, private forum in which to conduct this 
particular discussion, I am coming to some unsettling conclusions 
about concurrent, cascading emergency situations.

Consider for a moment the secondary effects of overload on local 
communication networks during critical timeframes when more than one 
major type of emergency (bio, chem, radiological), is followed by 
infrastructural attacks on transportation and/or communications 
systems. Think back to this summer and fact that we have yet to hear 
a reasonable explanation for complications which appear to have 
cumulatively worsened a basic vulnerability in the power grid.

Of course, we have to take first things first and get our basic, 
fundamental specs out and working so we can discover what needs to be 
dealt with to begin perfecting that level of response service, but it 
is also wise to keep an eye on how we may need to be capable of 
adapting to coordinated, timed emergencies, or freelancing attacks 
that seriously impede responses to natural disaster emergenices.

Paranoidly Yours,
Rex

At 9:41 PM -0800 12/1/03, Art Botterell wrote:
>A couple of notes on this one:
>
>1) Having had more time to reflect, I think there might be 
>legitimate instances of an <alert> of type Alert with no included 
><info>... especially if the scope is Restricted or Private.  Anyway, 
>making the presence of an <info> block mandatory when the value of 
><msgType> is "Alert" would complicate both the schema and any strict 
>implementation thereof.  So I'm thinking it might be more 
>appropriate to make this a SHOULD (or even a "normally SHOULD").
>
>2) It seems this could be expressed more simply in the affirmative 
>by saying something like: "Under most circumstances CAP messages 
>with a <msgType> value of "Alert" SHOULD include at least one <info> 
>element."
>
>- Art
>
>
>
>
>At 10:18 AM -0500 12/1/03, emtc@nc.rr.com wrote:
>>I would suggest we add the following last line to Section 1.3. The complete
>>paragraph would read...
>>
>>1.3 Structure of the CAP Alert Message
>>Each CAP Alert Message consists of an <alert> segment, which may contain one
>>or more <info> segments, each of which may include one or more <area>
>>segments (see the document object model diagram in section 3.1, below). While
>>the CAP XML Schema Definition (XSD) allows for a valid message to only
>>include <alert>, <identifier>, <sender>, <sent>, <status>, and <msgType>,
>>this type of message MUST only be used for message acknowledgements,
>>cancellations, or other system functions.
>>
>
>To unsubscribe from this mailing list (and be removed from the 
>roster of the OASIS TC), go to 
>http://www.oasis-open.org/apps/org/workgroup/emergency/members/leave_workgroup.php.


-- 
Rex Brooks
GeoAddress: 1361-A Addison, Berkeley, CA, 94702 USA, Earth
W3Address: http://www.starbourne.com
Email: rexb@starbourne.com
Tel: 510-849-2309
Fax: By Request