To understand XML, you must understand that it is designed to store and transfer data, not display it. As with everything, there's always an exception, in our case it's XHTML which is meant for display. So ignore XHTML for a moment, and clear your mind. You have to separate your data from its presentation, so stop thinking about how you're going to display your data and start thinking about how you're going to store it and access it.
http://www.sciam.com/print_version.cfm?articleID=0008C786-91DB-1CD6-B4A8809EC588EEDF
Feeds are XML in a format which lets anyone make use of your data however they choose, if you offer a feed based on a standard. Which if there's anything beyond hype to "Web 2.0", that's it. You can also tap into someone else's feed and use it as part of your own resource, right? Do you have any say over how your feed appears? No, that's entirely up to the application reading the feed.
http://en.wikipedia.org/wiki/Mashup_(web_application_hybrid)
Another key XML technology, is XSLT, which is a stylesheet for transforming one XML document format into another XML document format. An XSLT transformation can create an output document which bears no resemblance to the source document. Besides storing data in tree form, XML allows that data to be exchanged, and that's what XML (over HTTP) is really about. That's where a schema comes in.
One type of schema is a DOCTYPE. If we all agree to produce web pages which conform to a standard DOCTYPE, and so do those who build web browsers, we can all interoperate, right? So if we want to exchange data in XML format we need to conform to some sort of standard with our markup, just like if it was a web page. In order for me to use your data, you need to tell me something about the parent-child-sibling relationship (i.e. the structure) of your data tree (what elements are used, where, and in relation to what other elements), so that I can have some hope of parsing it meaningfully and using it for whatever purpose I see fit.
Without such a schema, how can you or anyone else validate their markup using your format? Don't enforce rules on me (particularly if you don't define them with a schema) by attempting to lock your data into one or more rigidly-defined representations which make assumptions about how I intend to use the resource I'm retrieving, i.e. render it visually on a display screen.
That forces me to "screen scrape" and rewrite my code every time you change your vision of how I should be viewing your data. Have you ever tried to search a vBulletin thread's markup to filter out all usernames and postcounts? It's pretty tricky to figure out which <td class='smallfont'> tag holds a username, which a postcount, and which holds something else entirely. Like if the first <td> in the next <tr> after a detected username, ever gets changed to something other than postcount, what happens if my script is counting on that table cell in the display representation holding a postcount?
I'd much rather see your data conform to an existing data storage and transfer format, not a data display format like HTML. The semantics of an Atom document's markup describe the stored data, while the semantics of an HTML document's markup describe how it is displayed. So make Atom (or other tried-and-trusted format, perhaps with minimal modification) your data storage format and provide a feed for your resource which allow others to interact with it at the raw data level, in a known format, if they want. The easier you make it for others the better, and the easier you make life on yourself.
http://www-128.ibm.com/developerworks/edu/x-dw-x-atomxsl-i.html
Uche's examples show clearly that a developer who uses these standards devises their own "toolkit" of standard XSLT code for transforming Atom documents into either XHTML or HTML code for output representation. This is XSLT being used as designed, as a "stylesheet" which adds all your personal-taste doodads (I like to use <div id='content'> for example) for any representation you choose to generate by transforming your data.
A developer who uses Atom makes it easier for other developers to integrate their data into external sites ('mashups') using their own standard XSLT vocabulary for transforming the Atom document into (X)HTML but adding their own personal-taste doodads (<div id='centercol'>).
In terms of site maintenance, whether it's you or some other developer down the road, the changes are most likely going to be made not in the nature or structure of the data, or how it's stored, but how it's accessed, manipulated or displayed. To redesign the (X)HTML representation, it's easier to understand the existing XSLT and work with it if it conforms to standards than if it was a one-off deal with no schema which wasn't designed to be re-used.
http://copia.ogbuji.net/blog/2006-01-12/Learn_how_
To redevelop the site in XHTML 2.0 in the future, only the output markup produced by an XSLT transformation is changed, not the XPATH code within the XSLT which accesses the data stored in the Atom document. The XPATH code you write for transforming Atom to some other form of XML stays static, the markup you're wrapping that data in (instead of the Atom tagset) is what changes, sometimes radically, like SVG or PDF.