201820192020 20212022202320242025 the Contributors to the XProc 3.1 Standard Step Library specifications XProc/specification XProc Next XML Norman Walsh Achim Berndzen Gerrit Imsieke Erik Siegel This specification describes the p:os-exec and p:os-info steps 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.

This specification describes the p:os-info and p:os-exec XProc steps. A machine-readable description of these steps may be found in steps.xpl. Familarity with the general nature of steps is assumed.

The p:os-info step returns information about the operating system on which the processor is running. The step returns a c:result element with attributes describing properties of the system. It must include the following properties. The attribute can be an empty string if they do not apply to the runtime environment. For example cwd will be an empty string on systems which have no concept of a working directory the value of the attribute will be empty. file-separator The file separator; usually "/" on Unix, "\" on Windows. path-separator The path separator; usually ":" on Unix, ";" on Windows. os-architecture The operating system architecture, for example "i386". os-name The name of the operating system, for example "Mac OS X". os-version The version of the operating system, for example "10.5.6". cwd The current working directory. user-name The login name of the effective user, for example "ndw". user-home The home directory of the effective user, for example "/home/ndw". The c:result element can contain zero or more c:environment elements that identify the environment variables available. These elements have a mandatory name and value attribute, reflecting name and value of the environment variable. Implementations should include all available operating system environment variables. The exact set of properties returned is implementation-defined. Additional attributes must be in a namespace. The resulting document has no properties apart from content-type. In particular, it has no base-uri.

The p:os-exec step runs an external command passing the input that arrives on its source port as standard input, reading result from standard output, and error from standard error. The p:os-exec step executes the command passed on command with the arguments passed on args. The processor does not interpolate the values of the command or args (for example, expanding references to environment variables). It is a dynamic error if the command cannot be run. If the cwd option is specified, it identifies the directory that will be the current working directory when execution begins. To resolve variations in the syntax of directory specifications (“/tmp” vs. “C:\tmp” vs “file:///c:/tmp”, for example), the value will be normalized with the p:urify function. It is a dynamic error if the current working directory cannot be changed to the value of the cwd option. If cwd is not specified, the current working directory is implementation-defined. If the path-separator option is specified, every occurrence of the character identified as the path-separator character that occurs in the command, args, or cwd will be replaced by the platform-specific path separator character. It is a dynamic error if the path-separator option is specified and is not exactly one character long. The source port is declared to accept a sequence so that it can be empty. If no document appears on the source port, then the command receives nothing on standard input. If a document does arrive on the source port, it will be passed to the command as its standard input. It is a dynamic error if more than one document appears on the source port of the p:os-exec step. The serialization option is used to control the serialization of the document before passing it to the standard input. If a document has a “serialization” document property, the effective value of the serialization options is the union of the two maps, where the entries in the “serialization” document property take precedence. Serialization is described in . If there is content on standard output, it is read and processed as described in p:load with result-content-type taken as value for p:load's content-type option. The created document is returned on result. Otherwise result will be empty. If there is content on standard error, it is read and processed as described in p:load with error-content-type taken as value for p:load's content-type option. The created document is returned on error. Otherwise error will be empty. The exit-status port always returns a single c:result element which contains the system exit status that the process returned. The specific exit status values returned by a process invoked with p:os-exec are implementation-dependent. If a failure-threshold value is supplied, and the exit status is greater than that threshold, then the p:os-exec step must fail. It is a dynamic error if the exit code from the command is greater than the specified failure-threshold value. This failure, like any step failure, can be captured with a p:try. No document properties are preserved.

These steps can raise dynamic errors. A dynamic error is one which occurs while a pipeline is being evaluated. Examples of dynamic errors include references to URIs that cannot be resolved, steps which fail, and pipelines that exhaust the capacity of an implementation (such as memory or disk space). For a more complete discussion of dynamic errors, see . If a step fails due to a dynamic error, failure propagates upwards until either a p:try is encountered or the entire pipeline fails. In other words, outside of a p:try, step failure causes the entire pipeline to fail. The following errors can be raised by these steps:

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.

The following features are implementation-defined:

The following features are implementation-dependent:

Glossary needs to be generated This specification includes by reference a number of ancillary files. An XProc step library for the declared steps.