The following example shows how to send a simple event using a normal message to an event log. There are only two parameters that are required: message and timestamp. This message will be treated as a Minor Informational message by the recipient.

The following example shows how an event message can be categorized with an event type and level.

The following example shows how an event message can be further enhanced by providing object and subject information.

The following example shows how an event message can receive an ID that can be singled out later to be analyzed by administrators, for instance.

The following example shows how to tag an event using custom information in a way that is easy to interpret and process.

The following example shows how module information can be provided in events to more easilly be able to single out information relating to the same application running on different machines.

The following example shows how to send a debug message with a stack trace, module and custom inforation.

The following table lists possible event types that can be used. If none is specified for an event, it is assumed that the event is Informational. It is largely based on the severity levels of Syslog.

Given an Event Type, an event level can provide additional information about the extent or importance of the event (a second dimension).

Using Event IDs the application can provide a machine understandable classification of the event. Examples could be "Login"-events, "ConnectionProblem"-events, etc. It is easier to group, parse or interpret events and their tags if you know what type of event it is. Event IDs are manufacturer specific, and only provide a means to more easilly extract subsets of events for processing without having to parse message texts (which should be allowed to be localizable).

Note: To avoid problems when running applications using different locales, event IDs should never be localized.

An event is often linked to an object, i.e. on which object an action was performed, or which object is reporting a condition. The object field permits the tagging of objects in a common way. It is later easy to extract all events relating to a specific object by using this attribute.

An event is often also linked to a subject, i.e. who or what performed a given action resulting in the event or condition. The subject field permits the tagging of subjects in a common way. It is later easy to extract all events relating to a specific subbject by using this attribute.

Facility can be either a facility in the network sense or in the system sense. This document does not restrict its use to the possible choices defined by other protocols such as Syslog, and leaves it open. However, it is left as a special attribute since it is important in monitoring applications.

A module is part of a larger software package. Using the module attribute makes it easier to attribute events to specific parts of a distributed application and analyze them separately.

Stack Traces can be important information to developers and correlate events to actual locations in the code that generated the event. This document does not specify any particular format for stack traces.

Note that stack traces can be divided into multiple lines separated by CRLF. It is important to encode such strings correctly to avoid problems in XML parsers.

Any event can have a custom set of tags attached to it. A tag is required to have a name and a value. It can also optionally specify a datatype. Data Types are specified using Qualified Names (QNames). If possible, they should adher to the list of Data Forms Validation Datatypes Data Forms Validation Datatypes <http://xmpp.org/registrar/xdv-datatypes.html> that is maintained by the XMPP Registrar.

Note: To avoid problems when running applications using different locales, tag names should never be localized.

If persisting received events in a database, care should be taken if normalized tables are used for storage of tags names and values, event IDs, objects, subjects, facilities and modules. If this is the case, the receiver should look for types of values that can be incompatible with normalized tables (such as floating point values or numbers in general, GUIDs, resource names in JIDs etc.) and replace them with some descriptive text and append the corresponding value in the message text instead. This to avoid problems with indexes in databases because of devices implemented by third parties.

It is still valid to send such information (like sequence numbers, unique GUIDs, resource names in JIDs etc., measurements, etc.) in tags names and values, but should be avoided in event IDs, objects, subjects, facilities and modules, as they can cause problems further down the line.

All timestamps and dateTime values use the XML data type xs:dateTime to specify values. These values include a date, an optional time and an optional time zone.

Note: If time zone is not available, it is supposed to be undefined. The recipient of an event message without time zone information should assume the sender has the same time zone as the received, if not explicitly configured otherwise on the recipient side.

If devices report time zone, this information should be propagated throughout the system. Otherwise, comparing timestamps from different time zones will be impossible.

Event messages SHOULD contain an xml:lang attribute on the message stanza to specify the language used in message texts, etc. If language information is not available (for instance, if relaying messages not created by the device itself, the xml:lang attribute can be omitted).