2021 2022 2023 2024 2025 2026 the Contributors to the XProc 3.2 Standard Step Library specifications XProc/specification XProc Next XML John Dziurłaj This specification describes the p:dfdl-parse and p:dfdl-unparse step for XProc 3.2: 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:dfdl-parse and p:dfdl-unparse 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:dfdl-parse step performs Data Format Description Language parse per . It transforms a non-XML input into an infoset (e.g. XML) by applying the specified DFDL schema. XProc processors must support a schema provided as XML. It is implementation-defined if serializations other than XML are supported on the schema port. If fail-on-error is true, the step will raise an error if the input cannot be parsed by the schema. It is a dynamic error if the source document cannot be parsed by the provided schema. If fail-on-error is false, no error will be raised and processors may return implementation-defined diagnostics on result . The infoset specifies the desired content type of the infoset. Processors must support the value xml. It is implementation-defined which additional infoset representations (for example, JSON) are supported. The parameters supported and their semantics are implementation-defined . The variables stores external DFDL variables whose names are specified by a xs:QName. The root specifies the target top-level element in the schema to start processing. By default, the first top-level element of the schema will be used. It is a dynamic error if root does not identify a top-level element declaration in the provided schema. If stream is true, when the DFDL processor encounters remaining data after parse, the parse operation repeats with the remaining data. Processing repeats until end-of-data, a parse failure, or a parse consumes no additional data. Each successful parse repetition produces a new document on result. If stream is false, it is a dynamic error for data to remain after parse. It is implementation-defined if a DFDL processor supports streaming. No document properties are preserved.

The p:dfdl-unparse step performs Data Format Description Language unparse per . It transforms an infoset (for example, XML or JSON) into a non-XML data stream by applying the specified DFDL schema. XProc processors must support a schema provided as XML. It is implementation-defined if serializations other than XML are supported on the schema port. If fail-on-error is true, the step will raise an error if the infoset cannot be unparsed by the schema. It is a dynamic error if the source infoset cannot be unparsed by the provided schema. If fail-on-error is false, no error will be raised and processors may return implementation-defined diagnostics on result or as out-of-band reports. The infoset specifies the content type of the infoset on source. Processors must support the value xml. It is implementation-defined which additional infoset representations (for example, JSON) are supported. The parameters supported and their semantics are implementation-defined . The variables stores external DFDL variables whose names are specified by a xs:QName. The root specifies the target top-level element in the schema to start processing. By default, the first top-level element of the schema will be used. It is a dynamic error if the specified root does not identify a top-level element declaration in the provided schema. If stream is true, each document on source is unparsed independently and produces a corresponding document on result. If stream is false, it is a dynamic error for more than one document to appear on source. It is implementation-defined if a DFDL processor supports streaming unparse. 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:

This step has no implementation-dependent features.

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