[go: up one dir, main page]

EXPath

Machine

XPath is great. XPath-based languages like XQuery, XSLT, and XProc, are great. The XPath recommendation provides a foundation for writing expressions that evaluate the same way in a lot of processors, written in different languages, running in different environments, in XML databases, in in-memory processors, in servers or in clients.

Supporting so many different kinds of processor is wonderful thing. But this also contrains which features are feasible at the XPath level and which are not. In the years since the release of XPath 2.0, experience has gradually revealed some missing features.

EXPath exists to provide specifications for such missing features in a collaborative- and implementation-independent way. EXPath also provides facilities to help and deliver implementations to as many processors as possible, via extensibility mechanisms from the XPath 2.0 Recommendation itself.

Other projects exist to define extensions for XPath-based languages or languages using 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. Nevertheless, working at the XPath level allows common solutions when there is no sense in reinventing the wheel over and over again. This is just following the brilliant idea of the W3C's XSLT and XQuery working groups, which joined forces to define XPath 2.0 together. EXPath purpose is not to compete with other projects, but collaborate with them.

Standard function libraries

The easiest way to improve XPath is by defining extension functions. We plan to provide several function libraries. Each library focuses on a specific area. For instance performing HTTP requests, using WebDAV, reading and writing ZIP files (like EPUB eBooks, Open XML and OpenDocument files,) parsing and serializing XML and HTML documents, executing XSLT transforms and XQuery queries, etcetera.

Check the Modules section for function libraries (some are available and some are still work-in-progress).

Packaging System

An important contribution to the XML community is the EXPath Packaging System. The goal is to be able to package any set of XML Core Technology files in a single archive, with enough information to be installed by a processor. You can for instance use it to deliver an XSLT library of stylesheets for transforming DocBook to 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.

Several processors implements the Packaging System, either natively or through third-party, open source implementations (for now: BaseX, Calabash, eXist, Qizx and Saxon). The packaging format supports XSLT, XQuery, XProc, XML Schema and various DSDL technologies, and is extensible (e.g. to support native language extensions). See the Packaging System homepage for further details.

XPath usage contexts

XPath is embedded in many other languages: XSLT, XQuery, Java, C#, Perl, and Python, to name a few. But it is also used in different contexts: standalone XSLT transforms, as part of an XQuery on an XML Database, in server environments, in XML streaming systems as well as in in-memory-tree-based systems.

All of these different contexts have their own peculiarities. It would be interesting for instance to define how one can access the HTTP request context info on a web server (to get header values, set the Content-Type for the response, and so on).

Just as the Java Servlet specification does not only offer a bunch of classes and methods, we should here define how the container must behave, what information it must provide and how it must react to XPath expression. The Webapp Module defines such a web container.

Let me in!

Helping is simple! Read through this website, and join the list. Providing use cases, writing and improving specifications, implementing them, or simply using existing extensions are all great ways to help.

The first thing you want to do is probably to have a look at the list of available modules.

The process

From experience on 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. We would love to get your own ideas, use cases, and feedback about existing extensions. How an extension helped or failed to help are both valuable kinds if feedback.

But this project is all about providing pragmatic, concrete extensions: well-defined, and ready to be used. Sounds rational, doesn'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 project centers around discussions on the mailing list. Join the list and tell us what you think and how you would like to help!