When to use xml
 

I was reading a different thread about how over used xml is. I have also recently gained a understanding of xml. It excitetes me sexually. (but that beside the point)

I'm a big anti database person and pro file storage. I used to store everything in txt files. Now I am doing that in xml. All my recent projects have used xml and It works great.

Correct me if I am wrong...
Database - Many instances of many different values
xml - longer strings, many values and sub-categorys
txt - few values, extremely long values

Wrong. Properly constituted XML and text files are simply examples of databases. Database != Relational Database.

i view xml as a tool to store properties (ie config files for a program/website). All other data IMHO is stored in a Relational DB.

Then again, that's just my opinion.

Modern database management systems such as MySQL, PostgreSQL, Oracle etc. have huge advantages over text files. They're transaction- and queue-based, so if two applications or scripts (or two instances of the same application or script) want to access the database at the same time, the queries are placed into a queue and dealt with one at a time. With a text file, you could either lock the file, causing the script trying to access the file second to fail, or allow both to write, which could result in something like this:
Not good. Database management systems have their purposes. Read up on them and figure out what those purposes are. Sure, they shouldn't be used for everything, but they're very useful nonetheless.

Well, what about xml? I have never been a big fan of databases. Although I am useing a Database/xml combo on Optimal Source

Did you read my post? XML will suffer from the same problems as standard text files. That's all they are, after all.

I though thats what you ment but I wasn't 100% sure.

When given a more or less compliant set of XML classes (such as with .Net) that support namespaces, XSLT, and Xpath, it's easier to use XML than not. For example, using .Net, I retrieved the forum's RSS feed and extracted the most recent post using just a few lines of code.

However, as noted, XML isn't as suited to replace a database as it is to transfer information. Consider RSS. It can be generated on the fly by a script for the news site/forum/blog/etc, be read by any XML reader (even if it doesn't understand it), be verified against the RSS schema, transformed into something else such as HTML using XSLT, or perhaps displayed in an aggregator. Those are some huge advantages.

Your example of saving rapidly changing data in xml is flawed as Ooble stated. However, consider the possibility of, instead of having your script return an HTML document, construct an XML document on the fly from a database backend. You have the best of both worlds. But what's the big deal with sending an XML document to the client? You are sending the data and only the data. Attach an XSL stylesheet and the client can a) interpret your data how it wants, since for example you may want a desktop app in the future, or b) use the stylesheet to convert the data into the presentation (HTML in this case, though PDF can be useful). Imagine also the savings in bandwidth if only the contents of the page are sent for each request, and the presentation aspect only once (Caching the stylesheet).

I like... no! I LOVE the way xml handles data (c#) root, node, element, attribute it allows you to get right down to the information. Like for the blog I am writing. Each entry has its own xml file (in an offline folder). Every image attachment has a "<image>" node so I just create a xmlList var and for loop though it. I know I can accomplish the same think in a database but I don't like the idea of using a single large column and very few small ones. Now that I think about it... I don't use xml for any rapidly changing items.
The program I am writing (my first with a purpose :) ) stores log type data (time, action, ect.) as xml. That’s only because I want a bunch of options for the ways you can export the data. Does that sound reasonable?

@bja888: Just because you don't like something doesn't mean that it is the best way to do it. I agree with Ooble. Here's an example:
Person A likes looking at his fingers while he types, and averages 20wpm. He doesn't like not looking at his fingers, because then he averages 2wpm with a lot of errors.
Person B likes looking at the monitor while he types, and averages 50wpm.

Just because person a likes looking at his hands doesn't mean it's the best/most effecient way of typing.