This article introduces the concept of document-centric XML processing and a set of emerging document-centric capabilities such as cutting, splitting, and splicing documents at the byte level. It also explains how it solves one of the most fundamental technical issues hampering enterprise SOA and XML application development: the redundant serialization and de-serialization of object-oriented XML processing models such as DOM.

Public Enemy #1: DOM's Problem of Modifying XML
If a DOM-based application modifies a particular text node of an XML document, the following steps are needed to accomplish that:

1. Decode characters
2. Create string objects by taking apart the input document
3. Allocate node objects to build the DOM tree
4. Navigate to the text node (manually or by XPath)
5. Attach a new text node
6. Encode characters
7. Byte concatenation
8. Garbage collecting node and string objects

If you focus on the objective, I think many readers will realize that the process outlined above doesn't really make sense. It is, in fact, absurd. DOM processing incurs at least the following three round-trip overheads in those steps:

• Every time a character is decoded, it eventually needs to be encoded again.
• Every time a document is taken apart of any change, it needs to be put back together (by concatenation).
• Every time an object (e.g., strings, nodes, etc.) is allocated, it will eventually go out of scope and be garbage collected.

Because those round-trips pretty much restore the document to the original state, they are nothing but a waste of CPU cycles and memory. Notice that modifying a text node can be done far more efficiently by humans using a text editor. To edit a text node, just open the document with NotePad, move the cursor to the text node, make the change in-place, and save it. This time, the update is "incremental," meaning it does not touch irrelevant parts of the document. If we, humans, can edit XML like this, why can't XML parsers?

To me, the answer to this question reveals some of the deep-rooted technical problems in software development today. Below are some of my observations on this topic:

• It significantly impacts your application performance: When applications process XML in a read-only fashion, the base-line performance is decided by XML parsing. If applications both read and write XML data, the base-line performance is typically cut in half (as serialization and de-serialization are equal in performance).
• It is a common, but deep, problem: Have you wondered, given that XML is ubiquitous, why nobody seems to be complaining? One way to look at this is since this is the way things have always been, everyone seems to get used to it. To make matters worse, solutions don't exist to make the problem look obvious. We end up with a ubiquitous issue that is surprisingly non-obvious and from which there is almost no escape.
• Hidden from OO perspective: If you live in a pure OO world, the redundant de-serialization/serialization process - the textbook approach of XML processing - is very much the right thing to do. This problem is again hidden.