Thanks to the second OP for identifying the root cause in the NiFi Jira. For people researching this today, the cause was the implicit/default Namespace specified in the root node (the 'xmlns' referenced in that element but without a suffix).  In the case of the second poster, their XML started with:   <data xmlns="http://www.media-saturn.com/msx" xmlns: ...   The `/data/item//uniqueID` he was searching for belongs to, more accurately, the "http://www.media-saturn.com/msx" namespace, meaning that - he was supposed to - specify that namespace as part of his XPath expression. The reason that searching for the pathless "//@uniqueType" worked, was because that search searches all namespaces for that XPath expression!   I'm using NiFi 2.0.0 M4 today and I'm pleased to report that it appears to support the XPath 3.0/3.1 notation where the Namespace can be specified inline with the query.  It's not particularly elegant - but it works.  You prefix the Namespace with the capital Letter 'Q' and wrap it in curly brackets; namely:       Q{http://www.media-saturn.com/msx}<single-level selector> To implement his expression, "/data/item//uniqueID[UniqueType='ProdID']/text()" which currently returns an Empty String set for Key 'ProdID4', you would use:   /Q{http://www.media-saturn.com/msx}data/Q{http://www.media-saturn.com/msx}item//uniqueID[UniqueType='ProdID']/text()    I have a suspicion that the second Namespace reference (to 'item' in this case) is not required, since once you've selected/are navigating down the 'data' path of the correct Namespace, you're not likely to jump to another Namespace?  My research indicates that Attributes do not seem to accept Namespace referencing - but again, once you've successfully selected your path I suspect it becomes a moot point. Aside, [1] it would be nice if the NiFi documentation specified the version of the XPath implemented within the Processor. [2] Even better if there were a drop down within the Processor that allowed a developer to select the version of XPath expression desired. ... View more