When I gave my introductory presentation on the use of XPath and XmlSearch() in ColdFusion, I stated that the use of a trailing slash at the end of your XPath path was optional. For example, the XPath:
//datum[ text() = '1.1' ]
... would return the same nodes as this XPath value that ends with a trailing slash:
//datum[ text() = '1.1' ]/
As such, I just assumed that this trailing slash was optional. And, it never caused a problem ... until this weekend. I was trying to calculate two simultaneous node sets using the "|". This is like an "or" statement between two paths used when searching the ColdFusion XML document object model. For example, I was trying to do this:
//datum[ text() = '1.1' ]/ | //datum[ text() = '3.2' ]/
Notice that both XPath values have trailing slashes and are separated by the pipe (|). When faced with this path structure, ColdFusion kept throwing the following error:
An error occured while Transforming an XML document. A location step was expected following the '/' or '//' token.
After figuring out what the problem is, the error seems obvious, but I have been thinking about it all weekend and just came up with the answer. Removing the trailing slashes fixes the problem:
//datum[ text() = '1.1' ] | //datum[ text() = '3.2' ]
This XmlSearch() function now executes fine and returns a node set that contains the nodes found from both XPath values. I am not sure why the trailing slash works sometimes but not other, but I guess going forward, I should just leave it out.
Looking For A New Job?
- 100% Remote - Sr ColdFusion Developer at Short's Travel Management
- ColdFusion Developer Opportunity at Cavulus
- IS Sr. Systems Analyst - Web Development at Nationwide Children's Hospital
That's interesting. I'll have to look over the XPath spec and play around with some other tools to see why that would happen.
As a side note, I think your expression is probably better written as:
//datum[ text() = '1.1' or text() = '3.2' ]
Assuming the same datum.
You are right, my example would be better done as a compound predicate. However, ultimately, what I was trying to do when I came across this problem was select both a parent node and it's child into the top level node set. There was logic in the XPath to determine if the child node existed (as only wanted to get parents that had children).
Ultimately, I wanted to be able to loop over the node list with step="2" and then [i] == parent and [i+1] == child. It would have made the looping logic very easy.