XML Databases. With the advent of XML, the presentation tier no longer wants objects. They want XML that they can manipulate. So being good middle-tier developers, we start returning XML instead. Now the presentation tier will also pass XML back to us. We parse the XML (not with a DOM right?) and once again update our data in the database.

But now that so many databases are supporting XML natively, does this middle tier become a simple pass through? Connect to the database and pass the XML into it? The database will take care of the rest? This is what I've been struggling with over the past week.

The old adage is don't put a heavy burden on the database because it is the most expensive piece to scale out. But how much of a burden is it? I think that depends on how I store my data. [News from the Forest]

I can't speak towards Oracle, because the only experience I have with XML Databases is SQL Server (thanks for the empathy), but it seems to me that the bigger danger isn't in placing a burden on the database, it's placing a burden on the DBA.  The problem with XML Queries in SQL Server is that it's excruciating to write queries if you care about what your XML looks like (this amounts to a FOR XML EXPLICIT queries chained together with UNION ALL in SQL Server), particularly if you have to work with an existing database structure.  Even if you can control the structure of the database, you're dealing with trying to mimic a tree structure in a relational database.  If you design your database to accomodate this, remember that databases have other functions, like reporting.  This is the same problem as with Object-Relational mapping; you can do it natively, but the end result may be unworkable.  I struggled with this for a while and decided to let relational data be relational and do transformations at the point where it's needed.  SQL Server does have a nifty facility for exposing XML Queries via HTTP or SOAP, but Greg pointed out the problem here.  Exposing your databases directly to a public network is asking for big trouble.

There is such a thing as a heirarchical database, and some people have pointed out that these actually pre-date relational technology.  Maybe this type of database would work for this application, I have no idea.

Later, Justin says:

The one grey area I have is about complex business logic. Simple business logic can be enforced by XML Schema (i.e. value must be between 1024 and 6782 inclusive). But what about complex logic? For example, the platform I work on today allows end-users to send text messages to what we call assets. These assets may or may not have a display. Depending on the display type is how long the text can be. So what do I do? One thing I had thought of is a rule of type XQuery. The processor runs the XQuery that returns me the display information for all the assets the person is sending the message to. Then I can simply go back to my primitive rule engine to figure out whether it is valid or not.

But then I got to thinking that I don't want to dynamically parse these rules everytime a message comes in. That would be a huge performance hit. So what I want to do is be able to dynamically compile a processor for a message that includes all these rules. This way I have data driven rules, but they are executed by compiled code.

I'd say that XML is one solution, but there's more than one way to do it.  I've been reading The Little Schemer, and it strikes me that one of the very cool things about that language is that code is data.  That's a concept that people are coming to (myself included) via XML, especially via XSLT.  The point is that we've been here before.  One way to go is to use XML as the framework for inventing a new way to get to this concept.  The other way is to build on an existing framework.  It's usually more expedient to build something special purpose rather than learn the ins and outs of some existing system, but lately my bias has been to try to do the latter.