This proposal defines a packaging system for various core XML technologies: XSLT, XQuery, and XProc. The goal is to define it in a way enough generic so to adapt it to other technologies in the future (such as XML Schema, XForms, etc.) using the same framework. Besides enabling the delivery of libraries written in standard XSLT, XQuery and XProc, it provides support for extensions specific to some processors, as well as enabling new processors to be supported by using the same framework.
Must be ignored, but is required by the schema...
revisiondesc
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.
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...
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 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
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:
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
Here is the description of the standard file kinds supported by this specification, and how they contribute to the package descriptor document type.
An XSLT file is associated a xsl:import) to import the XSLT file provided in
the package. This file is configured with the element xsl.
The element file contains the path to the file within the package
structure, relative to the library directory. Both elements import-uri
and file are of type anyURI.
An XQuery library module is referenced by its namespace URI. Thus the
xquery element associates a namespace URI to an XQuery file. An
importing module just need to use an import statement of the form import module
namespace xx = "<namespace-uri>";.
Note that there is no way to set any location hint (as the at clause in
the import statement.) To use this packaging system, an XQuery library module must be
referenced by its target namespace.
An XProc pipeline, like an XSLT stylesheet, is associated a p:import statement.
An XML schema can be imported using its target namespace. Like for XQuery, there is
no way to use any schemaLocation instead. There is neither the ability
to set several files as several sources for the schema. If the schema is spread over
multiple files, there must be one top-level file that includes the other files.
(TODO: Should we support schemas with empty target namespace? I am sure this is a good idea in a packaging system...)
A RelaxNG schema, like an XSLT stylesheet, is associated a public import URI, aimed
to be used in an
A Schematron schema is associated a public URI.
An NVDL script is associated a public URI.
Documentation (like result of XSLStyle or xqDoc) is not taken into account in the packaging format, though that could be used by IDEs for instance to provide documentation for functions in an editor with a live completion feature. Some support for documentation can of course be added as a product-specific feature to the package descriptor.
... [ package structure + package descriptor ] ...
Bla-bla...
Bla-bla...
... classes for
Bla-bla...
Bla-bla...
Bla-bla...
Bla-bla...
Bla-bla...
Bla-bla...
Bla-bla...
Bla-bla...
(or RNC?)