EXPath

Machine

XPath is great. Languages based on XPath, such as XQuery, XSLT and XProc, are great. The XPath recommendation provides a frame within which you can write expressions that will evaluate the same way in a lot of processors, written using plenty of different languages, in a lot of different environments, in an XML database, an in-memory processor, on a server or a client.

This support for as many processor kinds as possible is great. But this is has been also a constraint to decide which feature could be included in the recommendation and which couldn't. In addition, experience harvested for several years of using XPath 2.0 pointed out missing features. This project is aimed to provide specifications for such missing features in a collaborative and implementation independent way, as well as delivering implementations of those extensions for as most processors as possible, using the mechanisms for extensibility provided by the XPath 2.0 recommendation itself.

Other projects exist to define extensions for languages tightly bound to XPath, as the famous EXSLT, and the more recent EXQuery and EXProc projects. We think that those projects are really useful and fill a gap in the XML core technologies landscape. But we think also they should not reinvent their own wheels, when working at the XPath level (when that makes sense) would permit to share common work. This is just following the brilliant idea of XSLT and XQuery working groups at the W3C which joined their efforts in defining together XPath 2.0: far from competing with those projects, the idea is to promote collaboration between them.

Standard function libraries

The easiest way to provide new features to XPath is to define extension functions. We plan to provide several function libraries that each addresses a specific area. For instance performing HTTP requests, using WebDAV, reading and writing ZIP files (like EPUB eBook, Open XML and OpenDocument files,) parsing and serializing XML and HTML documents, executing XSLT transforms and XQuery queries, etcetera.

Have a look at the Modules section for available and work-in-progress function libraries.

Packaging System

An important contribution to the X* community is the packaging system of EXPath. The goal is to be able to package any set of X* files into a single ZIP file, with enough information to be installed within a processor. You can for instance use it to deliver an XSLT library of stylesheets that transforms DocBook into HTML, or XQuery files providing support for Google REST Web services. Of course, packaging extension functions (written in a processor-dependent language) is also supported.

This is a work-in-progress for now, but an implementation prototype exists yet for Saxon and eXist. For both those processors, it supports XSLT and XQuery, either standard files or Java extensions. The goal is to support XSLT, XQuery, XProc, XML Schema and various DSDL technologies. See the Packaging System homepage for further details and for implementations.

Extensions to the language

Besides function libraries, we want to address more fundamental XPath issues as well, right at the language level. One obvious example is nested sequences. XPath 2.0 does not provide any way to nest sequences. One can build complex data structures by using XML trees, but then he has to copy the data to that tree, he cannot have complex data structure that preserves all properties of the initial items and nodes.

While this can be defined and implemented through extension functions, this is a typical example of more fundamental changes that require more than a function API documentation to be used.

Those extensions are a good place to experiment with new ideas to improve the current version of XPath.

XPath usage contexts

XPath is a language used embedded in many other languages, as XSLT, XQuery, Java, C#, Perl, Python... But it is also used in different contexts: in a standalone XSLT transform, as part of an XQuery on an XML Database, in a server environment, in a system performing XML streaming or an in-memory-tree-based system.

All those different environments have their own particularities. It would be interesting for instance to define how one can access the HTTP request context info on a web server (getting header values, setting response Content-Type, etc.)

Like the Java Servlet specification does not only define a set of classes and methods, we should here define how the container must behave, what information it must provide and how it must react to some XPath expression evaluation.

Let me in!

This is simple. Read through this website, and join the list. You can help by providing use cases, writing specifications, implement them, or simply by using existing extensions.

The process

From experience with other similar projects, defining extensions is a domain where people have a lot of very useful, interesting ideas. But having fun ideas, or even a coarse-grained idea of what the function prototypes and the specification should look like is just the top of the iceberg. The real work starts here...

We maintain a list of raw ideas, and we are highly interested in getting your own ideas, use case, and how extensions, existing or not, can be used to help you solving your problems.

But the whole point of this project is to be pragmatic and to provide concrete extensions, ready to be used and well-defined. Sounds rational, isn't it? And the best way to help us to help you is to take part in the process. Communicate, send your own use cases, send prototype implementations, write a draft for a specification, report bugs...

The central point of the process is to communicate through the mailing list. So join the list, follow the discussions and see how you could help.