mirror of
https://github.com/moparisthebest/xeps
synced 2024-12-21 23:28:51 -05:00
0.0.1
This commit is contained in:
Peter Saint-Andre
parent
eee8f15bf5
commit
848c901c3d
515
inbox/eventlogging.xml
Normal file
515
inbox/eventlogging.xml
Normal file
@ -0,0 +1,515 @@
|
||||
<?xml version='1.0' encoding='UTF-8'?>
|
||||
<!DOCTYPE xep SYSTEM 'xep.dtd' [
|
||||
<!ENTITY % ents SYSTEM 'xep.ent'>
|
||||
%ents;
|
||||
]>
|
||||
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
|
||||
<xep>
|
||||
<header>
|
||||
<title>Event Logging over XMPP</title>
|
||||
<abstract>This specification provides a common framework for sending events to event logs over XMPP networks.</abstract>
|
||||
<legal>
|
||||
<copyright>This XMPP Extension Protocol is copyright (c) 1999 - 2013 by the XMPP Standards Foundation (XSF).</copyright>
|
||||
<permissions>Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the "Specification"), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specification, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or substantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or publisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation.</permissions>
|
||||
<warranty>## NOTE WELL: This Specification is provided on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. In no event shall the XMPP Standards Foundation or the authors of this Specification be liable for any claim, damages, or other liability, whether in an action of contract, tort, or otherwise, arising from, out of, or in connection with the Specification or the implementation, deployment, or other use of the Specification. ##</warranty>
|
||||
<liability>In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the XMPP Standards Foundation or any author of this Specification be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising out of the use or inability to use the Specification (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if the XMPP Standards Foundation or such author has been advised of the possibility of such damages.</liability>
|
||||
<conformance>
|
||||
This XMPP Extension Protocol has been contributed in full conformance with the XSF's Intellectual Property Rights Policy (a copy of which may be found at <<link url='http://www.xmpp.org/extensions/ipr-policy.shtml'>http://www.xmpp.org/extensions/ipr-policy.shtml</link>> or obtained by writing to XSF, P.O. Box 1641, Denver, CO 80201 USA).
|
||||
</conformance>
|
||||
</legal>
|
||||
<number>xxxx</number>
|
||||
<status>ProtoXEP</status>
|
||||
<type>Standards Track</type>
|
||||
<sig>Standards</sig>
|
||||
<approver>Council</approver>
|
||||
<dependencies>
|
||||
<spec>XMPP Core</spec>
|
||||
<spec>XEP-0001</spec>
|
||||
</dependencies>
|
||||
<supersedes/>
|
||||
<supersededby/>
|
||||
<shortname>eventlog</shortname>
|
||||
<author>
|
||||
<firstname>Peter</firstname>
|
||||
<surname>Waher</surname>
|
||||
<email>peter.waher@clayster.com</email>
|
||||
<jid>peter.waher@jabber.org</jid>
|
||||
<uri>http://www.linkedin.com/in/peterwaher</uri>
|
||||
</author>
|
||||
<revision>
|
||||
<version>0.0.1</version>
|
||||
<date>2013-11-10</date>
|
||||
<initials>pw</initials>
|
||||
<remark>
|
||||
<p>First draft.</p>
|
||||
</remark>
|
||||
</revision>
|
||||
</header>
|
||||
<section1 topic='Introduction' anchor='intro'>
|
||||
<p>
|
||||
This XEP provides a common framework for sending events over an XMPP network. These events can then be logged in event logs or analyzed by network monitors
|
||||
to analyze the status or operation of the network and its participants.
|
||||
</p>
|
||||
<p>
|
||||
The basic principle behind interoperable event logging over XMPP is the definition of a common XML element defining the event. This payload is then sent in
|
||||
a normal message stanza (i.e. with <strong>type='normal'</strong>) to the recipient. The recipient in turn, if it understands the payload, can choose to store it in an event log, forward it or
|
||||
analyze it accordingly.
|
||||
</p>
|
||||
<p>
|
||||
There are various event log packages available, but none yet defined for XMPP or using a well defined and known XML format. Therefore, this document defines
|
||||
such an XML format. This format is able to store <link url='https://tools.ietf.org/html/rfc5424'>Syslog</link> <note>
|
||||
RFC-5424: The Syslog Protocol <<link url='https://tools.ietf.org/html/rfc5424'>https://tools.ietf.org/html/rfc5424</link>>
|
||||
</note> compliant event information, even though the Syslog event model has been somewhat extended.
|
||||
</p>
|
||||
</section1>
|
||||
<section1 topic='Glossary' anchor='glossary'>
|
||||
<p>The following table lists common terms and corresponding descriptions.</p>
|
||||
<dl>
|
||||
<di>
|
||||
<dt>Event</dt>
|
||||
<dd>A piece of information describing an event in time.</dd>
|
||||
</di>
|
||||
<di>
|
||||
<dt>Event ID</dt>
|
||||
<dd>An attribute providing a machine readable ID to the type of event in question without having to parse the message text itself.</dd>
|
||||
</di>
|
||||
<di>
|
||||
<dt>Event Level</dt>
|
||||
<dd>Provides an additional level on the previous classification (Minor, Medium, Major).</dd>
|
||||
</di>
|
||||
<di>
|
||||
<dt>Event Type</dt>
|
||||
<dd>Coarse classification of the event (Debug, Informational, Notice, Warning, Error, Critical, Alert, Emergency).</dd>
|
||||
</di>
|
||||
<di>
|
||||
<dt>Facility</dt>
|
||||
<dd>What type of device, server, application, etc., is sending the message. </dd>
|
||||
</di>
|
||||
<di>
|
||||
<dt>Message</dt>
|
||||
<dd>A (human readable) text message describing what has occurred.</dd>
|
||||
</di>
|
||||
<di>
|
||||
<dt>Module</dt>
|
||||
<dd>
|
||||
The module reporting the event. Larger software packages are often divided into modules. Keeping track of which modules report which events can be useful when
|
||||
analyzing system performance.
|
||||
</dd>
|
||||
</di>
|
||||
<di>
|
||||
<dt>Object</dt>
|
||||
<dd>The object to which the event message refers to, on which the current action is performed.</dd>
|
||||
</di>
|
||||
<di>
|
||||
<dt>Stack Trace</dt>
|
||||
<dd>
|
||||
Exact position in the code from whice the event was reported or error occurred. Reporting it in a separate attribute unclutters the message, and removes the need
|
||||
to define custom tags.
|
||||
</dd>
|
||||
</di>
|
||||
<di>
|
||||
<dt>Subject</dt>
|
||||
<dd>The subject causing the event to take place or performing the action (for instance, user, process, etc.)</dd>
|
||||
</di>
|
||||
<di>
|
||||
<dt>Tag</dt>
|
||||
<dd>A custom tag or parameter attached to an event. Each tag has a name and a value and an optional data type.</dd>
|
||||
</di>
|
||||
<di>
|
||||
<dt>Timestamp</dt>
|
||||
<dd>When the event occurred.</dd>
|
||||
</di>
|
||||
</dl>
|
||||
</section1>
|
||||
<section1 topic='Use Cases' anchor='usecases'>
|
||||
<section2 topic='Sending a simple event message'>
|
||||
<p>
|
||||
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:
|
||||
<strong>message</strong> and <strong>timestamp</strong>. This message will be treated as a <strong>Minor Informational</strong> message by the
|
||||
recipient.
|
||||
</p>
|
||||
<example caption='Simple event message'>
|
||||
<![CDATA[
|
||||
<message from='device@clayster.com/device' to='eventlog@clayster.com' type='normal' xml:lang='en'>
|
||||
<log xmlns='urn:xmpp:eventlog'
|
||||
message='Something happened.'
|
||||
timestamp='2013-11-10T15:52:23Z'/>
|
||||
</message>]]>
|
||||
</example>
|
||||
</section2>
|
||||
<section2 topic='Specifying type and level'>
|
||||
<p>
|
||||
The following example shows how an event message can be categorized with an event type and level.
|
||||
</p>
|
||||
<example caption='Specifying type and level'>
|
||||
<![CDATA[
|
||||
<message from='device@clayster.com/device' to='eventlog@clayster.com' type='normal' xml:lang='en'>
|
||||
<log xmlns='urn:xmpp:eventlog'
|
||||
message='Low on memory.'
|
||||
timestamp='2013-11-10T15:54:55Z'
|
||||
type='Warning'
|
||||
level='Major'/>
|
||||
</message>]]>
|
||||
</example>
|
||||
</section2>
|
||||
<section2 topic='Specifying object and subject'>
|
||||
<p>
|
||||
The following example shows how an event message can be further enhanced by providing object and subject information.
|
||||
</p>
|
||||
<example caption='Specifying object and subject'>
|
||||
<![CDATA[
|
||||
<message from='device@clayster.com/device' to='eventlog@clayster.com' type='normal' xml:lang='en'>
|
||||
<log xmlns='urn:xmpp:eventlog'
|
||||
message='Object deleted'
|
||||
timestamp='2013-11-10T15:58:12Z'
|
||||
type='Informational'
|
||||
level='Major'
|
||||
object='Towel'
|
||||
subject='Arhur Dent'/>
|
||||
</message>]]>
|
||||
</example>
|
||||
</section2>
|
||||
<section2 topic='Specifying an event ID'>
|
||||
<p>
|
||||
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.
|
||||
</p>
|
||||
<example caption='Specifying an event ID'>
|
||||
<![CDATA[
|
||||
<message from='device@clayster.com/device' to='eventlog@clayster.com' type='normal' xml:lang='en'>
|
||||
<log xmlns='urn:xmpp:eventlog'
|
||||
id='LoginFailed'
|
||||
message='User attempted to login but provided incorrect password.'
|
||||
timestamp='2013-11-10T16:04:45Z'
|
||||
type='Warning'
|
||||
level='Minor'
|
||||
object='user1'
|
||||
subject='10.0.0.1'/>
|
||||
</message>]]>
|
||||
</example>
|
||||
</section2>
|
||||
<section2 topic='Tagging events with custom information'>
|
||||
<p>
|
||||
The following example shows how to tag an event using custom information in a way that is easy to interpret and process.
|
||||
</p>
|
||||
<example caption='Tagging events with custom information'>
|
||||
<![CDATA[
|
||||
<message from='device@clayster.com/device' to='eventlog@clayster.com' type='normal' xml:lang='en'>
|
||||
<log xmlns='urn:xmpp:eventlog'
|
||||
message='Current resources.'
|
||||
timestamp='2013-11-10T16:07:01Z'
|
||||
type='Informational'
|
||||
level='Minor'>
|
||||
<tag name='RAM' value='1655709892' type='xs:long'/>
|
||||
<tag name='CPU' value='75.45' type='xs:double'/>
|
||||
<tag name='HardDrive' value='163208757248' type='xs:long'/>
|
||||
</log>
|
||||
</message>]]>
|
||||
</example>
|
||||
</section2>
|
||||
<section2 topic='Specifying program module'>
|
||||
<p>
|
||||
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.
|
||||
</p>
|
||||
<example caption='Specifying program module'>
|
||||
<![CDATA[
|
||||
<message from='device@clayster.com/device' to='eventlog@clayster.com' type='normal' xml:lang='en'>
|
||||
<log xmlns='urn:xmpp:eventlog'
|
||||
message='Something horrible happened.'
|
||||
timestamp='2013-11-10T16:17:56Z'
|
||||
type='Error'
|
||||
level='Major'
|
||||
object='object1'
|
||||
subject='user1'
|
||||
module='applicaiton1'/>
|
||||
</message>]]>
|
||||
</example>
|
||||
</section2>
|
||||
<section2 topic='Sending debug information'>
|
||||
<p>
|
||||
The following example shows how to send a debug message with a stack trace, module and custom inforation.
|
||||
</p>
|
||||
<example caption='Sending debug information'>
|
||||
<![CDATA[
|
||||
<message from='device@clayster.com/device' to='eventlog@clayster.com' type='normal' xml:lang='en'>
|
||||
<log xmlns='urn:xmpp:eventlog'
|
||||
message='Something is rotten in the state of Denmark.'
|
||||
timestamp='2013-11-10T16:12:25Z'
|
||||
type='Debug'
|
||||
level='Major'
|
||||
module='My new application'
|
||||
stackTrace='file1, line 1, ...'>
|
||||
<tag name='a' value='1' type='xs:int'/>
|
||||
<tag name='b' value='10' type='xs:int'/>
|
||||
<tag name='s' value='Hello World!' type='xs:string'/>
|
||||
</log>
|
||||
</message>]]>
|
||||
</example>
|
||||
</section2>
|
||||
</section1>
|
||||
<section1 topic='Determining Support' anchor='support'>
|
||||
<p>If an entity supports the reception of events as specified herein, it MUST advertise that fact by returning a feature of "urn:xmpp:eventlog" in response to &xep0030; information requests.</p>
|
||||
<example caption="Service discovery information request">
|
||||
<![CDATA[
|
||||
<iq type='get'
|
||||
from='device@clayster.com/device'
|
||||
to='eventlog@clayster.com'
|
||||
id='disco1'>
|
||||
<query xmlns='http://jabber.org/protocol/disco#info'/>
|
||||
</iq>]]>
|
||||
</example>
|
||||
<example caption="Service discovery information response">
|
||||
<![CDATA[
|
||||
<iq type='result'
|
||||
from='eventlog@clayster.com'
|
||||
to='device@clayster.com/device'
|
||||
id='disco1'>
|
||||
<query xmlns='http://jabber.org/protocol/disco#info'>
|
||||
...
|
||||
<feature var='urn:xmpp:eventlog'/>
|
||||
...
|
||||
</query>
|
||||
</iq>]]>
|
||||
</example>
|
||||
<p>
|
||||
In order for an application to determine whether an entity supports this protocol, where possible it SHOULD use the dynamic, presence-based profile of service discovery defined
|
||||
in &xep0115;. However, if an application has not received entity capabilities information from an entity, it SHOULD use explicit service discovery instead.
|
||||
</p>
|
||||
</section1>
|
||||
<section1 topic='Implementation Notes' anchor='impl'>
|
||||
<section2 topic='Event Types'>
|
||||
<p>
|
||||
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 <strong>Informational</strong>.
|
||||
It is largely based on the severity levels of Syslog.
|
||||
</p>
|
||||
<table caption='Event Types'>
|
||||
<tr>
|
||||
<th>Type</th>
|
||||
<th>Description</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Debug</td>
|
||||
<td>Developers can ask applications to send debug messages during development or testing to more easily see what happens in a system.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Informational</td>
|
||||
<td>An informational message describing a normal event.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Notice</td>
|
||||
<td>Represents a significant condition or change that administrators should be aware of.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Warning</td>
|
||||
<td>A warning condition. If not taken into account, the condition could turn into an error.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Error</td>
|
||||
<td>An error condition. A condition has been detected that is considered to be an error or a fault.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Critical</td>
|
||||
<td>A ciritical condition. An error so great that it could escalate into something graver if not addressed.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Alert</td>
|
||||
<td>An alert condition. Action must be taken immediately.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Emergency</td>
|
||||
<td>System is unusable.</td>
|
||||
</tr>
|
||||
</table>
|
||||
</section2>
|
||||
<section2 topic='Event Levels'>
|
||||
<p>
|
||||
Given an Event Type, an event level can provide additional information about the extent or importance of the event (a second dimension).
|
||||
</p>
|
||||
<table caption='Event Levels'>
|
||||
<tr>
|
||||
<th>Level</th>
|
||||
<th>Description</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Minor</td>
|
||||
<td>Minor events, concerning normal operating procedures.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Medium</td>
|
||||
<td>Medium events.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Major</td>
|
||||
<td>More substantial events or affecting larger parts of the system.</td>
|
||||
</tr>
|
||||
</table>
|
||||
</section2>
|
||||
<section2 topic='Event IDs'>
|
||||
<p>
|
||||
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).
|
||||
</p>
|
||||
<p>
|
||||
<strong>Note:</strong> To avoid problems when running applications using different locales, event IDs should never be localized.
|
||||
</p>
|
||||
</section2>
|
||||
<section2 topic='Objects'>
|
||||
<p>
|
||||
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.
|
||||
</p>
|
||||
</section2>
|
||||
<section2 topic='Subjects'>
|
||||
<p>
|
||||
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.
|
||||
</p>
|
||||
</section2>
|
||||
<section2 topic='Facilities'>
|
||||
<p>
|
||||
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.
|
||||
</p>
|
||||
</section2>
|
||||
<section2 topic='Modules'>
|
||||
<p>
|
||||
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.
|
||||
</p>
|
||||
</section2>
|
||||
<section2 topic='Stack Traces'>
|
||||
<p>
|
||||
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.
|
||||
</p>
|
||||
<p>
|
||||
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.
|
||||
</p>
|
||||
</section2>
|
||||
<section2 topic='Tags'>
|
||||
<p>
|
||||
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
|
||||
<link url='http://xmpp.org/registrar/xdv-datatypes.html'>Data Forms Validation Datatypes</link> <note>
|
||||
Data Forms Validation Datatypes <<link url='http://xmpp.org/registrar/xdv-datatypes.html'>http://xmpp.org/registrar/xdv-datatypes.html</link>>
|
||||
</note> that is maintained by the XMPP Registrar.
|
||||
</p>
|
||||
<p>
|
||||
<strong>Note:</strong> To avoid problems when running applications using different locales, tag names should never be localized.
|
||||
</p>
|
||||
</section2>
|
||||
<section2 topic='Normalized tables'>
|
||||
<p>
|
||||
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.
|
||||
</p>
|
||||
<p>
|
||||
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.
|
||||
</p>
|
||||
</section2>
|
||||
</section1>
|
||||
<section1 topic='Internationalization Considerations' anchor='i18n'>
|
||||
<section2 topic='Time Zones'>
|
||||
<p>
|
||||
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.
|
||||
</p>
|
||||
<p>
|
||||
<strong>Note:</strong> 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.
|
||||
</p>
|
||||
<p>
|
||||
If devices report time zone, this information should be propagated throughout the system. Otherwise, comparing timestamps from different time zones will be impossible.
|
||||
</p>
|
||||
</section2>
|
||||
<section2 topic='xml:lang'>
|
||||
<p>
|
||||
Event messages SHOULD contain an <strong>xml:lang</strong> 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 <strong>xml:lang</strong> attribute can be omitted).
|
||||
</p>
|
||||
</section2>
|
||||
</section1>
|
||||
<section1 topic='Security Considerations' anchor='security'>
|
||||
<p>
|
||||
Even though this document permits zero-configuration of devices to event logs, this might not always be the best option. Event information might be sensitive
|
||||
and should not be sent to anybody just because they support the event log feature as defined in this document.
|
||||
</p>
|
||||
<p>
|
||||
<strong>Never</strong> log information that should be handled securely or encrypted, such as passwords.
|
||||
</p>
|
||||
</section1>
|
||||
<section1 topic='IANA Considerations' anchor='iana'>
|
||||
<p>This document requires no interaction with &IANA;.</p>
|
||||
</section1>
|
||||
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
|
||||
<p>
|
||||
The <link url="#schema">protocol schema</link> needs to be added to the list of <link url="http://xmpp.org/resources/schemas/">XMPP protocol schemas</link>.
|
||||
</p>
|
||||
</section1>
|
||||
<section1 topic='XML Schema' anchor='schema'>
|
||||
<code>
|
||||
<![CDATA[
|
||||
<?xml version='1.0' encoding='UTF-8'?>
|
||||
<xs:schema
|
||||
xmlns:xs='http://www.w3.org/2001/XMLSchema'
|
||||
targetNamespace='urn:xmpp:eventlog'
|
||||
xmlns='urn:xmpp:eventlog'
|
||||
elementFormDefault='qualified'>
|
||||
|
||||
<xs:element name='log'>
|
||||
<xs:complexType>
|
||||
<xs:choice minOccurs='0' maxOccurs='unbounded'>
|
||||
<xs:element name='tag'>
|
||||
<xs:complexType>
|
||||
<xs:attribute name='name' type='xs:string' use='required'/>
|
||||
<xs:attribute name='value' type='xs:string' use='required'/>
|
||||
<xs:attribute name='type' type='xs:QName' use='optional' default='xs:string'/>
|
||||
</xs:complexType>
|
||||
</xs:element>
|
||||
</xs:choice>
|
||||
<xs:attribute name='message' type='xs:string' use='required'/>
|
||||
<xs:attribute name='timestamp' type='xs:dateTime' use='required'/>
|
||||
<xs:attribute name='id' type='xs:string' use='optional'/>
|
||||
<xs:attribute name='type' type='EventType' use='optional' default='Informational'/>
|
||||
<xs:attribute name='level' type='EventLevel' use='optional' default='Minor'/>
|
||||
<xs:attribute name='object' type='xs:string' use='optional'/>
|
||||
<xs:attribute name='subject' type='xs:string' use='optional'/>
|
||||
<xs:attribute name='facility' type='xs:string' use='optional'/>
|
||||
<xs:attribute name='module' type='xs:string' use='optional'/>
|
||||
<xs:attribute name='stackTrace' type='xs:string' use='optional'/>
|
||||
</xs:complexType>
|
||||
</xs:element>
|
||||
|
||||
<xs:simpleType name='EventType'>
|
||||
<xs:restriction base='xs:string'>
|
||||
<xs:enumeration value='Debug'/>
|
||||
<xs:enumeration value='Informational'/>
|
||||
<xs:enumeration value='Notice'/>
|
||||
<xs:enumeration value='Warning'/>
|
||||
<xs:enumeration value='Error'/>
|
||||
<xs:enumeration value='Critical'/>
|
||||
<xs:enumeration value='Alert'/>
|
||||
<xs:enumeration value='Emergency'/>
|
||||
</xs:restriction>
|
||||
</xs:simpleType>
|
||||
|
||||
<xs:simpleType name='EventLevel'>
|
||||
<xs:restriction base='xs:string'>
|
||||
<xs:enumeration value='Major'/>
|
||||
<xs:enumeration value='Medium'/>
|
||||
<xs:enumeration value='Minor'/>
|
||||
</xs:restriction>
|
||||
</xs:simpleType>
|
||||
|
||||
</xs:schema>]]>
|
||||
</code>
|
||||
</section1>
|
||||
<section1 topic='Acknowledgements' anchor='ack'>
|
||||
<p>Thanks in alphabetical order to Joachim Lindborg, Markus Kohlhase, Matthew Wild, Mike Taylor, Robert Kosten, Steffen Larsen, and Yusuke DOI for all valuable feedback.</p>
|
||||
</section1>
|
||||
</xep>
|
||||
Loading…
Reference in New Issue
Block a user