diff --git a/build.gradle b/build.gradle
index 129da29..95a73bc 100644
--- a/build.gradle
+++ b/build.gradle
@@ -101,7 +101,7 @@ task make_etc() {
["steps", "step-file", "step-os", "step-paged-media",
"step-run", "step-text", "step-mail", "step-rdf", "step-validation",
- "step-ixml"
+ "step-ixml", "step-message"
].each { spec ->
Task t = task "copy_${spec}_build"(dependsOn: [ "buildspecs" ], type: Copy) {
from "$spec/build/"
@@ -706,6 +706,59 @@ task step_ixml_xpl(dependsOn: ["step-ixml:library"], type: Copy) {
rename ("library.xml", "steps.xpl")
}
+// ======================================================================
+// step-message
+
+task step_message(type: DocBookTask,
+ dependsOn: [ "download_xproc_toc",
+ "steps", "xproc_schemas", "spec_schemas",
+ "step-message:specification",
+ "step_message_assets",
+ "step_message_src", "step_message_xpl" ]) {
+ inputs.files fileTree(dir: "tools/xsl/")
+ inputs.files fileTree(dir: "tools/xpl/")
+ inputs.file "build/xproc/toc.xml"
+ input("source", "step-message/build/source.xml")
+ output("result", "build/dist/message/index.html")
+
+ param("schemaext.schema", file("build/schema/dbspec.rng"))
+ param("ci", getenv("CIWORKFLOW"))
+ param("ci-commit", getenv("CI_SHA1"))
+ param("ci-build-number", getenv("CI_BUILD_NUM"))
+ param("ci-user", getenv("CI_PROJECT_USERNAME"))
+ param("ci-repo", getenv("CI_PROJECT_REPONAME"))
+ param("ci-branch", getenv("CI_BRANCH"))
+ param("ci-tag", getenv("CI_TAG"))
+
+ option("style", file("tools/xsl/xproc-specs.xsl"))
+ option("diff", '')
+ option("specid", "message")
+ option("diffloc", buildAbsDir + "/message/diff.html")
+
+ pipeline "tools/xpl/formatspec.xpl"
+}
+buildspecs.dependsOn "step_message"
+
+task step_message_assets(type: Copy) {
+ from "src/main/resources"
+ into "build/dist/message/"
+}
+
+task step_message_src(dependsOn: ["step-message:source"], type: Copy) {
+ from "step-message/build/"
+ into "build/dist/message/"
+ include "source.xml"
+ rename ("source.xml", "specification.xml")
+}
+
+task step_message_xpl(dependsOn: ["step-message:library"], type: Copy) {
+ from "step-message/build/"
+ into "build/dist/message/"
+ include "library.xml"
+ rename ("library.xml", "steps.xpl")
+}
+
+
// ======================================================================
// Clean up
diff --git a/settings.gradle b/settings.gradle
index e92df9a..c3d20fe 100644
--- a/settings.gradle
+++ b/settings.gradle
@@ -1,2 +1,2 @@
include 'steps', 'step-validation', 'step-os', 'step-paged-media', 'step-run',
- 'step-file', 'step-text', 'step-mail', 'step-ixml'
+ 'step-file', 'step-text', 'step-mail', 'step-ixml', 'step-message'
diff --git a/step-message/build.gradle b/step-message/build.gradle
new file mode 100644
index 0000000..0e77196
--- /dev/null
+++ b/step-message/build.gradle
@@ -0,0 +1,95 @@
+repositories {
+ mavenLocal()
+ mavenCentral()
+}
+
+configurations {
+ tools {
+ description = "Run tools"
+ transitive = true
+ }
+}
+
+dependencies {
+ tools (
+ [group: 'org.relaxng', name: 'jing', version: '20181204'],
+ [group: 'org.relaxng', name: 'trang', version: '20181204']
+ )
+}
+
+defaultTasks 'specification'
+
+apply plugin: 'com.xmlcalabash.task'
+
+import com.xmlcalabash.XMLCalabashTask
+import com.nwalsh.tasks.StripAmblesTask
+
+task xinclude(dependsOn: [":spec_schemas"], type: XMLCalabashTask) {
+ inputs.files fileTree(dir: "src/main/xml/")
+ outputs.file "build/xinclude.xml"
+ input("source", "src/main/xml/specification.xml")
+ output("result", "build/xinclude.xml")
+ pipeline "../tools/xpl/validate.xpl"
+}
+xinclude.doFirst {
+ mkdir("build")
+}
+
+task source(dependsOn: ["glossary"], type: XMLCalabashTask) {
+ inputs.file "../tools/xsl/masterbib.xsl"
+ inputs.file "../src/main/xml/bibliography.xml"
+ inputs.file "src/main/xml/specification.xml"
+ inputs.file "build/glossary.xml"
+ outputs.file "build/source.xml"
+ input("source", "src/main/xml/specification.xml")
+ output("result", "build/source.xml")
+ pipeline "../tools/xpl/validate.xpl"
+}
+
+task glossary(dependsOn: ["xinclude"], type: XMLCalabashTask) {
+ inputs.file "build/xinclude.xml"
+ inputs.file "../tools/xpl/makeglossary.xpl"
+ inputs.file "../tools/xsl/makeglossary.xsl"
+ outputs.file "build/glossary.xml"
+ input("source", "build/xinclude.xml")
+ output("result", "build/glossary.xml")
+ pipeline "../tools/xpl/makeglossary.xpl"
+}
+
+task library(dependsOn: ["source"], type: XMLCalabashTask) {
+ inputs.file "build/source.xml"
+ inputs.file "../tools/xpl/typed-pipeline-library.xpl"
+ inputs.file "../tools/xsl/typed-pipeline-library.xsl"
+ outputs.file "build/library.xml"
+ input("source", "build/source.xml")
+ output("result", "build/library.xml")
+ pipeline "../tools/xpl/typed-pipeline-library.xpl"
+}
+
+task rnc(dependsOn: ["library"], type: XMLCalabashTask) {
+ inputs.file "build/library.xml"
+ inputs.file "../tools/xpl/library-to-rnc.xpl"
+ inputs.file "../tools/xsl/library-to-rnc.xsl"
+ outputs.file "build/steps.rnc"
+ input("source", "build/library.xml")
+ output("result", "build/steps.rnc")
+ pipeline "../tools/xpl/library-to-rnc.xpl"
+}
+
+task rng(dependsOn: ["rnc"], type: JavaExec) {
+ inputs.file "build/steps.rnc"
+ outputs.file "build/steps.rng"
+ classpath = configurations.tools
+ mainClass = 'com.thaiopensource.relaxng.translate.Driver'
+ args = ["build/steps.rnc", "build/steps.rng"]
+}
+
+task specification(dependsOn: [ "source", "library", "rng" ]) {
+ // nop
+}
+
+task clean() {
+ doFirst {
+ delete("build")
+ }
+}
diff --git a/step-message/build/glossary.xml b/step-message/build/glossary.xml
new file mode 100644
index 0000000..a4efcee
--- /dev/null
+++ b/step-message/build/glossary.xml
@@ -0,0 +1,9 @@
+Glossaryimplementation-definedAn
+implementation-defined feature is one where the
+implementation has discretion in how it is performed.
+Conformant implementations must document
+how implementation-defined features are performed.implementation-dependentAn
+implementation-dependent feature is one where the
+implementation has discretion in how it is performed.
+Implementations are not required to document or explain
+how implementation-dependent features are performed.
\ No newline at end of file
diff --git a/step-message/build/library.xml b/step-message/build/library.xml
new file mode 100644
index 0000000..b9b0303
--- /dev/null
+++ b/step-message/build/library.xml
@@ -0,0 +1,10 @@
+
+
+
+
+
+
+
+
diff --git a/step-message/build/source.xml b/step-message/build/source.xml
new file mode 100644
index 0000000..fe19b34
--- /dev/null
+++ b/step-message/build/source.xml
@@ -0,0 +1,242 @@
+
+
+ XProc 3.1: message step
+
+2025
+the Contributors to the XProc 3.1 Standard Step Library
+specifications
+
+
+xproc/3.0-steps
+XProc Next
+
+ XML
+
+
+ Norman Walsh
+
+
+ Achim Berndzen
+
+
+ Gerrit Imsieke
+
+
+ Erik Siegel
+
+
+
+
+ This specification describes an optional message step for
+XProc 3.1: An XML Pipeline Language.
+
+
+
+ This specification was published by the
+ XProc
+ Next Community Group. It is not a W3C Standard nor is it on
+ the W3C Standards Track. Please note that under the
+ W3C
+ Community Contributor License Agreement (CLA) there is a limited
+ opt-out and other conditions apply. Learn more about W3C Community and Business
+ Groups.
+
+
+ If you wish to make comments regarding this document, please
+ send them to
+ xproc-dev@w3.org.
+ (subscribe,
+ archives).
+
+
+
+This draft is the “editor’s working draft” and may continue to evolve.
+
+
+
+
+
+
+ Introduction
+
+ This specification describes an optional message step for XProc 3.1.
+A machine-readable description of this step may be found in
+steps.xpl.
+
+Familarity with the general nature of
+ steps is assumed.
+
+
+
+Step library
+
+
+p:message
+
+The p:message step conditionally produces a message.
+
+
+
+
+
+
+
+
+Steps that produce messages offer one way for an author to keep track of
+the progress of a pipeline. The [p:]message
+attribute can be added to any step to display a message when it runs.
+
+Status and debugging messages that are appropriate during pipeline
+development may be distracting when the pipeline is running “in production”.
+Existing mechanisms for conditional compilation can be used to mediate between
+“development” and “production” runs, but they are a bit heavyweight. Adding many
+steps with [p:]use-when attributes and managing the
+connections between steps that may be conditionally removed can make pipelines
+harder to read and understand.
+
+The p:message step can be used to achieve much the same effect
+and is considerably less verbose.
+
+If the test attribute is
+“true”, the select expression is
+evaluated and made available. (As with the message
+attribute, this is intentionally vague. Precisely what “made
+available” means is implementation-defined.
+Often it means “printed on the console”.)
+
+Irrespective of the value of the test
+attribute, the p:message passes all of the documents that appear on
+its source port through to the result port,
+unchanged and in the same order.
+
+If exactly one document appears on the source port, it is the
+context item when the test and select expressions are evaluated. In all other cases,
+the context item is undefined.
+
+
+If the test expression is “false”,
+it is implementation-dependent if the
+select expression is evaluated.
+
+
+
+If it can be determined statically that test expression is
+always “false”, the processor may remove the
+step from the pipeline entirely, although it must guarantee that all of the connections
+are preserved.
+
+
+
+ Document properties
+ All document properties are preserved.
+
+
+
+
+
+
+
+Conformance
+
+Conformant processors must implement all of the features
+described in this specification except those that are explicitly identified
+as optional.
+
+Some aspects of processor behavior are not completely specified; those
+features are either implementation-dependent or
+implementation-defined.
+
+An
+implementation-dependent feature is one where the
+implementation has discretion in how it is performed.
+Implementations are not required to document or explain
+how implementation-dependent features are performed.
+
+
+An
+implementation-defined feature is one where the
+implementation has discretion in how it is performed.
+Conformant implementations must document
+how implementation-defined features are performed.
+
+
+
+Implementation-defined features
+
+The following features are implementation-defined:
+
+
+
+
+
+Implementation-dependent features
+
+The following features are implementation-dependent:
+
+
+
+
+
+
+
+ References
+
+ XProc 3.1
+XProc 3.1:
+An XML Pipeline Language.
+Norman Walsh, Achim Berndzen, Gerrit Imsieke and Erik Siegel, editors.
+
+
+
+
+
+ Glossaryimplementation-definedAn
+implementation-defined feature is one where the
+implementation has discretion in how it is performed.
+Conformant implementations must document
+how implementation-defined features are performed.implementation-dependentAn
+implementation-dependent feature is one where the
+implementation has discretion in how it is performed.
+Implementations are not required to document or explain
+how implementation-dependent features are performed.
+
+
+Ancillary files
+
+This specification includes by reference a number of
+ancillary files.
+
+
+
+
+
+An XProc step library for the declared steps.
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/step-message/build/steps.rnc b/step-message/build/steps.rnc
new file mode 100644
index 0000000..4ea2562
--- /dev/null
+++ b/step-message/build/steps.rnc
@@ -0,0 +1,18 @@
+default namespace p = "http://www.w3.org/ns/xproc"
+namespace local = ""
+
+# This schema could be made more constrained.
+
+Step = Step-message
+
+Step-message =
+ element message {
+ name.ncname.attr?,
+ common.attributes,
+ use-when.attr?,
+ step.attributes,
+ attribute test { avt.datatype }?,
+ attribute select { avt.datatype }?,
+ (WithInput* & WithOption* & (Documentation|PipeInfo)*)
+ }
+
diff --git a/step-message/build/steps.rng b/step-message/build/steps.rng
new file mode 100644
index 0000000..7e337be
--- /dev/null
+++ b/step-message/build/steps.rng
@@ -0,0 +1,43 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/step-message/build/xinclude.xml b/step-message/build/xinclude.xml
new file mode 100644
index 0000000..fe19b34
--- /dev/null
+++ b/step-message/build/xinclude.xml
@@ -0,0 +1,242 @@
+
+
+ XProc 3.1: message step
+
+2025
+the Contributors to the XProc 3.1 Standard Step Library
+specifications
+
+
+xproc/3.0-steps
+XProc Next
+
+ XML
+
+
+ Norman Walsh
+
+
+ Achim Berndzen
+
+
+ Gerrit Imsieke
+
+
+ Erik Siegel
+
+
+
+
+ This specification describes an optional message step for
+XProc 3.1: An XML Pipeline Language.
+
+
+
+ This specification was published by the
+ XProc
+ Next Community Group. It is not a W3C Standard nor is it on
+ the W3C Standards Track. Please note that under the
+ W3C
+ Community Contributor License Agreement (CLA) there is a limited
+ opt-out and other conditions apply. Learn more about W3C Community and Business
+ Groups.
+
+
+ If you wish to make comments regarding this document, please
+ send them to
+ xproc-dev@w3.org.
+ (subscribe,
+ archives).
+
+
+
+This draft is the “editor’s working draft” and may continue to evolve.
+
+
+
+
+
+
+ Introduction
+
+ This specification describes an optional message step for XProc 3.1.
+A machine-readable description of this step may be found in
+steps.xpl.
+
+Familarity with the general nature of
+ steps is assumed.
+
+
+
+Step library
+
+
+p:message
+
+The p:message step conditionally produces a message.
+
+
+
+
+
+
+
+
+Steps that produce messages offer one way for an author to keep track of
+the progress of a pipeline. The [p:]message
+attribute can be added to any step to display a message when it runs.
+
+Status and debugging messages that are appropriate during pipeline
+development may be distracting when the pipeline is running “in production”.
+Existing mechanisms for conditional compilation can be used to mediate between
+“development” and “production” runs, but they are a bit heavyweight. Adding many
+steps with [p:]use-when attributes and managing the
+connections between steps that may be conditionally removed can make pipelines
+harder to read and understand.
+
+The p:message step can be used to achieve much the same effect
+and is considerably less verbose.
+
+If the test attribute is
+“true”, the select expression is
+evaluated and made available. (As with the message
+attribute, this is intentionally vague. Precisely what “made
+available” means is implementation-defined.
+Often it means “printed on the console”.)
+
+Irrespective of the value of the test
+attribute, the p:message passes all of the documents that appear on
+its source port through to the result port,
+unchanged and in the same order.
+
+If exactly one document appears on the source port, it is the
+context item when the test and select expressions are evaluated. In all other cases,
+the context item is undefined.
+
+
+If the test expression is “false”,
+it is implementation-dependent if the
+select expression is evaluated.
+
+
+
+If it can be determined statically that test expression is
+always “false”, the processor may remove the
+step from the pipeline entirely, although it must guarantee that all of the connections
+are preserved.
+
+
+
+ Document properties
+ All document properties are preserved.
+
+
+
+
+
+
+
+Conformance
+
+Conformant processors must implement all of the features
+described in this specification except those that are explicitly identified
+as optional.
+
+Some aspects of processor behavior are not completely specified; those
+features are either implementation-dependent or
+implementation-defined.
+
+An
+implementation-dependent feature is one where the
+implementation has discretion in how it is performed.
+Implementations are not required to document or explain
+how implementation-dependent features are performed.
+
+
+An
+implementation-defined feature is one where the
+implementation has discretion in how it is performed.
+Conformant implementations must document
+how implementation-defined features are performed.
+
+
+
+Implementation-defined features
+
+The following features are implementation-defined:
+
+
+
+
+
+Implementation-dependent features
+
+The following features are implementation-dependent:
+
+
+
+
+
+
+
+ References
+
+ XProc 3.1
+XProc 3.1:
+An XML Pipeline Language.
+Norman Walsh, Achim Berndzen, Gerrit Imsieke and Erik Siegel, editors.
+
+
+
+
+
+ Glossaryimplementation-definedAn
+implementation-defined feature is one where the
+implementation has discretion in how it is performed.
+Conformant implementations must document
+how implementation-defined features are performed.implementation-dependentAn
+implementation-dependent feature is one where the
+implementation has discretion in how it is performed.
+Implementations are not required to document or explain
+how implementation-dependent features are performed.
+
+
+Ancillary files
+
+This specification includes by reference a number of
+ancillary files.
+
+
+
+
+
+An XProc step library for the declared steps.
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/step-message/src/main/xml/ancillary.xml b/step-message/src/main/xml/ancillary.xml
new file mode 100644
index 0000000..76e7374
--- /dev/null
+++ b/step-message/src/main/xml/ancillary.xml
@@ -0,0 +1,21 @@
+
+Ancillary files
+
+This specification includes by reference a number of
+ancillary files.
+
+
+
+
+
+An XProc step library for the declared steps.
+
+
+
+
+
+
diff --git a/step-message/src/main/xml/specification.xml b/step-message/src/main/xml/specification.xml
new file mode 100644
index 0000000..1519f8a
--- /dev/null
+++ b/step-message/src/main/xml/specification.xml
@@ -0,0 +1,234 @@
+
+
+
+ XProc 3.1: message step
+
+2025
+the Contributors to the XProc 3.1 Standard Step Library
+specifications
+
+
+xproc/3.0-steps
+XProc Next
+
+ XML
+
+
+ Norman Walsh
+
+
+ Achim Berndzen
+
+
+ Gerrit Imsieke
+
+
+ Erik Siegel
+
+
+
+
+ This specification describes an optional message step for
+XProc 3.1: An XML Pipeline Language.
+
+
+
+ This specification was published by the
+ XProc
+ Next Community Group. It is not a W3C Standard nor is it on
+ the W3C Standards Track. Please note that under the
+ W3C
+ Community Contributor License Agreement (CLA) there is a limited
+ opt-out and other conditions apply. Learn more about W3C Community and Business
+ Groups.
+
+
+ If you wish to make comments regarding this document, please
+ send them to
+ xproc-dev@w3.org.
+ (subscribe,
+ archives).
+
+
+
+This draft is the “editor’s working draft” and may continue to evolve.
+
+
+
+
+
+
+ Introduction
+
+ This specification describes an optional message step for XProc 3.1.
+A machine-readable description of this step may be found in
+steps.xpl.
+
+Familarity with the general nature of
+ steps is assumed.
+
+
+
+Step library
+
+
+p:message
+
+The p:message step conditionally produces a message.
+
+
+
+
+
+
+
+
+Steps that produce messages offer one way for an author to keep track of
+the progress of a pipeline. The [p:]message
+attribute can be added to any step to display a message when it runs.
+
+Status and debugging messages that are appropriate during pipeline
+development may be distracting when the pipeline is running “in production”.
+Existing mechanisms for conditional compilation can be used to mediate between
+“development” and “production” runs, but they are a bit heavyweight. Adding many
+steps with [p:]use-when attributes and managing the
+connections between steps that may be conditionally removed can make pipelines
+harder to read and understand.
+
+The p:message step can be used to achieve much the same effect
+and is considerably less verbose.
+
+If the test attribute is
+“true”, the select expression is
+evaluated and made available. (As with the message
+attribute, this is intentionally vague. Precisely what “made
+available” means is implementation-defined.
+Often it means “printed on the console”.)
+
+Irrespective of the value of the test
+attribute, the p:message passes all of the documents that appear on
+its source port through to the result port,
+unchanged and in the same order.
+
+If exactly one document appears on the source port, it is the
+context item when the test and select expressions are evaluated. In all other cases,
+the context item is undefined.
+
+
+If the test expression is “false”,
+it is implementation-dependent if the
+select expression is evaluated.
+
+
+
+If it can be determined statically that test expression is
+always “false”, the processor may remove the
+step from the pipeline entirely, although it must guarantee that all of the connections
+are preserved.
+
+
+
+ Document properties
+ All document properties are preserved.
+
+
+
+
+
+
+
+Conformance
+
+Conformant processors must implement all of the features
+described in this specification except those that are explicitly identified
+as optional.
+
+Some aspects of processor behavior are not completely specified; those
+features are either implementation-dependent or
+implementation-defined.
+
+An
+implementation-dependent feature is one where the
+implementation has discretion in how it is performed.
+Implementations are not required to document or explain
+how implementation-dependent features are performed.
+
+
+An
+implementation-defined feature is one where the
+implementation has discretion in how it is performed.
+Conformant implementations must document
+how implementation-defined features are performed.
+
+
+
+Implementation-defined features
+
+The following features are implementation-defined:
+
+
+
+
+
+Implementation-dependent features
+
+The following features are implementation-dependent:
+
+
+
+
+
+
+
+ References
+
+
+
+
+
+
+
+
+
+ Glossary
+ Glossary needs to be generated
+
+
+
+
+
+
+