I have a xml file:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE agent SYSTEM "http://www.someUrl.com">
<myData>
<service>
<description>Description</description>
</service>
<courier>
<listener port="55556"
/>
<mainService
name="Some Name"
port="55555"
/>
</courier>
</myData>
and I want to get the value of the listener port variable using nodejs. According to the docu for SaxonJs SaxonJS.XPath.evaluate is the method I need. It requires a query and a document node object. When I convert my xml file into dom object I get the error message : "Uncaught TypeError TypeError: Cannot read properties of undefined (reading 'length')"
const saxonJs = require('saxon-js');
const fs = require('node:fs');
const jsdom = require("jsdom");
var xmlFile = fs.readFileSync(xmlFilePath, 'utf8');
var doc = new jsdom.JSDOM(xml);
var xpathQuery = '//listener/@port';
var result = saxonJs.XPath.evaluate(xpathQuery, doc);
Do you need to use XPath in particular? Since you have JSDOM, I'd just query using a CSS selector:
You can use
JSDOM.fromFileto read from disk without usingfs(although that's fine too).If you don't mind querying with CSS, Cheerio provides an even cleaner option:
If you really want to use XPath, you can do it in JSDOM (note the
[@port]change to select by attribute on thelistenerelement):or selecting the attribute string value directly:
Note that using both JSDOM and Saxon is probably unnecessary, since Saxon can parse the XML without support from JSDOM. Pick one or the other.
I'm not familiar with Saxon, but at the time of writing, JSDOM has 22,000,000 weekly downloads and 831 questions on SO, while saxon-js has 20,000 weekly downloads and 61 questions on SO. My instinct is to avoid the dependency on saxon-js if possible, since small packages tend to become unmaintained, and are harder to find support for on Stack Overflow and GitHub if you run into problems.
On the other hand, apparently JSDOM XPath has "quite a few issues", and JSDOM is (probably) a much more complex library, so you may have a good reason for pursuing Saxon if it's a better tool for your particular use case (i.e. you need robust XML support, don't care about the whole DOM API, and don't mind the support/maintenance cost of using a less popular library).