XProc 3.0: JSON steps
Editor's Draft
- This Version:
- https://xproc.github.io/3.0-steps/master/head/os/
- Latest Version:
- http://spec.xproc.org/master/head/os/
- Editors:
- Norman Walsh
- Achim Berndzen
- Gerrit Imsieke
- Erik Siegel
- Repository:
- This specification on GitHub
- 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 courtesy of DeltaXML.
Copyright © 2018 @@FIXME:
Abstract
This specification describes the p:join-json
step 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 section describes the status of this document at the time of its publication. Other documents may supersede this document.
This document is derived from XProc: An XML Pipeline Language published by the W3C.
Table of Contents
1 Introduction
This specification describes the p:join-json
XProc step. 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:json-join
The p:json-join
step joins a sequence of JSON documents into a single JSON document (an array). If the sequence on port source
is empty, the empty sequence is returned on port result
.
<p:declare-step
type
="
p:join-json
"
>
<p:input
port
="
source
"
sequence
="
true
"
content-types
="
json
"
/>
<p:output
port
="
result
"
content-types
="
application/json
"
/>
<p:option
name
="
flatten-arrays
"
as
="
xs:boolean
"
select
="
false()
"
/>
</p:declare-step>
If option flatten-arrays
is false
, a member in the array is created for each document in the sequence appearing on portsource
. Therefore the produced array with have the same number of members as the number of documents appearing on port source
. However if flatten-arrays
is true
, for each member of an array appearing at the top level of a JSON document on port source
a new member in the resulting array will be created.
3 Step Errors
This step 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.