As an XML application, an XLF file SHOULD begin with the <?xml> element.

The most important attribute of the <?xml> tag for our purposes is the encoding attribute. The most common values for the encoding is either "UTC-8" (8-bit ASCII) or "UTC-16" (16-bit Unicode), although there are others as well.

The <?xml ...> processing instruction is written out when the logfile is first created.

Example:

<?xml version="1.0" encoding="UTF-8"?>

The <xlf> element comes after the <?xml ...> tag, and is written out when the logfile is first created.

The <xlf> tag has these attributes:

Req'd	Name	Type	Default	Description
X	version	xs:string	"1.9.1"	The version of the XLF standard this file was written in.
	closetags	xs:boolean	"1"	Set this to "0" if the logfile does not end with a </xlf> tag, but instead simply has <session>, <logevent>, and <debugevent> entries appended to the end of it.
	product	xs:string	""	The overall product that the programs that are writing to this logfile belong to, if they're all part of the same product. (Otherwise the products should be specified in each <session> element.)

Inside the <xlf> element, there are zero or more instances of <session>, <logevent>, and <debugevent>, in any order.

Unresolved issue: The full XML Schema shows the <xlf> element as a complexType. But the XML Schema language doesn't seem to provide a way to specify that a complexType element can have any number of specific children in any sequence. "xs:sequence" means that any number of the specified child elements can occur, but only in a specific sequence. "xs:all" means that they can occur in any sequence, but there can only be one of each. Neither is true in the case of XLF. So I don't know exactly how the <xlf> element's structure should be expressed in the schema.

Example with closing tags:

<?xml version="1.0" encoding="UTF-8"?> <xlf version="1.9.1"> <session ... <logevent ... <logevent ... <logevent ... <debugevent ... <logevent ... <session ... <logevent ... <logevent ... </xlf>

Example without closing tags:

<?xml version="1.0" encoding="UTF-8"?> <xlf version="1.9.1" closetags="0"> <session ... <logevent ... <logevent ... <logevent ... <debugevent ... <logevent ... <session ... <logevent ... <logevent ...

When an individual program starts up, it SHOULD write a <session> element. The element's body is a unique identifier of some kind—a random integer, the current system time, or even a Windows-style GUID. The purpose of the <session> element is to allow the logfile analyzer to group logfile entries together. It also collects relevant information for this logging session, such as the program that generated these log entries, its process ID, the computer this program is running on, etc.

If the <session> element is used, all subsequent <logevent> and <debugevent> entries that are written from this instance of the program SHOULD include this ID in their session attributes.

Note that the <logevent> and <debugevent> entries are not children of this session. This is because there could be mutliple programs writing to the same logfile concurrently, so their log entries would be interspersed with each other. So the log/debug entries simply refer back to their respective sessions instead.

The <session> tag has these attributes:

Req'd	Name	Type	Default	Description
	dtfmt	dtfmt-type (see below)	"xml"	The format that the <logevent> and <debugevent> entries will use to express the date/time. (see below)
	ipaddr	xs:string	""	IP address of this computer.
	computer	xs:string	""	Name of this computer on the network.
	user	xs:string	""	Name of the user account this program is running under.
	product	xs:string	""	Name of the product that this program is part of, if not specified in <xlf>.
	pgm	xs:string	""	Name or pathname of this program.
	pgmver	xs:string	""	This program's version string.
	procid	xs:integer	"0"	This program's process ID.
	tz	xs:string	""	The timezone this computer is in, as ±hh:mi. This is useful if you can't or don't want to include it in each <logevent>'s timestamp.
	helpuri	xs:anyURI	""	The base URL to the file that contains information on specific <logevent> codes. (see below)

The dtfmt attribute specifies how this program will be expressing its date/times. You can specify these formats:

dtfmt	Meaning
xml	The default format for XLF (and XML) files: yyyy-mm-ddThh:mi:ss±hh:mi. a.k.a. the dateTime datatype.
rfc-822	The standard format for email, HTTP headers, etc.
sql	SQL's DATETIME format: yyyy-mm-dd hh:mi:ss, possibly with milliseconds attached as a decimal part.
unix	Number of seconds since midnight on 1/1/1970. This is generated by the time function in C, PHP, etc.
VT_DATE	The default date/time format for Windows Automation objects. This is a floating-point number; the integer part is the number of days since 12/30/1899, and the decimal part is the fraction of the day since midnight.
strftime: formatspec	This value should allow for any custom format a program could reasonably come up with. formatspec is the format string you would pass to the strftime function in C, PHP, Python, etc.

The helpuri attribute specifies where the log analyzer program can find the descriptions for the various codes from the <logevent> & <debugevent> entries.

Unresolved issue: The helpuri attribute is meant to enable a log analyzer program to produce a description of the various codes that the logevents & debugevents produce. The user would click on the code value for a specific logevent, and the analysis program would either popup a textbox for that code, or bring up the browser with that webpage loaded, or...? I'm assuming that there would be one html file with the descriptions for all the possible codes, with each code's description as a named anchor inside it. But it's possible that an organization might want to organize them as a separate html file for each code. It's not clear what the best way is to specify these possibilities. (Then again, few organizations document these things today, so maybe we can force a "best" way here?) It needs to be flexible, but not too difficult to implement. Then there's the question of supporting multiple languages. Maybe there should be one or more <help> elements below <session>, one for each language, with pointers to the respective help files.

Example:

<?xml version="1.0" encoding="UTF-8"?> <xlf version="1.9.1" xmlns="http://www.graphicaldynamics.com/xlf1.9.1/"> <session computer="JENNY" ipaddr="172.0.0.34" user="Admin" procid="1668" program="D:\SRC\AutoIntern\AIEngine.exe">77057457675269</session> <logevent dt="2007-04-05T13:04:52-08:00" session="77057457675269" code="0">Scheduler engine starting.</logevent> <logevent dt="2007-04-05T19:15:00-08:00" session="77057457675269" code="5024768">Event started.</logevent> <logevent dt="2007-04-05T19:15:03-08:00" session="77057457675269" code="5024768">Event ended.</logevent> <logevent dt="2007-04-05T20:35:49-08:00" session="77057457675269" code="0">Scheduler engine ending.</logevent> </xlf>

The <logevent> element represents a message that the program writes to the logfile.

The <logevent> tag has these attributes:

Req'd	Name	Type	Default	Description
X	dt	Depends on this session's dtfmt		The current date & time.
	session	xs:string (normally an int)	""	The session ID from this run's <session>.
	id	xs:string (normally an int)	""	A unique ID for this log event, if the program needs to generate one.
	code	xs:string (normally an int)	""	A non-unique code explaining the log event. This can be an error code, or any other non-unique data associated with this log event.
	severity	string or int	"notice"	Severity code. (see below)

Inside the <logevent> element is the text that the program wants to send to the log. The program could also write structured logging data here as an XML fragment.

The <debugevent> element represents a debugging message that the program writes out to the logfile.

The <debugevent> tag has these attributes:

Req'd	Name	Type	Default	Description
X	dt	Depends on this session's dtfmt		The current date & time.
	session	xs:string	""	The session ID from this run's <session>.
	srcfile	pathname	""	Which source file generated the debug event. In C this is generated by the __FILE__ macro.
	srcline	integer	""	Which line in the source file generated the debug event. In C this is generated by the __LINE__ macro.
	code	xs:string (normally an int)	""	This is normally an error code, but it can be any non-unique data associated with this debugging event.
	severity	string or int	"debug"	See <logevent>, above.

Inside the <debugevent> element is the debugging text that the program wants to send to the log.

Example:

<debugevent ...