XProc 3.2: Data Format Description Language

Draft Community Group Report

Editor's Draft at (build 188)
This draft:
https://spec.xproc.org/pr/153
Latest editor’s draft:
https://spec.xproc.org/main/dfdl/
Editor:
John Dziurłaj
Participate:
Codeberg XProc/specification
Report an issue
Changes:
Diff against the “status quo” draft
Commits for this specification

This document is also available in these non-normative formats: XML and HTML with automatic change markup courtesy of DeltaXignia.

Copyright © 2021–2026 the Contributors to the XProc 3.2: Data Format Description Language specification, published by the XProc Next Community Group under the W3C Community Contributor License Agreement (CLA). A human-readable summary is available.

Abstract

This specification describes the p:dfdl-parse and p:dfdl-unparse step for XProc 3.2: 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).

ⓘ
Editorial Note

This draft is the “editor’s working draft” and may continue to evolve.

1. Introduction

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 XProc 3.2 steps is assumed.

2. Step library

2.1. p:dfdl-parse

The p:dfdl-parse step performs Data Format Description Language parse per Data Format Description Language. It transforms a non-XML input into an infoset (e.g. XML) by applying the specified DFDL schema.

Summary

Input port Primary Sequence Content types
schema   ✔  any 
source ✔    any 
Output port Primary Sequence Content types
result ✔  ✔  any 
Option name Type Default value
fail-on-error xs:boolean true()
infoset xs:string 'xml'
parameters map(xs:QName,item()*)? ()
root xs:QName ()
stream xs:boolean false()
variables map(xs:QName, xs:string*)? ()
Errors
Error code Description
err:XC0214 It is a dynamic error (err:XC0214) if the source document cannot be parsed by the provided schema.
err:XC0215 It is a dynamic error (err:XC0215) if root does not identify a top-level element declaration in the provided schema.
err:XC0216 it is a dynamic error (err:XC0216) for data to remain after parse.
Implementation details
Implementation Description
Defined It is implementation-defined if serializations other than XML are supported on the schema port.
Defined It is implementation-defined which additional infoset representations (for example, JSON) are supported.
Defined The parameters supported and their semantics are implementation-defined .
Defined It is implementation-defined if a DFDL processor supports streaming.
Declaration

<p:declare-step type="p:dfdl-parse">
     <p:input port="schema" sequence="true" content-types="any"/>
     <p:input port="source" primary="true" content-types="any"/>
     <p:output port="result" sequence="true" content-types="any"/>
     <p:option name="fail-on-error" as="xs:boolean" select="true()"/>
     <p:option name="infoset" as="xs:string" select="'xml'"/>      
     <p:option name="parameters" as="map(xs:QName,item()*)?"/>     
     <p:option name="root" as="xs:QName"/>                         
     <p:option name="stream" as="xs:boolean" select="false()"/>    
     <p:option name="variables" as="map(xs:QName, xs:string*)?"/>  
</p:declare-step>

XProc processors must support a schema provided as XML. It is implementation-defined if serializations other than XML are supported on the schema port.

Document properties

No document properties are preserved.

2.2. p:dfdl-unparse

The p:dfdl-unparse step performs Data Format Description Language unparse per Data Format Description Language. It transforms an infoset (for example, XML or JSON) into a non-XML data stream by applying the specified DFDL schema.

Summary

Input port Primary Sequence Content types
schema   ✔  any 
source ✔  ✔  any 
Output port Primary Sequence Content types
result ✔  ✔  any 
Option name Type Default value
fail-on-error xs:boolean true()
infoset xs:string 'xml'
parameters map(xs:QName,item()*)? ()
root xs:QName? ()
stream xs:boolean false()
variables map(xs:QName, xs:string*)? ()
Errors
Error code Description
err:XC0217 It is a dynamic error (err:XC0217) if the source infoset cannot be unparsed by the provided schema.
err:XC0218 It is a dynamic error (err:XC0218) if the specified root does not identify a top-level element declaration in the provided schema.
err:XC0219 it is a dynamic error (err:XC0219) for more than one document to appear on source.
Implementation details
Implementation Description
Defined It is implementation-defined if serializations other than XML are supported on the schema port.
Defined It is implementation-defined which additional infoset representations (for example, JSON) are supported.
Defined The parameters supported and their semantics are implementation-defined .
Defined It is implementation-defined if a DFDL processor supports streaming unparse.
Declaration

<p:declare-step type="p:dfdl-unparse">
     <p:input port="schema" sequence="true" content-types="any"/>
     <p:input port="source" primary="true" sequence="true" content-types="any"/>
     <p:output port="result" sequence="true" content-types="any"/>
     <p:option name="fail-on-error" as="xs:boolean" select="true()"/>
     <p:option name="infoset" as="xs:string" select="'xml'"/>      
     <p:option name="parameters" as="map(xs:QName,item()*)?"/>     
     <p:option name="root" as="xs:QName?"/>                        
     <p:option name="stream" as="xs:boolean" select="false()"/>    
     <p:option name="variables" as="map(xs:QName, xs:string*)?"/>  
</p:declare-step>

XProc processors must support a schema provided as XML. It is implementation-defined if serializations other than XML are supported on the schema port.

Document properties

No document properties are preserved.

3. Step Errors

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 Dynamic Errors in XProc 3.2: 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 these steps:

Step Errors
err:XC0214

It is a dynamic error if the source document cannot be parsed by the provided schema.

See: p:dfdl-parse

err:XC0215

It is a dynamic error if root does not identify a top-level element declaration in the provided schema.

See: p:dfdl-parse

err:XC0216

it is a dynamic error for data to remain after parse.

See: p:dfdl-parse

err:XC0217

It is a dynamic error if the source infoset cannot be unparsed by the provided schema.

See: p:dfdl-unparse

err:XC0218

It is a dynamic error if the specified root does not identify a top-level element declaration in the provided schema.

See: p:dfdl-unparse

err:XC0219

it is a dynamic error for more than one document to appear on source.

See: p:dfdl-unparse

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

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.

1. Implementation-defined features

The following features are implementation-defined:

  1. It is implementation-defined if serializations other than XML are supported on the schema port. See Section 2.1, “p:dfdl-parse”.
  2. It is implementation-defined which additional infoset representations (for example, JSON) are supported. See Section 2.1, “p:dfdl-parse”.
  3. The parameters supported and their semantics are implementation-defined . See Section 2.1, “p:dfdl-parse”.
  4. It is implementation-defined if a DFDL processor supports streaming. See Section 2.1, “p:dfdl-parse”.
  5. It is implementation-defined if serializations other than XML are supported on the schema port. See Section 2.2, “p:dfdl-unparse”.
  6. It is implementation-defined which additional infoset representations (for example, JSON) are supported. See Section 2.2, “p:dfdl-unparse”.
  7. The parameters supported and their semantics are implementation-defined . See Section 2.2, “p:dfdl-unparse”.
  8. It is implementation-defined if a DFDL processor supports streaming unparse. See Section 2.2, “p:dfdl-unparse”.

2. Implementation-dependent features

This step has no implementation-dependent features.

    Appendix B. References

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

    [Data Format Description Language] Data Format Description Language (DFDL) 1.0 Specification. M. Beckerle and S. Hanson, editors. Open Grid Forum. February, 2021.

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

    Appendix D. Ancillary files

    This specification includes by reference a number of ancillary files.

    steps.xpl

    An XProc step library for the declared steps.