There is a Java class in the Community Commons module that can handle Xpaths. Here’s a blog post that explains how it is used.
You can search in the Xpath.java file to see all the methods that are possible.
If you have a Date parameter birthdateAfter passed in to a custom Java action, you can use the Xpath class like this:
XPath<myEntity> xpath = XPath.create(Core.createSystemContext(), myEntity.class);
Correction: As Pieter correctly pointed out, the below won't work. I'd expected Mendix to interpret the content of the string variables as input for the Xpath, but it does not. I'm affraid you're down to Java.
*For Xpath constraints on datagrids, you are probably correct. Within (datasource) microflows it seems quite easy to construct your Xpath out of (string) variables. As long as the end-result reads as a boolean.
You could make the following Xpath: [$variable1 >= variable2]
You can probably allow for the '>', '=' and '<' variations easiest with an enumeration and a five-way split, allowing for a microflow with three input parameters for your Xpath:
Does that give anything useful, or did I misunderstand your problem?*
(On a sidenote; if you're going to retrieve through java after all, write a JDBC query with one or more variables. Plenty of examples for those to be found online)
You will agree that a date should be stored as a date. So if it's a String (for any legacy reason), first, I suggest having a after-commit job that converts and stores it as a Date attribute. If that's not preferred, for comparison keep the Year first, then Month, and the Day last, so that 20140131 < 20140201. Comparing 01022014 and 31012014 would be wrong.
If you want to get a list, with dynamic XPATH constraint, it's best to use the data-source as a microflow. You can do all the processing in it, and then show the list. Of course, there are some limitations to it, than using an entity as the source.