Main Page

From EXPath Community Group

The mission of this Community Group is to lead extensions to XPath and related technologies.

Continuing effort

This Community Group is a continuation of the previous effort started by Florent Georges, on http://expath.org/. That website, with this wiki, are the main entry points and reference for EXPath.

EXPath defines extensions to XPath, XSLT and XQuery. The most typical extension is a module, that is a set of functions, which cannot be implemented in plain XQuery or XSLT, but needs to be implemented as an extension.

A module is defined in a specification, maintained by an editor, by following a community-driven approach. Modules are implemented directly in different processors, or by third-party implementation. See the page Modules for a list of existing modules, and their implementation for various processors.

Content

This sections tries to give an overview of what is on this wiki, and where.

  • Modules contains the list of modules defined by EXPath, and their status.
  • Definitions contains the definition of some terms, concepts or related projects.
  • Engines is a list, description and comparison of various XPath engines.

The following pages are interesting for editors and active members of the community:

  • General information for Editors
  • Process to propose new modules and help
  • Naming lists the naming rules and conventions.
  • Tests defines how to test modules, and other test suites information.

Process

This section provides information about the processes in the EXPath project. The main idea is quite simple: the atomic piece of work is the module, and each module has its own maintainer, who is the single point of contact for this module.

A module is a single facility or a consistent group of facilities. For instance, the HTTP Client is one module, and defines only one function. The ZIP facility is another module, and defines a library of related functions. But the packaging system is also one module, though it defines a complete system for packaging and library deployment. Anyway, modules are agreed upon on the mailing list.

Each module has its own maintainer. He/she is in charge to coordinate the tasks related to this module, to lead the discussions in the mailing list, update the relevant wiki pages, reflect the discussions within the relevant specifications and coordinate the different implementations and the website pages related to the module. He/she can delegate some of those tasks to someone else.

To propose a new module, just start the discussion on the mailing list. The goal here is to see if other people are interested in the new functionalities you are proposing, and to show that you are ready to help in this area. The first step is not only to propose the idea, but also to propose a draft spec. Even just a few paragraphs, but at least enough to start discussing about something people can refer to.