use xml for a log

[jb.bavoux]

Hello ,
is it a good idea to use an xml file to write a log file?
If i use a file like that:
<LOGFILE>
<LINE>
<TIME>2007-11-28 10:00:00</TIME>
<LOG>something appens</LOG>
</LINE>
<LINE>
<TIME>2007-11-28 10:00:10</TIME>
<LOG>another thing appens</LOG>
</LINE>
</LOGFILE>

I want my log file to be closed each line:
open the file, log, close the file
in order to have a correct file anytime.
My problem is that each time I open the file I have to remove the end
tag, insert my line, then reappend the end tag. I find this not
'clean'.
I could remove the first level tag <LOGFILE>, but in this case is my
file still xml ?
My second problem is that if my program(computer) crash writting the
log, my file is no more xml compliant.
....
<LINE>
<TIME>2007-11-28
EOF
then all my logs in this file become unreadable !!
and next logs will be unreadable too if I continue to log in this file

<LINE>
<TIME>2007-11-28 <LINE>
<TIME>2007-11-28 10:00:10</TIME>
<LOG>another thing appens</LOG>
</LINE>

What do you think about it?

 

[Andy Dingley]

is it a good idea to use an xml file to write a log file?

No. Very much not.

The problem is that well-formed XML must only have one root element,
so you need to manage this element's closure every time you append to
the log. That's just about the opposite of what makes for aa useful
logging format.

Look into log4j, which is just about the best logging tool available
and is for Java. Do this whatever coding language you're using. You
might find an equivalent for non-Java platforms too, but look at the
features log4j offers and see if your chosen logger is giving them to
you in a comparable manner.

 

[Joseph Kesselman]

The problem is that well-formed XML must only have one root element,
so you need to manage this element's closure every time you append to
the log. That's just about the opposite of what makes for aa useful
logging format.

There is a workaround for that, if you want to go this way: Make the
logfile be an XML External Parsed Entity rather than an XML Document,
and have a top-level document which imports the logfile into a top-level
element.

As to whether this is a good idea or not: The ritual answer of "It
Depends" still holds. If the
structure/markup/self-documentation/toolability/portability of XML will
be of value for this specific application, you may want to use XML. If
its verbosity will be a problem and the others aren't significant
advantages for your task, you may not want to use XML.

 

[Stefan Ram]

There is a workaround for that, if you want to go this way: Make the
logfile be an XML External Parsed Entity rather than an XML Document,
and have a top-level document which imports the logfile into a top-level
element.

I am not aware of a rule forbidding to write a sequence of
multiple XML documents into a single file. An XML processor
possibly might be able to then sequentially read these
documents from such a file.

 

[Juergen Kahrs]

I am not aware of a rule forbidding to write a sequence of
multiple XML documents into a single file.

I think it _is_ forbidden to store multiple XML docs into a file.
Joseph Kesselmann already cited the one-root-element-per file.

An XML processor
possibly might be able to then sequentially read these
documents from such a file.

But this problem has already been solved by several users.
While implementing the XML reader extension of GNU Awk,
Andrew Schorr found that he really needed many XML root
elements in one file and he "convinced" our XML library
(based on Expat) to really read an arbitrary number of
XML docs from one file.

 

[Stefan Ram]

Joseph Kesselmann already cited the one-root-element-per file.

I am aware of one post by Joseph in this thread,
where I do not find such a citation.

But this problem has already been solved by several users.

Technically, such an agent might not be an »XML processor«,
but a wrapper calling an XML processor multiple times.
The effect is the same: reading multiple XML documents from
a file.

 

[Joseph Kesselman]

If you look at the XML spec, it says that nothing should appear after
the top-level element (and anything which does appear there should be
ignored).

I already pointed out the pure-XML workaround. Another would be to say
that your file is not itself actually an XML file, and to have some
preprocessing that pulls the XML documents out of it before parsing.

Again, the original question was whether it makes sense do to any of
this, and the answer depends on exactly what your needs are.

 

[Jürgen Kahrs]

I am aware of one post by Joseph in this thread,
where I do not find such a citation.

Correct, it was Andy Dingley who said:

The problem is that well-formed XML must only have one root element,

Technically, such an agent might not be an »XML processor«,
but a wrapper calling an XML processor multiple times.
The effect is the same: reading multiple XML documents from
a file.

Yes, that's the way it was solved.