The presentation of this document has been augmented to identify changes from a previous version. Three kinds of changes are highlighted: new, added text, changed text, and deleted text.
This document is also available in these non-normative formats: XML and Revision markup.
This proposal defines a packaging system for various core XML technologies: XSLT, XQuery, and XProc. The goal is to define it in a way generic enough 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.
1 Introduction
2 Concepts
3 Package descriptor
3.1 Overall structure
3.2 Components
3.2.1 XSLT
3.2.2 XQuery
3.2.3 XProc
3.2.4 XML Schema
3.2.5 RelaxNG
3.2.6 Schematron
3.2.7 NVDL
3.3 Not supported file kinds
4 Processor behaviour
4.1 XProc pipelines
5 Versioning and dependency management
5.1 Package dependency
5.2 Processor dependency
5.3 Dependency enforcement
6 On-disk repository layout
7 Example
8 Extensibility
9 Editorial notes
A Package descriptor schema
B Package list schema
C References
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 is 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.
A package is a set of files fulfilling a common purpose. A package could for instance provide XML schemas for a particular document type, alongside a set of XSLT stylesheets to format the same document type to HTML or XSL-FO. Or a package can simply provide an XQuery library module containing a set of functions (directly supporting the notion of library). Those files composing a package (stylesheets, schemas, pipelines, queries, etc.) are called its components.
A package has a unique name (a URI) as well as a convenient short name, also known as its abbrev (an NCName), used in contexts where a URI is not suitable (or simply not convenient) and where the uniqueness of the name is not necessary. A package has a set of dependencies too. A dependency is another package, identified by its full name, a package depends on. [[ TODO: Introduce other kinds of dependencies, for instance collections... ? ]]
A package provides all those infos as well as its components as a single file. This is then very convenient to organize packages, publish them, give them to a processor to install them, etc.
A component can be of one out of several types: an XSLT stylesheet, an XML schema, a RELAX NG schema, an XProc pipeline, but also any other type a particular implementation chose to support. It is identified by a public URI. This public URI is used to access the component from the outside of the package. Each component type has its own URI space, within which a component's URI has to be unique (so two different components can have the same public URI if they are of different types, but this is not recommended).
All the components composing the package, alongside an additional package
descriptor, are used to create a ZIP file. This file is the
physical package, and can be used to distribute the package to the users. The package
descriptor is a plain XML file, named expath-pkg.xml at the root of the ZIP
file, and containing information about the package (like its name and its version
number) and about the components it provides and how to reference them.
The package descriptor is an XML file, named expath-pkg.xml and located at
the root of the ZIP file. It describe the whole package, and all of its components.
Alongside this descriptor, the root of the ZIP file contains a directory named after the
module name (see below) abbrev,
which contains the components and any other file the package needs. All the relative
URIs used to identify components are relative to the package directory.
See A Package descriptor schema for anormative
schema.
Note:
Because this package format is designed to be extensible and used as a building block by other specifications, the ZIP file can contain another entries at top-level. They are just ignored when the package is deployed as a simple package following this specification.
All the elements in the package descriptor are defined in the namespace
http://expath.org/ns/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 a
name, an optional list of dependencies to other packages, and exactly one child
element module , besides some naming
and versionning attributes, a title, an optional home URI, an optional list of
dependencies on other packages and on processors, and a list of
components:
<package name = uri> dependency*, module </package> <dependency name = uri> empty </dependency>
name is the name of the package. A package is named using an
absolute URI, except any file: scheme URIs (most frequent choices are
http: and urn: scheme URIs). Dependencies are set by
using the name of other packages this package depends on. The module
content model is:
<module name = NCName
version = string>
title,
(xslt
|xquery
|xproc
|xsd
|rng
|rnc
|...)+
</module>name is a short module name. The package directory 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 components. In addition to
those standard components, it can also contain elements specific to some processors
(for instance an element for Saxon, eXist, etc.)
All the elements in the package descriptor are defined in the namespace
http://expath.org/ns/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, besides some naming
and versionning attributes, a title, an optional home URI, an optional list of
dependencies on other packages and on processors, and a list of components:
<package name = uri
abbrev = string
version = string
spec = string>
title,
home?,
dependency*,
(xslt
|xquery
|xproc
|xsd
|rng
|rnc)*
</package>name is the name of the package. A package is named using an
absolute URI, except any file: scheme URIs (most frequent choices are
http: and urn: scheme URIs). abbrev is the
package abbrev, and version its version. The package directory must have
the exact same name as the abbrev. spec is the version of the packaging
specification the package conforms to. The current specification requires the package
to use the spec number 1.0 (no forward compatibility rules are defined,
a processor conforming to this specification has to generate an error if the spec
number is different than the string 1.0). The package then contains a
title, which is a plain string, intended to be a simple description of the package
for humans, and a home which is a URI to find more informations about the package. It
then contains the list of its dependencies and the list of its components.
<dependency package = uri
processor = string
versions = string
semver = string
semver-min = string
semver-max = string>
empty
</dependency>Dependencies are set by using the name of other packages this package depends on. The dependency can also define the version of the package or the set of processors it depends on by using one of the few available strategies; see 5 Versioning and dependency management for a complete description of them.
This section describes the standard component kinds supported by this specification, and how they contribute to the package descriptor document type.
An XSLT file is associated a public import URI. This is the URI to
use in an XSLT import instruction (aka xsl:import) to import the XSLT
file provided in the package. This file is configured with the element
xslt.
<xslt> import-uri, file </xslt>
The element file contains the path to the file within the package
structure, relative to the package 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>";.
An XQuery main module is associated a public URI. Usually an XQuery package will provide functions through library modules, but in some cases one can want to provide main modules as well.
<xquery> (namespace |import-uri), file </xquery>
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 public import
URI, aimed to be used in an XProc p:import statement.
<xproc> import-uri, file </xproc>
An XML schema can be imported using its target namespace. Like
for XQuery, there is no way to use any schemaLocation
instead. It is not possible 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.
<xsd> namespace, file </xsd>
<xsd> (namespace |import-uri), file </xsd>
(TODO: Should we support schemas with empty target namespace? I am not
sure this is a good idea in a packaging system...) (TODO: This does not support
xs:redefine, as it requires a hint, not a target namespace)
The import-uri can be used to define a schema location for
this schema component. This can be useful for schema without target namespace, or
for some specific usages, like when using xs:redefine.
A RelaxNG schema, like an XSLT stylesheet, is associated a public import URI, aimed to be used in an import statement (either the include element for an RNG schema or an import directive for an RNC schema.)
<rng> import-uri, file </rng> <rnc> import-uri, file </rnc>
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.
A processor is any program that use packaged components. For instance, an XSLT processor uses XSLT stylesheets (as well as XML schemas for an XSLT 2.0 SA processor), an XML database can use XQuery modules, XSLT stylesheets or any other kind of component, etc. But processors include also IDEs, editors, and any program that could want to use packaged components and that supports this specification.
The installed package list is implementation-defined. Each implementation (for a specific processor) can define its own way to install and remove packages, as long as it properly documents it. A processor should use, when appropriate, the on-disk repository layout as defined below.
Whether or not such a repository exists (or several repositories), the implementation must define an installed packages list. How this is done is outside the scope of this spec. An XML IDE could provide a way to select packages to activate for a specific scenario, or a web server container could activate packages on a per-web application basis.
When a reference to a file of a specific kind is done via an absolute URI, a processor must look up for this URI in the corresponding URI space in the repository. How the repository is set to the processor is implementation-defined (a processor can also use a list of repositories, and enable or disable some libraries in any implementation-defined way.)
The URI space to use is defined by the nature of the reference. An XSLT
href attribute on xsl:import will use the xslt
URI space, while it will use the xsd space for
xsl:import-schema.
An XProc processor in particular has to pay great attention to the space it uses
regarding the step that is being evaluated. Any xsl:import instruction
encountered on the stylesheet port of the step p:xslt has
to be looked for in the xslt space (regardless if the stylesheet
document is inlined in the pipeline, computed, loaded from the file system or
retrieved from the Internet, or if the containing stylesheet has been imported
itself.)
The XProc elements p:document and p:data, as well as the
step p:load are handled specially. They can be used to access any kind
of resource, including but not limited to components in a repository. The user has to
tell explicitly the processor what kind of component is looked for by using the
pkg:kind extension attribute. For instance, a stylesheet can be
loaded from a repository as input to the step xslt as following:
<p:xslt>
<p:input port="stylesheet">
<p:document href="..." pkg:kind="xslt"/>
</p:input>
...
</p:xslt>Every package has a name (a URI) and a version number. It can also have a set of dependencies on other packages, identified by their names. Each dependency can also define a specific version (or range of versions) of the package it depends on. In addition to depending on other packages, a package can also depend on a specific processor (or on one among a set of specifc processors). This section uses the following example package to illustrate those concepts:
<package name="http://example.org/app" version="1.0" ...> <dependency package="http://external.org/library"/> <dependency package="http://partner.com/lib-2" semver="2"/> <dependency processor="saxon" version="pe"/> <!-- rest of package descriptor skipped --> ... </package>
At first glance, we can see that this package (which is named
http://example.org/app and has the version number 1.0),
depends on the package http://external.org/library (no specific version),
on the package http://partner.com/lib-2 (version 2, whatever minor revision
numbers) and on the Saxon processor, Professional Edition. The rest of this section
explains in details the rules behind those dependencies, how to represent them, and
their semantics.
The remainder of this section will use the term primary for the current package, described by this package decriptor, and secondary for a package it depends on.
A dependency on another package (usually called a library), is represented
by the element dependency, with an attribute package which
is the name of the library the package depends on. The dependency can be versioned;
that is, only some versions of the library are acceptable for this package.
The versionning attributes are versions, semver,
semver-min and semver-max. They are all mutually
exclusive, except semver-min and semver-max. If no
versionning attribute is set on the dependency, any version of the secondary package,
identified by its name (the URI in the package attribute), is
acceptable. If the versions attribute is used, it defines the exact set
of acceptable versions for the secondary package, separated by spaces.
The other versionning attributes use [SemVer] to define the set of acceptable versions for the secondary package. We use only the syntax of SemVer, and define in addition the format of a SemVer template as being either a SemVer version number or a subpart of it (i.e. only the major version, or the major and the minor versions, or the major, the minor and the patch version). For instance 1.9 is a valid SemVer template (because it does not have any patch number), while 1.9.0 and 1.9.23 are actual version numbers compatible with this template.
If the semver attribute is used, the secondary package version must be
compatible with this template. If semver-min is used, the secondary
package version must be either compatible with that SemVer template, or greater than
it. If semver-max is used, the secondary package version must be either
compatible with that SemVer template, or lower than it. For instance, with
semver-min="2.3" and semver-max="3", any version of the
secondary package which is equal or above 2.3.0 and strictly below 4.0.0 is valid
(that is, 2.3.0, 3.0.0, 3.99.87, etc.)
In addition to depending on other packages, a dependency can tell which processor(s) is (are) needed for this package:
<dependency processor="saxon"/>
If there is several such dependencies, the package is supported by a specific processor as soon as one of the proc dependencies does match. The meaning of the versionning attributes on processor dependencies is defined by each processor.
How those rules are enforced is implementation-defined. For instance a command line tool to install a package in a repository can generate an error if the required dependencies are not installed, try to install them automagically from the web, or just emit a warning install the package hoping the dependencies to be installed later on, and provide an option to select the behaviour to use. Another implementation can enforce the dependencies at compile- or at run-time. An implementation SHOULD provide a way to enforce those rules, but can also provide an option to ignore them.
From the above text, a version number is not defined to have any particular semantics, except when used with one of the several SemVer attributes. The only constraint is that a version number cannot contain any whitespace character (as defined by the [XML] recommendation). A library author SHOULD use version numbers compatible with SemVer though, unless there is a justification not to use it.
This section defines a standard structure for on-disk repositories. An implementation can choose not to support this kind of repository and to define its own one (or even to not define it publicly, just to provide the ability to install and remove packages, in a clearly documented way.) However, there are several advantages to support this structure, the most obvious one is to be able to benefit from existing tools to manage such repositories as well as existing libraries to access those repositories.
The resolving machinery is based on OASIS XML Catalogs [Catalogs]. The repository is a simple directory, each subdirectory of which is
an installed package (aka a package dir.) The only exception to this is the
subdirectory .expath-pkg/ which is dedicated to store working information
about the installed packages, among which the catalogs (aka the admin dir.)
[repository-dir]/
.expath-pkg/
xquery-catalog.xml
xslt-catalog.xml
lib1/
xquery-catalog.xml
xslt-catalog.xml
lib2/
...
lib1/
query.xq
style.xsl
lib2/
...The package dirs are really simple: they are simply an unzipped
version of the XAR file. The name of the directory is simply the same as the name of the
module in the package. The admin dir contains a catalog for each URI space
(the catalog for one specific URI space can not be there if there is no one file in that
URI space in the whole repository.) The name of such a catalog is
[space]-catalog.xml where [space] is either xslt,
xquery, rnc, etc. Those catalogs are called repository
catalogs. It also contains a subdirectory for each installed package, with the
same naming convention. In turn, those directories contain catalog files, containing the
mappings defined in the corresponding package descriptors (pointing to the actual files
installed in the package dirs.) Those are called the package
catalogs. They follow the same naming convention than the repository
catalogs (divided by URI spaces.) The repository catalogs just include the
several package catalogs for the same URI space.
[ ... TODO ... ]
The repository is a directory on the file system, within which the packages
are installed. Each package results in a subdirectory in the repository, where the
content of the XAR file is unzipped. Next to those package directories, there is also a
subdirectory named .expath-pkg/, which contains administrative information
about the packages installed in this repository. The package directories should be named
after the package abbreviation (the abbrev attribute in the package
descriptor) and the version number, separated by a dash. A package directory name must
not contain the space character.
Note:
Because these directory names cannot be ensured to be unique among every packages installed in the repository, and because the processors will in some case have to translate some characters (depending on the rules of the filesystem they put the repository on), they cannot be used as a perfect mapping between package abbreviations and directories. It is only described here as a note, in the hope that the several implementations will use similar naming strategies, meaningful for humans.
The repository maintains a list of installed packages. For each of them, this
list contains its name (the name URI), its subdirectory name, and its version number.
This list is maintained within two files: .expath-pkg/packages.xml and
.expath-pkg/packages.txt. Both contain the same information, the former
in an XML format and the later as plain text. The XML format looks like the following
(see B Package list schema for a normative schema):
<packages xmlns="http://expath.org/ns/repo/packages">
<package name="http://example.org/some/package"
dir="some-package-2.3"
version="2.3"/>
<package name="http://example.com/some-library"
dir="some-lib-0.1"
version="0.1"/>
<package ...
</packages>The text file is a line-separated file (either line termination can be used:
\r, \n or \n\r, though the standard Internet
line termination is preferred: \n\r). Each line represent a package, and is
a space-separated record. The first field is the package directory (the name if the
subdirectory within the repository where the package has been unzipped), the second one
is the package name (the name URI), and the last one is the version number. The two
first fields cannot contain any space character. The version number is the only one that
can contain a space character (though this is not recommended). Every field is separated
by exactly one space character (the Unicode character with code point #x20). This file
then looks like:
some-package-2.3 http://example.org/some/package 2.3 some-lib-0.1 http://example.com/some-library 0.1 ...
The overall repository thus looks like:
[repository-dir]/
.expath-pkg/
packages.txt
packages.xml
some-package-2.3/
query.xq
style.xsl
some-lib-0.1/
...Note:
Because the package descriptor is unzipped in the package directory, as well as the
rest of the files contained in the package, this is easy to find the mapping between
package directories and package names and versions: just look into the package
descriptor into every package directory, and you will find what you are looking for.
But in order to allow other programs to access easily the list of installed packages,
we provide the list in .expath-pkg/packages.xml. And because shell
scripts must be able to access that list as well, a second file, text-oriented, is
provided; of course this is redundant information, but it is maintained automatically
by the repository manager, so the redundancy is not an issue.
In addition to this structure, a specific processor can store information in
subdirectories (both in the repository level or within each package directories),
provided those directories start with a dot, and are named unambiguously with the name
of the processor. For instance [repository]/.saxon/, or
[repository]/[some-pkg]/.exist/.
This section provides a non-normative example to illustrate the concepts defined here. Instead of using a hello world example, it describes the packaging of the existing FunctX library [FunctX]. This library consists of a standard XQuery 1.0 library module and a standard XSLT 2.0 stylesheet (both provide the same set of functions to either XQuery or XSLT, but this is not relevant to packaging.)
The first thing to do is to create a ZIP file with both of those components, alongside a
package descriptor. The constraints are: 1) the package descriptor is
named expath-pkg.xml at the root of the package, 2) the library content is
in a directory at the root of the package (aka the package directory), and
3) the name of this directory must be the value of the name attribute
of the module element abbrev
attribute, and must be a valid NCName. The structure (the content) of the
package directory is completely free. In our case, let's just put both component files
directly in the package directory, and define the module name as
functx:
expath-pkg.xml functx/ functx.xql functx.xsl
The XQuery library module's target namespace is defined by the module itself. For the
XSLT stylesheet, we have to define its public URI, used to identify it
within an xsl:import (or any other means, for instance within XProc or an
IDE scenarii system). Let's define it as http://www.functx.com/functx.xsl.
The package descriptor thus looks like the following:
<package xmlns="http://expath.org/ns/pkg">
<module name="functx" version="1.0">
<title>FunctX library</title>
<xquery>
<namespace>http://www.functx.com</namespace>
<file>functx.xql</file>
</xquery>
<xslt>
<import-uri>http://www.functx.com/functx.xsl</import-uri>
<file>functx.xsl</file>
</xslt>
</module>
</package>
<package xmlns="http://expath.org/ns/pkg"
spec="1.0"
name="http://www.functx.com"
abbrev="functx"
version="1.0">
<title>FunctX library</title>
<xquery>
<namespace>http://www.functx.com</namespace>
<file>functx.xql</file>
</xquery>
<xslt>
<import-uri>http://www.functx.com/functx.xsl</import-uri>
<file>functx.xsl</file>
</xslt>
</package>We just have to create a ZIP file with this structure and content. The convention is to
call this file functx-1.0.xar (that is,
[name
abbrev]-[version].xar). That's all for the
package itself. If the target processor supports the on-disk repository layout, here is
what the repository could look like after the package has been installed:
[repository-dir]/
.expath-pkg/
xquery-catalog.xml
xslt-catalog.xml
functx/
xquery-catalog.xml
xslt-catalog.xml
functx/
functx.xql
functx.xslThe package directory has been copied verbatim, and two new catalogs have
been created for the package, pointing to the components in the package directory. The
top-level catalogs in the admin directory (one per URI space) just point to the other
package-specific catalogs. Here is for instance the content of
.expath-pkg/xslt-catalog.xml, initiating the catalog list for the URI
space for XSLT (in our case the catalog for the URI space for XSLT of the single
installed package):
<catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog"> <nextCatalog catalog="functx/xslt-catalog.xml"/> </catalog>
The catalogs at the package-level point to the actual components by using a
relative path within the repository. The following is for example the content of the
catalog .expath-pkg/functx/xslt-catalog.xml:
<catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog">
<!-- TODO: Should there be a system entry as well? -->
<uri name="http://www.functx.com/functx.xsl"
uri="../../functx/functx.xsl"/>
</catalog>A user can then import the FunctX library from either an XQuery module or an XSLT stylesheet by using respectively an import statement:
[repository-dir]/
.expath-pkg/
packages
packages.xml
functx-1.0/
expath-pkg.xml
functx/
functx.xql
functx.xslThe content of .expath-pkg/packages.xml is:
<packages xmlns="http://expath.org/ns/repo/packages">
<package name="http://www.functx.com"
dir="functx-1.0"
version="1.0"/>
</packages>The content of .expath-pkg/packages.txt is:
functx-1.0 http://www.functx.com 1.0
The package directory functx-1.0/ has been named after the
abbrev and the version number. Its content is simply the content of the XAR file,
unzipped. A user can then import the FunctX library from either an XQuery module or an
XSLT stylesheet by using respectively an import statement:
import module namespace fx = "http://www.functx.com";
or an import instruction:
<xsl:import href="http://www.functx.com/functx.xsl"/>
The package format defined in this specification is a complete system to package libraries, for the right definition of a library. But a specfic kind of library can require more information. For instance, a web application is also a set of components, but requiring more configuration. An additional descriptor format for such applications could be defined and added to this packaging framework to define a specialized kind of packages. By building upon this packaging format, the new format would benefit from the existing mechanism to map public URIs to components.
Another extensibility point is the definition of additional component types. The component types defined here are the standard types, but an implementation may support additional implementation-defined types.
More generally, an implementation may define any extension element in the package descriptor to achieve its purposes, providing that the new elements it defines are neither in the EXPath Packaging namespace nor in the null namespace.
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 we add a generic "xml" URI space, for any XML document?
Interesting use case with XProc and NVDL: How to configure the XSLT processor in Calabash with the NVDL URI space for an NVDL implementation for XProc written using XSLT as a plain library step?
About the standard directory layout: should we still use XML Catalogs, or just a simple format to map public URIs to files? (should really this repository layout be defined here, anyway?)
Add in the package descriptor an element for a description, or at very least a URL to the home of the project.
[ ... TODO ... ]
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:pkg="http://expath.org/ns/pkg"
targetNamespace="http://expath.org/ns/pkg"
elementFormDefault="qualified">
<xs:element name="package">
<xs:complexType>
<xs:sequence>
<xs:element name="title" type="pkg:title-type"/>
<xs:element ref="pkg:dependency" minOccurs="0" maxOccurs="unbounded"/>
<xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:element name="xquery" type="pkg:query-type"/>
<xs:element name="xslt" type="pkg:component-type"/>
<xs:element name="xproc" type="pkg:component-type"/>
<xs:element name="xsd" type="pkg:component-type"/>
<xs:element name="rng" type="pkg:component-type"/>
<xs:element name="rnc" type="pkg:component-type"/>
</xs:choice>
</xs:sequence>
<xs:attribute name="name" type="xs:anyURI" use="required"/>
<xs:attribute name="abbrev" type="xs:NCName" use="required"/>
<xs:attribute name="version" type="xs:string" use="required"/>
<!-- In the 1.0 version of the spec, fix it to '1.0'. -->
<xs:attribute name="spec" fixed="1.0-alpha1" use="required"/>
</xs:complexType>
</xs:element>
<xs:element name="dependency">
<xs:complexType>
<xs:attribute name="name" type="xs:anyURI"/>
<xs:attribute name="version" type="xs:token"/>
<xs:attribute name="versions">
<xs:simpleType>
<xs:list itemType="xs:token"/>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="semver" type="pkg:semver"/>
<xs:attribute name="semver-min" type="pkg:semver"/>
<xs:attribute name="semver-max" type="pkg:semver"/>
</xs:complexType>
</xs:element>
<!-- TODO: Make it more precise, using a regex. -->
<xs:simpleType name="semver">
<xs:restriction base="xs:token"/>
</xs:simpleType>
<xs:simpleType name="title-type">
<xs:restriction base="xs:string"/>
</xs:simpleType>
<xs:complexType name="component-type">
<xs:sequence>
<xs:element name="import-uri" type="xs:anyURI"/>
<xs:element name="file" type="xs:anyURI"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="query-type">
<xs:sequence>
<xs:element name="namespace" type="xs:anyURI"/>
<xs:element name="file" type="xs:anyURI"/>
</xs:sequence>
</xs:complexType>
</xs:schema>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:p="http://expath.org/ns/repo/packages"
targetNamespace="http://expath.org/ns/repo/packages"
elementFormDefault="qualified">
<xs:element name="packages">
<xs:complexType>
<xs:sequence>
<xs:element ref="p:package" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="package">
<xs:complexType>
<!-- TODO: Get those definitions from expath-pkg.xsd
(or instead shared them between both schemas). -->
<xs:attribute name="name" type="xs:anyURI" use="required"/>
<xs:attribute name="dir" type="xs:string" use="required"/>
<xs:attribute name="version" type="xs:string" use="required"/>
</xs:complexType>
</xs:element>
</xs:schema>