Text Nodes Do Not Always Exist In A ColdFusion XML Document

Yesterday, I was working on an audit tracker that stored updates in an XML document when I came across an XML behavior that I didn't know about. Apparently, not all element nodes in an XML document have to have a nested text node. Now, when you think about this, this makes some sense; however, when you look at a ColdFusion XML document, it can certainly be confusing. To examine this, let's create a simple ColdFusion XML document:

Here, our Hayden Panettiere girl XML object has a number of nested fields. Of these fields, some have nested text values and some don't. However, even though that is the case, here is what the CFDump of the XML looks like:

Notice that even though some element nodes have text and other don't, from a ColdFusion XML Document Object Model (DOM) standpoint, they all have XmlText values; some of them just happen to be empty strings. This kind of structure might lead you to believe that all element nodes have a text node element inside of them, and, in fact, this is what I used to think. As it turns out, though, this is not true - the XmlText attribute in the ColdFusion XML DOM has nothing to do with whether or not a text node actually exists.

To prove this, let's use XmlSearch() and XPath to select all nodes in the ColdFusion XML document that have a nested text node. We can do this by using the predicate [ text() ]. This predicate merely checks for existence and is not concerned with actual value:

After selecting all nodes that have a nested text node and outputting those node names, we get the following list:

• girl
• name
• age
• description

Notice that nodes Height and Weight are not getting selected. This is because they have no text node. And, if you look up at my original XML, you will see that matter of factly, the Height and Weight nodes open and close with no text data in between. Because there is no text data, there is no text node; so, while the ColdFusion XML DOM has XmlText values for these nodes, realize that they are not actually parents of anything.

While this might not seem like such a problem, this can cause things to be a little kinky when you actually need to query an XML document based on text values. A non-existing text node is very much like a NULL value in SQL; it's an "unknown" value. And, because it's an unknown value, you can't compare data do it. This goes for both testing equality as well as inequality. To demonstrate this, let's get all nodes whose text value is either equal to or not equal to, "Blam":

Instinctively, you might think that this will return all nodes of the XML, right? I mean, anyone who's taken math knows that something and NOT something should return the "universe". However, just as with SQL and NULL values, because some of our text nodes don't exist, they cannot result in a known comparison whether that be a test of equality or inequality. And, in fact, when we output the selected node names:

• girl
• name
• age
• description

... we see that, again, neither the Height or Weight element nodes were selected. Imagine trying to select all nodes whose text value was NOT something. If you didn't realize how this worked, you might spend a heck of a lot of time banging your head against a wall trying to figure out why only some of the expected nodes were being selected.

If you work with a lot of XML, you probably already know this; but, if you have only worked with the ColdFusion XML Document Object Model (DOM), it may not be immediately obvious that the existence of an XmlText attribute does not mean that there is a corresponding text node in the DOM. I know that I didn't realize this, and it probably took me a good 30 minutes to figure out what the heck was going on.

What Other People Are Searching For

[ local search ] select text nodes with xpath coldfusion
[ local search ] xpath cannot find text node
[ local search ] xmlsearch() cannot find text node

You Might Also Be Interested In: