Versions & Standards

XPath 4.0: What Is in the Community Draft and Why Browsers Will Not Get It

XPath 4.0 is being drafted by a W3C community group rather than a working group. Here is what it proposes, who will implement it, and what it means (nothing, yet) for test automation.

versionsxpath-4.0news

Status

XPath 4.0 is not a W3C Recommendation and is not being produced by a W3C Working Group. It is developed by the XSLT/XQuery/XPath 4.0 Community Group (often called the QT4 CG), a volunteer group that includes several of the people who wrote the 2.0 and 3.x specifications. The group publishes editor’s drafts of XPath 4.0, XQuery 4.0, XSLT 4.0 and the Functions and Operators 4.0 library, and Saxon ships experimental support for many proposals.

Because it is a community draft, there is no fixed publication date and details change between drafts. Treat everything below as “proposed”, and check the current draft before relying on specifics.

What the draft proposes

The themes are ergonomics and filling gaps found in ten years of 3.1 use. Proposals that have appeared in the drafts include:

  • The otherwise operator: $a otherwise $b returns $b when $a is empty, a common pattern that previously needed if (exists($a)) then $a else $b.
  • Focus functions and a thin arrow: shorthand for inline functions over the context item, so mapping over a sequence needs less ceremony.
  • String templates: interpolated strings with backticks, similar to XQuery 3’s computed constructors but for text.
  • Record types: typed maps with declared keys, giving structure to the map-heavy code that 3.1 encouraged.
  • for member and for key: iteration over arrays and maps directly.
  • New functions: fn:parse-html() (an HTML5 parser, which matters for scraping and XSLT over web pages), fn:slice(), fn:items-at(), fn:all() and fn:some(), fn:index-where(), fn:foot() and fn:trunk(), enhancements to fn:sort(), and many more.
  • Switch and typeswitch expressions in XPath, previously XQuery-only.
  • Deep-lookup operator ?? for descending through nested maps and arrays.
  • Annotations and default arguments on functions, and keyword arguments in calls.

Some of these have shipped in Saxon under a “4.0 extensions” flag and in BaseX as experimental features.

Who will implement it

The same set of processors that implement 3.1: Saxon (Java, .NET, C, JavaScript), BaseX, eXist-db, and XSLT 3.0-capable tooling. These are the users of XPath as a programming language over XML and JSON documents.

What it means for test automation

Nothing changes. Browsers implement XPath 1.0 through the DOM evaluate API, and that API is frozen. Selenium, Playwright, Cypress, Puppeteer, WebdriverIO and Appium all rely on it. There is no proposal from any browser vendor to update the DOM XPath engine to 2.0, let alone 4.0.

The one place XPath 4.0 might touch a tester is fn:parse-html(): an XSLT 3.0/4.0 pipeline could load a page and query it with the modern language, which is useful for report generation or scraping in an XML-centric shop. For locators in a running browser, XPath 1.0 remains the whole story.

Why a community group

The W3C XML Query and XSLT Working Groups closed after publishing the 3.1 recommendations in 2017. Continued development moved to the community group model, which has looser process and no formal recommendation track. That is why 4.0 can move quickly and also why it may never carry the “W3C Recommendation” label unless a working group is re-chartered.

Should you learn it?

If you write XSLT, XQuery, or use an XML database, yes, gradually, as your processor adopts it. If you write locators, no. Spend the time on the XPath 1.0 functions and the idioms for what 1.0 lacks.