Referential integrity is at the core of the relational model. However, the XML notion of integrity is less well defined; linking technologies exist but it's often not clear how best these should be employed, and it's likely application code will be required to maintain integrity. If this is a strong requirement, then a relational or XML enabled database may be the better solution.
If you WANT your XML representation to change when an underlying information item changes (e.g., the customer address in a purchase order should change when the address in the customer database changes), RDBMS-based solutions of one sort or another are generally more appropriate. (Michael Champion)
...XML simply has no good notion of "referential integrity" and that could bite you hard. (Michael Champion)
Also in XML-Deviant
The most common use for, particularly data-oriented, XML is as a means of integration or data interchange between enterprise applications inside and outside the firewall. Middleware has been a growth industry over the last few years, and with the increasing use of XML for this kind of messaging, a NXD becomes a prime candidate for managing the message flow. This is particularly true when messages will not be consumed immediately (and need to be cached), must be logged for legal reasons, or require transaction support.
XML DBMSs *are* solutions for all sorts of interesting problems, especially in a world where XML is the "lingua franca" of electronic commerce. You *can* normalize XML purchase orders that come in from SOAP, Web pages, etc. into 20-30 RDBMS tables, with the help of an army of programmers and DBAs to cope with diversity and evolution... or you can do this much more simply with an XML DBMS. (Michael Champion)
Native XML databases look like a good way to integrate data from a variety of backends, and I think the winning native XML databases of the future will do this transparently and bi-directionally. (Some are already doing it today.) Relational databases may have problems in this area, since the result of integrating data from a variety of sources is likely to be semi-structured data, not structured data. (Ronald Bourret)
I agree very much that integrating data from a variety of backends is one of the promising areas for native XML DBMSes, and that ability to handle semi-structured data is a key benefit.
Some native XML DBMSes are also well-suited to serve the role of a middle-tier persistent transactional distributed cache. (Dan Weinreb)
Whether physical XML or a virtual view, data integration is one of the biggest reasons for XML, and providing database functionality for the XML view is one of the biggest reasons for an XML database. (Jonathan Robie)
...Hide the godawful mess in the back office behind an XML representation cached in an XML DBMS so that other applications don't have to know or care about the voodoo behind the scenes.
...if the godawful mess in the back office is glued to the buzzword-du-jour-MLs out on the wireless web somewhere via some tangled mess of CGI/ASP/JSP/SOAP triggered by diverse XML B2B/B2C/A2A messages, how will you ever keep track of what is really going on from a point of view that management cares about, or to give customers a coherent answer when the widget they ordered from your virtual store didn't show up, but the credit card statement did? Logging the "transient" XML data can help. (Michael Champion)
No doubt there are other factors which could be added to the above list and more opinions that could be added to help weigh one against another. I hope this is a useful starting point for further discussions.