I think this has been discussed before to some extent. regardless, it is like beauty, it is in the eye of the beholder.

If you are comfortable using php, or asp for that matter, or any other form of db, and it works for you, I say stick with it. XML is easy to edit and style with XSL and CSS, but it is not perfect for all db driven sites. I use it to display listings on a directory site and it works great for that. I use it on another site which is e-commerce, and it works well for that too. I think it biggest disadvantage over a normal db is search ability, but that is my opinion.

Marshall

Marshall -

Thank you for your input; so, in "some/many/most" real-world applications, XML is used to replace a db? Or it's used to format db output?

Here's where my ignorance will shine though as I am going to say you can't use an XML file to format a db as it is a db in itself. Anyone - correct me if I am wrong.

I am by no means a php expert and use asp to parse my xml files and xsl to format the output and css for styles in the HTML markup.

Did you check the W3 School tutorial [w3schools.com] on XML?

Marshall

Marshall -

Thanks for the W3Schools link. Will take a look and see if that clears the fogs.

Appreciate the input!

Neophyte

XML is often used to cache frequently accessed database information.

When we display our class schedule, rather that querying the database for every user request - we access an XML version of the data that has been placed on the web server. The XML is automatically updated whenever we make a change to the schedule. This greatly reduces the load on the database server and allows the website to function even if the database server is down.

So is the XML file parsing the db or, is there a script that parses the db to the xml or, is it done manually?

Marshall

Here's what I use XML for. If you are interested in seeing the stuff in action, I can SM you a link to a site under development, but most of the XML/XSL is invisible. You just see the results.

I have a site with a large database of events that occur regularly. Each of these events has address information, special agenda information, time, date, etc.

I developed a special XML export of this DB. It isn't RSS; it's custom XML, described by a schema.

The site is one belonging to a central organization.

I have written another site, expressed in WordPress. I have plugins written that execute XSLT scripts on the XML in order to produce a "pinned map," using Google Maps API [google.com]. In order to do this, I have an XSLT script that transforms the XML feed to JSON objects.

I also directly transform the XML to XHTML in order to produce a list of events, and to provide single event detailed listing.

Last, but not least, I have an XSLT script that transforms the XML into WML 1 and WML 2 for mobile phones.

I don't use XML to store the data. I use it to transmit the data across servers. The central server is unable to run XSLT, but you don't need anything fancy to create XML. The WordPress server can run XSLT.

Marshall-

A script creates the XML periodically from the db. The website only sees the XML.

I use XML for:

1) configuration settings. When I build a multi-purpose application, I'll keep application config settings in XML so they can be changed easily when it's installed on another site.

2) REST web services. I'll turn frequently-used scripts into a web service, especially if they are going to be offered as an API to the public. A good API doubles as a DAL (data access layer) even within the same application. if the service is going to be used in AJAX applications, I'll make the same service also available in JSON.

3) caching complex SQL jobs. I'll sometimes store really heavy calculations in an XML format so I don't overtax the SQL database with repeated queries.

4) SQL output as native XML. Occasionally I'll build a stored procedure that outputs XML instead of a record set. Some databases do this very efficiently. I'd do this most often if the data is going to be offered as an API, or if the result will be rendered on the page without further ado.

5) internal application objects. It's sometimes easier to buid a complex data object as XML, especially when it's going to be rendered on the page soon after. Forego the loops and ifs and prints, and do it with an XSLT transformation instead.

6) separation of application and presentation layers. When the engine just outputs XML, I can build multiple skins for an application with XSLT and CSS. I contribute to one large project done this way: all page requests start with an engine that receives a request and outputs pure XML. Depending on the skin chosen, it introduces the XML to a discreet collection of XSLT, JS, CSS, JPG/PNG/GIF files which comprise the "skin". output to the user is all valid XHTML.

7) hierarchical data. Hierarchical data like a sitemap or a category tree is a no-brainer for XML.

8) user-entered data. Rarely, but worth mentioning. If you're accepting complex data sets from an uploaded file, XML is a good format to accept. I prefer XML instead of CSV because it can be validated with a Schema and/or DTD.

i almost forgot:

9) importing data into Flash. Flash has a pretty decent XML parser built-in. it's been capable of Asynchronous Actionscript And XML (AAAX?) since version MX. Great for displaying those high score lists!

I often use XML files as my database(one file as one table) when a project is small and/or I don't know what technology the final implementation is. The great thing about using XML in a LAMP enviroment is that it is more secure than SQL, if you know what you're doing. What I've done is created an XML processing object which behaves like a database query for data reading and rewriting.

Also, I store formatted documents in my database using XML format, along with other bits and pieces such as sitemaps, templates and widgets.

I build all my web interfaces as a DOM Document these days so, XML is the defacto native format on my web app framework. With this approach you can consider DOM nodes to be like bits of Leggo which clip together to form a finished webpage/document. Which, is a lot more powerful than the old school, series of concantenated strings approach.