XProc 3.0: text steps

Draft Community Group Report

Editor's Draft at 15:03 UTC (build 294)
Latest editor’s draft:
http://spec.xproc.org/master/head/text/
Editors:
Norman Walsh
Achim Berndzen
Gerrit Imsieke
Erik Siegel
Participate:
GitHub xproc/3.0-steps
Report an issue
Changes:
Diff against current “status quo” draft
Commits for this specification

This document is also available in these non-normative formats: XML, automatic change markup from the previous draft and from the last call draft courtesy of DeltaXML.


Abstract

This specification describes the optional text related steps for XProc 3.0: An XML Pipeline Language.

Status of this Document

This document is an editor's draft that has no official standing.

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).

1. Introduction

This specification describes the optional text related XProc steps. A machine-readable description of these steps may be found in steps.xpl.

Familarity with the general nature of [XProc 3.0] steps is assumed; for background details, see [XProc 3.0 Steps].

2. p:markdown-to-html

The p:markdown-to-html step converts a text document in Markdown to XHTML.

<p:declare-step type="p:markdown-to-html">
     <p:input port="source" primary="true" sequence="false" content-types="text/*"/>
     <p:output port="result" primary="true" sequence="false" content-types="application/xhtml+xml"/>
     <p:option name="parameters" as="map(xs:QName, item()*)?"/>    
</p:declare-step>

The p:markdown-to-html step expects on its source port a text document in Markdown syntax (TBD: REF TO MARKDOWN SPEC?) and converts this into XHTML. The result is returned on its result port.

TBD

Document properties

No document properties are preserved.

3. Step Errors

These steps can raise dynamic errors.

[Definition: 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 Dynamic Errors in XProc 3.0: An XML Pipeline Language.

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 this step:

A. 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.

[Definition: 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.]

[Definition: 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.]

A.1. Implementation-defined features

The following features are implementation-defined:

    A.2. Implementation-dependent features

    The following features are implementation-dependent:

      B. References

      [XProc 3.0] XProc 3.0: An XML Pipeline Language. Norman Walsh, Achim Berndzen, Gerrit Imsieke and Erik Siegel, editors.

      [XProc 3.0 Steps] XProc 3.0 Steps: An Introduction. Norman Walsh, Achim Berndzen, Gerrit Imsieke and Erik Siegel, editors.

      C. Glossary

      dynamic error

      A dynamic error is one which occurs while a pipeline is being evaluated.

      implementation-defined

      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-dependent

      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.

      D. Ancillary files

      This specification includes by reference a number of ancillary files.

      steps.xpl

      An XProc step library for the declared steps.