Packaging System

1 Introduction

XSLT, XQuery and XProc are amazing programming languages. But they lack a large choice of libraries, and when such libraries do exist, this is a challenge to install. There is no automatic install process, the rules are different for each processor, library authors do not follow the same rules regarding the info they provide, the cataloging, the way they reference third-party libraries, etc.

All those problems (well, most of them) can be addressed by a packaging system that would be broadly adopted by processor vendors and library authors. The cornerstone of such a system is the packaging format: a description of the information to be provided by the library authors and how to provide and structure them.

2 Editorial notes

• Should the package system define a set of XPath functions? Instead of just defining the package format and letting everything else as implementation-defined, should it in addition define a module of functions to install, delete, and more generally manage packages from within a processor?

  Drawback: potential problems if the processor requires to be stopped?

  Advantages: enables writing tools on top of the system (one single graphical package manager for one system, simply using the XPath functions, as well as easy integration within IDEs; or even other systems could be more easily be built on top of it, like a packaging system for XRX applications for instance.)

• Should it be possible to have two different kinds of files with the same public URI? Put another way, should we have a different URI space for each kind of files? I think this would be necessary for instance to enable deploying a package with both an XML schema and an XQuery library module with the same target namespace. I am not sure this is a best practice, but I am sure that will lead to at least one company's standard practices...

3 Concepts

A library is a set of files fulfilling a common purpose. An XSLT library can for instance provide a set of template rules and functions to help formating a particular XML document type. A package is a way to bundle those files into a single ZIP file, following a defined structure and providing more information within the package descriptor. The package descriptor is a plain XML file, named expath-pkg.xml at the root of the ZIP file, and containing information about the library (like its name and its version number) and about the files it provides and how to reference them (for instance stylesheets and query modules.)

The ZIP file structure (aka the package structure) must have exactly two entries at the top-level (aka the root): the package descriptor and one directory entry. This directory contains all the library files, and all file references in the package descriptor are relative to this directory. This directory is called the library directory.

All the elements in the package descriptor are defined in the namespace http://expath.org/mod/expath-pkg. All the elements defined in this specification or used in samples and in text are in this namespace, even if no prefix is used. The root element is package, and contains exactly one child element module:

<package>
   module
</package>

<module name = NCName
        version = string>
   title,
   (xsl
   |xquery
   |xproc
   |xsd
   |rng
   |rnc
   |...)+
</module>

name is the library name. The top-level directory in the package structure must have the exact same name. The module has also a version number, and a human-readable title. It then provides information about one or several files. In addition to those standard file descriptors, it can also contain elements specific to some processors (for instance an element for Saxon, eXist, etc.) Details are provided below.

The files configured in the module are the files exported by the module. But the whole library directory must be preserved. Indeed, it can contain other, private files, aimed to be used only from within library files, not from the outside.

4 Standard X* files

Here is the description of the standard file kinds supported by this specification, and how they contribute to the package descriptor document type.

<xsl>
   import-uri,
   file
</xsl>

<xquery>
   namespace,
   file
</xquery>

<xproc>
   import-uri,
   file
</xproc>

<xsd>
   namespace,
   file
</xsd>

<rng>
   import-uri,
   file
</rng>

<rnc>
   import-uri,
   file
</xrnc>

<schematron>
   import-uri,
   file
</schematron>

<nvdl>
   import-uri,
   file
</nvdl>

5 Processor-specific files

Bla-bla...

6 Extensibility

Bla-bla...