XProc 3.0: An XML Pipeline Language
Drafts are published automatically at spec.xproc.org.
The XProc community is using GitHub to manage the development of this specification. Please pull the repository, make improvements, and propose changes in the form of pull requests.
The XProc specification is built automatically with Travis CI.
To build and publish the spec on your
gh-pages, setup the
configure Travis CI to
run for your repo, and then create the following
secure environment variables for your repo in the Travis CI Settings
page for your fork:
- GH_TOKEN="your git token"
- GIT_NAME="Your Name"
GIT_TOKEN must be a
personal access token. The
GIT_PUB_REPO must be the repository where you wish
to publish the results. The publications scripts will push the published documents
Travis CI will then publish your changes everytime you do a commit
master branch. Travis CI cannot publish
How it works
The documents are built by a gradle task that runs XML Calabash and other tools. The individual specifications are in sub-projects. At the time of this writing, there are two specifications in this repository:
overviewis the overview page that points to all the specs
xprocis XProc 3.0: A Pipeline Language
The default gradle target,
allspecs, will build all of the specifications.
The built specifications are in the
build/dist/ directory or directories
Within each subproject, the “source” for each specification is in
src/main/xml/specification.xml. There may be other files as well.
Use XInclude to break specs into pieces if you wish.
About the workflow
It’s all a bit complicated. These are some notes.
The published specs are the
gh-pagesbranch of this repository.
Three repositories update the
gh-pagesbranch: this repository publishes the language specification; the
3.0-stepsrepository publishes the steps; the
3.0-grammarrepository publishes the grammar.
Publishing the grammar relies on the steps! So
3.0-grammarshould be rebuilt whenever the steps change and this repos should be rebuilt whenever the core grammar changes!
All specifications have a glossary; if the glossary turns out to be empty, because there are no term definitions (
firsttermelements) in a specification, it will be elided automatically.
<xi:include href="../../../build/glossary.xml"> <xi:fallback> <glossary xml:id="glossary"> <title>Glossary</title> <para>Glossary needs to be generated</para> </glossary> </xi:fallback> </xi:include>
- Similarly, for steps, there is a step errors appendix. It will be populated automatically and elided if there are no step errors.
<appendix xml:id="app.step-errors"> <title>Step Errors</title> <para>The following <glossterm baseform="dynamic-error">dynamic errors</glossterm> can be raised by the <code>p:validate-with-relax-ng</code> step:</para> <?step-error-list?> </appendix>
- There is a single, master bibliography in
src/main/xml/bibliography.xml. In each specification, use
bibliorefto refer to bibliography entries. Create a
bibliomiscelements to pull in the relevant entries from the master bibliography:
<appendix xml:id="references"> <title>References</title> <bibliolist> <bibliomixed xml:id="xproc30"/> <bibliomixed xml:id="xproc30-steps"/> <bibliomixed xml:id="iso19757-2"/> <bibliomixed xml:id="relaxng-compact-syntax"/> <bibliomixed xml:id="relaxng-dtd-compat"/> </bibliolist> </appendix>
- Examples and graphics are also a little complicated. I’ll describe them here if anyone asks. :-)
The build process is owned by norm; bug him if you have difficulties.