MHonArc v2.5.0b2 -->
emergency message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [emergency] Comment #30: Suggested Language
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]