Emergency-management XML provides shared structures for exchanging information between systems. Start by identifying the message format, its version, the sender, and the intended recipients. Then interpret the message lifecycle and the rules of the system that carries it.
Distinguish content from distribution
The OASIS Common Alerting Protocol 1.2 standard defines a format for alerts and public warnings. A CAP message can describe an event, urgency, severity, certainty, affected area, timing, and instructions. Those fields let receiving systems interpret the message according to shared definitions.
EDXL is a family of emergency data-exchange specifications. The EDXL Distribution Element 2.0 Committee Specification describes a wrapper for related content and routing criteria. Its role differs from an individual alert's event description. A deployment must specify the exact versions and profiles it accepts. Interoperability also depends on consistent field interpretation and application behavior.
Read identity, status, and timing first
| Field | Meaning | Reader check |
|---|---|---|
| identifier, sender, sent | Identify a particular message from a sender | Preserve the complete reference tuple. |
| status and scope | Test/actual status and intended dissemination | Check these before interpreting an exercise as an operational message. |
| msgType and references | Alert, update, cancellation, and their relationships | Resolve references to the correct earlier messages. |
| urgency, severity, certainty | Timing priority, expected impact, and confidence categories | Interpret each separately using the specified vocabulary. |
| effective, onset, expires | When information applies, the event starts, and information expires | Keep timezone offsets and field meanings distinct. |
Area descriptions, polygons, circles, and geocodes may express different spatial information. Check coordinate ordering and code-system definitions in the applicable specification and profile. A drawn boundary is useful only when the receiver interprets its coordinates and scope correctly.
Follow a fictional alert lifecycle offline
The XML labs pack contains three expired, fictional messages for local reading only. All use status=Test, scope=Private, and a reserved example.invalid address. The sequence is:
lab-001, sent at 10:00 UTC, introduces an offline exercise.lab-002, sent at 10:05 UTC, updates it and references the first message.lab-003, sent at 10:10 UTC, cancels the second message.
The update's reference contains the sender, identifier, and original sent time:
training@example.invalid,lab-001,2026-09-15T10:00:00-00:00CAP uses an explicit timezone offset; its UTC representation is -00:00. Preserve that exact value in references. The update has its own identifier and sent time. Cancellation addresses the referenced message; it does not establish that an underlying hazard has ended.
With Python and lxml installed, run python check_cap.py. Expect three schema-valid messages with resolved references. The script validates against the bundled unmodified OASIS schema and checks this fixed sequence. It is an educational check, not a complete receiving application. Do not transmit these examples to an alerting service.
Separate validation from authority
Schema validation checks the document's structure and datatypes. Additional checks must address required relationships, trusted sender identity, profile rules, allowed geography, and operational permissions. A conforming message can still contain incorrect facts.
U.S. IPAWS has its own adoption, agreement, training, and testing processes. Consult FEMA's IPAWS training material for that operational setting. The offline examples here make no IPAWS conformance or authorization claim.
For a receiving-system evaluation, use the authorized test environment and its procedures. Include duplicate messages, out-of-order updates, unresolved references, expiry, and restart recovery. Record how the system preserves message history while presenting the current state. Review timestamp, profile, and schema assumptions whenever an integration changes.