XML Pipeline Language (XPL) Version 1.0 (Draft)

1.1 What is XPL?

[Definition: An XPL program or program in the XPL language is a well-formed XML document whose syntax is well-formed XML [XML 1.0] conforming to the Namespaces in XML Recommendation [XML Namespaces 1.0]. Furthermore, the XML document must conform to the syntax of the XPL language described in this specification. ]

An XPL program defines orchestrated sequences of operations on XML Information Sets (Infosets). Individual operations are encapsulated within components called XML processors. Operations include production, consumption, and transformation of XML Infosets. An XPL program supports unconditional operations, and may support as well conditions, loops, and change of control following runtime errors.

1.2 Motivation

A growing number of specifications describe operations on XML documents. The best-known specification is [XSLT 1.0], a language designed to transform XML documents into other XML documents. There are other such specifications, including [XQuery], validation languages like [RELAX NG] and [XML Schema]. No current specification adequately addresses the interoperability of those specifications from the point of view of the XML Infosets they produce or consume. XPL addresses this problem.

2.1 Terminology

[Definition: The key words must, must not, required, shall, shall not, should, should not, recommended, may, and optional in this specification are to be interpreted as described in [RFC 2119]. ]

[Definition: The term information set refers to the output of an [XML 1.0] or [XML 1.1] processor, expressed as a collection of information items and properties as defined by the [XML Infoset] specification.] In this document the term Infoset is used as a synonym for information set. ]

2.2 Notation

In this document the specification of each XPL-defined element type is preceded by a summary of its syntax in the form of a model for elements of that element type. The meaning of syntax summary notation is as defined in [XSLT 2.0 Working Draft], section 2.2.

2.3 XPL Implementation

The XPL specification does not put any requirement on the underlying software platform other than being able to execute an XPL program. In fact it is hoped that XPL will be implemented in various programming languages on various platforms.

2.4 Error Handling

The following definitions are borrowed from [XSLT 2.0 Working Draft] with minor adjustments.

[Definition: An error that is detected by examining an XPL program before execution starts is referred to as a static error. ]

[Definition: An error that is not detected until an XPL program is executed is referred to as a dynamic error. ]

[Definition: Some dynamic errors are classed as recoverable errors. When a recoverable error occurs, this specification allows the XPL implementation either to signal the error (by reporting the error condition and terminating execution) in the basic profile or to take a defined recovery action and continue processing when the Exception module is available. ]

[Definition: A dynamic error that is not recoverable is referred to as a non-recoverable dynamic error. When a non-recoverable dynamic error occurs, the XPL implementation must signal the error, and the execution of the XPL program fails. ]

2.5 Qualified Names

The following definitions are borrowed from [XSLT 2.0 Working Draft] with minor adjustments.

XML processors referred to by XPL are specified as a QName using the syntax for QName as defined in [XML Namespaces 1.0].

[Definition: A QName is always written in the form (NCName ":")? NCName, that is, a local name optionally preceded by a namespace prefix. When two QNames are compared, however, they are considered equal if the corresponding expanded-QNames are the same, as described below. ]

Because an atomic value of type xs:QName is sometimes referred to loosely as a QName, this specification also uses the term lexical QName to emphasize that it is referring to a QName in its lexical form rather than its expanded form. This term is used especially when strings containing lexical QNames are manipulated as run-time values.

[Definition: A lexical QName is a string representing a QName in the form (NCName ":")? NCName, that is, a local name optionally preceded by a namespace prefix. ]

[Definition: A string in the form of a lexical QName may occur as the value of an attribute node in a stylesheet module, or within an XPath expression contained in such an attribute node, or as the result of evaluating an XPath expression contained in such an attribute node. The element containing this attribute node is referred to as the defining element of the QName. ]

[Definition: An expanded-QName contains a pair of values, namely a local name and an optional namespace URI. It may also contain a namespace prefix. Two expanded-QNames are equal if the namespace URIs are the same (or both absent) and the local names are the same. The prefix plays no part in the comparison, but is used only if the expanded-QName needs to be converted back to a string. ]

If the QName has a prefix, then the prefix is expanded into a URI reference using the namespace declarations in effect on its defining element. The expanded-QName consisting of the local part of the name and the possibly null URI reference is used as the name of the object.

In the case of a prefixed QName used as the value of an attribute in the XPL program, or appearing within an XPath expression in the stylesheet, it is a static error if the defining element has no namespace node whose name matches the prefix of the QName.

2.6 Namespace

All the elements defined by XPL must be in the http://www.orbeon.com/oxf/xpl namespace. For consistency, this specification use the prefix p. It is recommended that authors of XPL programs use that prefix as well. However the XPL implementation must only consider the namespace URI of an element to identify it as an XPL element.

3.1 Definition

[Definition: An XML processor is a component used in an XPL program and identified by a QName. ]

An XML processor is composed of:

• A set of inputs and outputs, defining how the XML processor interfaces with an XPL program. See 3.3 Inputs and Outputs.

• A behavior, defining tasks performed by the XML processor during the execution of an XPL program. See 3.4 Behavior.

A small set of XML processors must be provided by the XPL implementations. See 9 Standard XML Processor Library. However most of the XML processors provided by XPL implementations are implementation-defined. XPL implementations may also choose to be extensible and allow users of the implementation to provide their own XML processors.

The use of a QName to identify an XML processor has the following benefits:

• Shorter to write by hand than full URIs. Once an XML namespace prefix mapping is done, a qualified name only requires typing a prefix, which can be as short as one character, and a local name.

• Allows for logical grouping of processors. A single URI regroups the XML processors in a certain category, for example the XML processors implemented by a certain company.

• Consistency with other specifications. [XSLT 2.0 Working Draft] for example, uses qualified names to identify stylesheet-defined objects such as functions.

The mapping between a particular QName and an XML processor implementation is implementation-dependent.

3.2 Instances

[Definition: An XML processor instance designates a specific use of a processor in a pipeline. ]

An XML processor used in an XPL program is always instantiated. Multiple instances of the same XML processor may occur in an XPL program.

XPL does not specify how an XML processor is instantiated or keeps state information during an XPL program execution.

3.3 Inputs and Outputs

Inputs and outputs connect an XML processor instance to the rest of the pipeline. Each input may provide an XML Infoset to the XML processor instance. Each output may provide an XML Infoset produced by the processor instance.

[Definition: A static input or output is an input or output exposed by an XML processor before the execution of the XPL program. ]

[Definition: A connected input or output is an input or output of an XML processor instance connected according to 6.4 Connections. ]

[Definition: A declared input or output of an XML processor instance is an input or output with name n where a p:input or p:output element with name n is a child of the processor instance's p:processor element. See 5.3 Processor Module. ]

[Definition: A dynamic input or output is a declared input or output of an XML processor instance which is not exposed by the XML processor before the execution of the XPL program. ]

Each XML processor instance has:

• A set of inputs each identified by a name. No two inputs may have the same name. The set of inputs may be empty.

• A set of outputs each identified by a name. No two outputs may have the same name. The set of outputs may be empty.

For each static input or output, the XML processor defines whether the input or output is:

• Mandatory. Such an input or output must be declared in an XPL program. The XPL implementation should raise a static error if a statically defined mandatory input or output is not declared for a given XML processor instance.

• Optional. Such an input or output may or may not be declared in an XPL program.

In the following table "N/A" is used to designate combinations that do not exist according to the above definitions.

3.4 Behavior

The behavior of an XML processor is for the most part outside the scope of this specification, with the exception of the following aspects:

• Change of control. The XPL implementation may give control to an XML processor instance, in association with exactly zero or one connected output. If the XML processor instance has at least one declared output, the XPL implementation will always give control to the XML processor in association with an output. If the XPL implementation gives control to the XML processor instance in association with an output, while in control of processing the XML processor instance must "produce" an XML Infoset associated with that output. If the XPL implementation does not associate an output, the XML processor does not generate an XML Infoset.

• Generating an error. The XML processor instance, while in control of processing, may generate an error that is propagated to the XPL implementation. The XPL implementation then raises a dynamic error. Even if the XPL implementation expects a resulting XML Infoset, no such XML Infoset is provided by the XML processor. With the Exception module, the error is considered an exception and may be a recoverable dynamic error. This means that if an exception handler is available for that exception, it can be caught and processing may resume. Otherwise, the error is a non-recoverable dynamic error. With the basic profile, all errors raised by an XML processor are non-recoverable dynamic errors.

  Example 1: An XML processor may generate an error if the XML Infoset read on any of its inputs does not conform to a format expected by the XML processor. Similarly, the interaction with other software may cause the XML processor to report errors.

  Example 2: An XML processor may generate an error if the interaction with other software reports an error.

• Reading inputs. The XML processor instance, while in control of processing, may read one or more of its connected inputs. "Reading an input" means that the XML processor instance asks the XPL implementation to produce the XML Infoset associated with that particular connected input.

• Reading outputs. "Reading an output" means that the XPL implementation gives control to an XML processor instance in association with an output. When in control, the XML processor instance must produce the XML Infoset associated with that particular output. If the XML implementation reads a dynamic output, the XML processor instance may generate a dynamic error if it does not support that output.

While in control of processing, an XML processor instance may perform other tasks, like interacting with other software. Such tasks are outside the scope of the present specification.

XPL does not specify the format or API used by the XPL implementation to provide XML Infosets to an XML processor, or how an XML processor returns XML Infosets to the XPL implementation.

4.1 Structure

An XPL program consists of:

• Input and output parameters. Each input or output has a name, and may either provide the XPL program with an XML Infoset (case of an input), or produces an XML Infoset (case of an output). The XPL program may have no input or output.

• A sequence of statements. Statements are discussed in 4.3 Statements and sequences of statements in 4.4 Sequence of Statements.

4.2 XML Infoset Identifiers

In XPL, XML Infoset identifiers are exposed by statements using the infoset attribute.

4.3 Statements

An XPL program statement is an element with the following characteristics:

• Scoped XML Infoset Identifiers. A set of XML Infoset identifiers in scope at the point where the statement occurs in the XPL program. The set may be empty.

• Exposed XML Infoset Identifiers. A set of XML Infoset identifiers exposed by the statement. There cannot be an intersection between the scoped XML Infoset identifiers and the exposed XML Infoset identifiers. For example, a statement can attempt to expose, with an infoset attribute on a p:output element, an XML Infoset identifier already present in the set of scoped XML Infoset identifiers. Such a condition must raise a static error. This is referred to as the no-collision rule.

The set of XML Infoset identifiers in scope for a statement of an XPL program, unless specified otherwise, consists of the union of the identifiers in scope for the previous statement and the identifiers exposed by the previous statement in document order.

If there is no such previous statement, the set of XML Infoset identifiers in scope for a statement of an XPL program, unless specified otherwise, consists of the set of identifiers specified by the infoset attributes of the XPL program inputs. In other words, this condition applies to the first statement of an XPL program.

In this specification, a statement consists of either a p:processor, p:choose or p:for-each element. A statement may contain nested statements. For example, p:choose may contain one or more p:processor elements.

4.4 Sequence of Statements

5.1 Introduction

The XPL syntax is organized into modules. The Pipeline module and the Processor module constitute the basic framework of XPL. Other modules build on top that framework to provide enhanced functionality. Modules are grouped into profiles, see 11 Conformance.

5.2 Pipeline Module

<p:pipeline
    version = "1.0" >
    <!-- Content: (p:input*, p:output*, (p:processor | p:choose | p:for-each)*) -->
</p:pipeline>
            

<p:input
    name = ncname
    infoset? = ncname
    schema-uri? = uri-reference
    schema-href? = uri-reference />
            

<p:output
    name = ncname
    infosetref = infoset-reference
    schema-uri? = uri-reference
    schema-href? = uri-reference />
            

5.3 Processor Module

<p:processor
    name = qname >
    <!-- Content: (p:input* | p:output*) -->
</p:processor>
            

<p:input
    name = ncname
    infosetref? = infoset-reference
    schema-uri? = uri-reference
    schema-href? = uri-reference >
    <!-- Content: (embedded-infoset)? -->
</p:input>
            

<p:output
    name = ncname
    infoset = ncname
    schema-uri? = uri-reference
    schema-href? = uri-reference >
</p:output>
            

5.4 Choose Module

<p:choose
    infosetref = infoset-reference >
    <!-- Content: (p:output*, p:when+, p:otherwise?) -->
</p:choose>
            

<p:output
    infoset = ncname
    infosetref = infoset-reference
    schema-uri? = uri-reference
    schema-href? = uri-reference />
            

<p:when
    test = expression >
    <!-- Content: (p:processor | p:choose | p:for-each)* -->
</p:when>
            

<p:otherwise>
    <!-- Content: (p:processor | p:choose | p:for-each)* -->
</p:otherwise>
            

5.5 Repeat Module

<p:for-each
    infosetref = infoset-reference
    select = expression
    schema-href? uri-reference
    schema-uri? uri-reference >
    <!-- Content: (p:output?, (p:processor | p:choose | p:for-each)*) -->
</p:for-each>
            

<p:output
    infosetref = infoset-reference
    infoset = ncname
    schema-uri? = uri-reference
    schema-href? = uri-reference >
</p:output>
            

5.6 Schema References

Several elements support the optional schema-uri and schema-href attributes. The purpose of these attributes is to refer to a schema defined outside of the XPL program, and to use that schema to validate a particular XML Infoset.

Those attributes are associated with a particular XML Infoset, depending on the element they are associated with.

If the schema-href attribute is present, it must contain a URL referring to either an W3C XML Schema schema, or a Relax NG schema.

If the schema-uri attribute is present, it must contain a URI identifying either an W3C XML Schema schema, or a Relax NG schema. For W3C Schemas, it should specify the namespace URI that is the target namespace of the schema. The way the mapping between the URI and the actual schema is done is outside the scope of XPL.

If both attributes are present, a static error must be raised.

The use of schema-href allows easily using schemas bundled with an XPL program. The use of schema-uri allows the use of URIs, commonly used with XML Schema, which provide a level of abstraction hiding the actual storage location of actual schema files.

6.1 Introduction

The XPL processing model is based on declarative and lazy evaluation models. This means that, unlike most imperative programming languages, processing order is determined by first considering the results to be produced, and then walking down a chain of dependencies to determine what statements must be executed. The benefit of lazy evaluation and declarative programming is that they have more potential for allowing implementations with different levels of optimization.

6.2 Input Invariance

A processor, when given control, may read one or more of its inputs. The XPL implementation must make sure that, if a processor reads the same input several times over a single execution of a sequence of statements, the XML Infoset read is the same.

6.3 Output Invariance

Multiple statements may consume XML Infosets in an XPL program by referencing the same XML Infoset identifier. These consumers may request the XML Infoset at different times during program execution. The XPL implementation must make sure that the XML Infoset read by those different processors is the same for a given execution of a sequence of statements.

6.4 Connections

A processor input with name n is said to be connected when:

• The corresponding p:processor element contains an embedded p:input element with an attribute name with value n.

• The p:input element contains an embedded XML Infoset, or has a valid infosetref attribute. See 8 Infoset Reference.

A processor output with name n is said to be connected when:

• The corresponding p:processor element contains an embedded p:output element with an attribute name with value n.

• The p:output element exposes an XML Infoset identifier i.

• There exists an expression in the XPL program referring to i.

6.5 XML Processor Execution

The execution of a processor always starts with an initialization phase. During the initialization phase, the XML processor:

• Is given control by the XPL implementation, through a mechanism outside the scope of XPL.

• Should reinitialize previous execution state if any.

• May read one or more of its inputs, in any order and at any time.

• May perform tasks unrelated to the XPL program, like interacting with other software.

• The processor should return control to the XPL implementation after a finite amount of time. There may be some rare uses cases where not returning control may be desirable.

If a processor does not have any declared output, the execution of the processor terminates with the end of the initialization phase.

When a processor has at least one output, execution of the processor may resume at a later point when the XML Infoset associated with an output is requested by the XPL implementation. This is called a read phase. During such a phase, the processor:

• Is given control by the XPL implementation, through a mechanism outside the scope of XPL.

• May access execution state created during the initialization phase or previous read phases, if necessary.

• May read one or more of its inputs, in any order and at any time.

• May perform tasks unrelated to the XPL program, like interacting with other software.

• The processor should return control to the XPL implementation after a finite amount of time, and return an XML Infoset associated with that output.. There may be some rare uses cases where not returning control may be desirable.

There is no guarantee that an XML processor will read one or more of its inputs. This is entirely left to the implementor of the XML processor.

There is no guarantee that a processor in an XPL program will be initialized, or will have any read phase after an initialization phase. The only guarantee of execution is that if an XML processor does not have any outputs and is declared in a sequence of statements which is executed, then it will be initialized.

6.6 Sequence of Statements Execution

The execution of a sequence of statements always starts with an initialization phase. During the initialization phase:

1. The sequence is initialized. The meaning of this is largely implementation dependent, but may for example mean that execution state information kept by the implementation and related to the execution of this sequence of statements is discarded, for example, discarding XML Infosets associated with some Infoset identifiers in the sequence. It may also notifying processor instances that they should reinitialize some internal state.

2. A list of statements in the sequence that do not have any declared output is established in document order (in the order they appear in the XPL program). Each statement in the list is then initialized in that order.

3. During the initialization of a statement, that statement may read one or more of its inputs. When doing so, control is passed to the XPL implementation again. The XPL implementation must then obtain the XML Infoset associated with that input, possibly by evaluating an expression. That expression may refer to one or more XML Infoset identifier. The XPL implementation must obtain those XML Infoset identifiers in turn, by executing read phases on the statements exposing those identifiers. When XML Infosets associated with all the XML Infoset identifiers used by the expression are obtained, the XML Infoset associated with the input is complete, and control is returned to the statement.

If the sequence of statements exposes XML Infoset identifiers, XML Infosets associated with one or more of those identifiers may be requested by the XPL implementation. When such an identifier i is requested, a read phase is initiated on the sequence of statements:

• The statement exposing the identifier i is initialized if and only if not already done during the execution of the sequence of statements.

• The XML Infoset associated with the XML Infoset identifier i is requested from the statement by starting a read phase. The XPL implementation may decide to store the XML Infoset to fulfill further requests associated with i, and return the stored XML Infoset when possible. How this is achieved is implementation dependent, but in all cases output invariance must be guaranteed. See 6.3 Output Invariance.

• Like during initialization, the statement may read one or more of its inputs. The same processing model applies.

• The XML Infoset associated with the XML Infoset identifier i is forwarded to the requestor.

6.7 XPL Program Execution

The execution of an XPL program consists in executing the sequence of statements contained under the p:pipeline element.

After the initialization phase, the XPL implementation may request XML Infosets associated with XPL program outputs. To achieve this, infosetref attribute associated with the XPL program output to read is evaluated. This may cause requesting one or more XML Infosets exposed by the sequence of statements, therefore executing one or more read phases on the sequence of statements.

6.8 p:choose Execution

This section is relevant only if the Choose Module is implemented.

The execution of a p:choose statement consists in:

• Obtaining the XML Infoset associated with the p:choose element's infosetref attribute. The expression is evaluated, and may cause requesting one or more XML Infosets in scope.

• For each p:when element contained in the p:choose element, evaluate the expression contained in the test attribute on the XML Infoset obtained previously. Evaluation must be performed on p:when elements in document order. The result of the expression is converted to an xs:boolean type. If this is not possible, a dynamic error is generated. If the result of the boolean expression is true(), the branch is selected. Evaluation of further p:when elements must not be performed.

• If the branches do not export any XML Infoset identifier, the selected branch is considered a sequence of statements and is simply initialized.

• If the branches export at least one XML Infoset identifier, the selected branch is considered a sequence of statements and is executed like a regular sequence of statements.

6.9 p:for-each Execution

This section is relevant only if the Repeat Module is implemented.

The execution of a p:for-each statement consists in:

• Obtaining the XML Infoset associated with the p:for-each element's infosetref attribute. The expression is evaluated, and may cause requesting one or more scoped XML Infosets.

• Evaluating the expression on the p:for-each element's select attribute. This expression must return a sequence of elements called the iteration sequence. The iteration sequence may be empty. If it does not consist of a sequence of elements, a dynamic error must be raised. The iteration sequence may be calculated lazily, and the dynamic error may be raised only when the first item in the sequence that is not an element is found, if any.

• If there is no nested p:output element, the embedded sequence of statements is executed once for each element in the iteration sequence. Because there is no read phase, this means that the sequence of statements is initialized once for each element in the iteration sequence. The function current() of 8 Infoset Reference is assigned a new XML Infoset built from the current element of the iteration sequence. See 7 Infoset Extraction.

• If there is a nested p:output element, the expression on the infosetref attribute of the embedded p:output element, called the output expression, must be evaluated. It may refer to XML Infoset identifiers of two types:

  • XML Infoset identifiers in scope for the p:for-each statement. Those are called external XML Infoset identifiers.
  • XML Infoset identifiers exposed by the sequence of statements contained within the p:for-each statement. Those are called local XML Infoset identifiers.

  A local XML Infoset identifier must be interpreted as sequences of XML Infosets. Each execution of the sequence of statements produces the next value in the sequence. After initializing the embedded sequence of statements, a read phase is performed for each such identifier, in the order in which they appear in the output expression.

  External XML Infoset identifiers refer to sequences of XML Infoset identifiers that contain only one element.

  When the embedded sequence of statements has been executed a number of times equal to the number of elements in the iteration sequence, the output expression must have produced a complete XML Infoset. That XML Infoset is associated with the identifier on the infoset attribute of the p:output element.

• If there is a p:output element within the p:for-each element but the iteration sequence is empty, the embedded sequence of statements is never executed. The output expression is evaluated with each local XML Infoset identifier replaced with an empty sequence.

6.10 Schema References

Several elements support the optional schema-uri and schema-href attributes. The purpose of these attributes is to refer to a schema defined outside of the XPL program, and to use that schema to validate a particular XML Infoset. See 5.6 Schema References for information about the syntax. If none of those attributes is present, the processing model is not influenced by this section.

The application must load the schema referred to by one of the two attributes if present. It is allowed to load the schema before execution, but at the latest the schema must be loaded as soon as the first parts of the XML Infoset associated with the schema is available.

It is a dynamic error if the schema cannot be loaded during execution. Optionally, if the XPL implementation loads the schema before execution, it may raise a static error instead.

If the XML Infoset associated with the schema read on the input does not validate against the schema, a dynamic error must be raised.

8.1 Local Reference

A local reference starts with the #sign and is followed by an XML Infoset identifier. It refers to either a single XML Infoset, or a sequence of XML Infosets. Whenever a local reference is used, it must refer to a scoped XML Infoset identifier.

A local reference evaluates to the XML Infoset or XML Infoset sequence identified by the XML Infoset identifier.

8.2 URI Reference

This definition is borrowed from [XSLT 2.0 Working Draft]:

Note that this is a wider definition than the definition in [RFC2396], for example it does not require non-ASCII characters to be escaped.

URI references used to identify external resources must conform to the same rules as the locator attribute (href) defined in section 5.4 of [XLink]. If the URI reference is relative, then it is resolved (unless otherwise specified) against the base URI of the containing element node, according to the rules of [RFC2396], after first escaping all characters that need to be escaped to make it a valid RFC2396 URI reference.

8.3 Aggregation

The aggregate() function returns a new XML Infoset. In terms of [XQuery 1.0 and XPath 2.0 Data Model], it can be defined as follows:

fn:aggregate($root as xs:QName, $arg1 as node()*, ...) as document-node()
                

The resulting XML Infoset's document information item contains:

• A document element with the QName specified as the first argument of the aggregate() function.

• No processing instructions, comments, and document type declaration information.

The aggregate() function can take, in additoin to the first element specifying the QName, one or more additonal arguments. Each of those arguments is of type node()*, in other words a sequence of nodes as defined by [XPath 2.0 Working Draft], with the exception that attribute nodes and namespace nodes are not allowed. The types returned are consistent with the acquired Infoset defined in [XInclude]. The Infoset associated with each node in the sequence is added as child information items to the document element information item.

8.4 Current XML Infoset

This section is relevant only if the Repeat Module is implemented.

The current() function evaluates to the current element of the iteration sequence within a p:for-each statement. In terms of [XQuery 1.0 and XPath 2.0 Data Model], it can be defined as follows:

fn:current() as document-node()
                

8.5 XPointer

XPointer expressions must support [XPointer Framework] and [XPointer xmlns() Scheme].

They must also support a subset of [XPointer xpointer() Scheme] working with standard XPath 1.0, or an extension of that subset working with XPath 2.0. This means that there is no requirement for XPL to support the XPath extensions proposed by [XPointer xpointer() Scheme].

9.1 Introduction

XPL defines a set of standard XML processors, called the XPL standard XML processor library, that must be implemented by any conformant implementation. All the XML processors are identified with a QName with URI http://www.orbeon.com/oxf/xpl/standard. The recommended namespace prefix for that QName is xpl.

9.2 Identity Processor

<p:processor name="xpl:identity">
    <p:input name="data">...</p:input>
    <p:output name="data">...</p:output>
</p:processor>
                    

9.3 Pipeline Processor

<p:processor name="xpl:pipeline">
    <p:input name="pipeline">...</p:input>
</p:processor>
                    

9.4 Null Serializer

<p:processor name="xpl:null-serializer">
    <p:input name="data">...</p:input>
</p:processor>
                    

11.1 Basic Profile

The Basic XPL profile requires implementing all of this specification except the optional Choose, Repeat and Exception modules. The Pipeline and Processor modules must be implemented.

11.2 Full Profile

The full XPL profile requires implementing all of this specification including the Pipeline, Processor, Choose, Repeat and Exception modules.

11.3 XPath Support

In XPL, XPath is used in the following places:

• Within XPointer's xpointer() scheme.

• In the test attribute of the p:when element, if the Choose module is implemented.

• In the select attribute of the p:for-each element, if the Repeat module is implemented.

XPL constructs using XPath may support the following version of XPath:

• XPath 1.0. In this case, [XPath 1.0] must be supported.

• XPath 2.0. In this case, [XPath 2.0 Working Draft] must be supported. In this case XPL is the host language. It should not provide any in-scope schema definitions in the static context; it should provide the types defined by XML Schema as in-scope type definitions in the static context; it should not provide any in-scope variable.

An XPL implementation must document the version of XPath used. It may optionally allow users to configure which XPath version must be used when executing a pipeline. XPL itself does not have any provisions to configure, whether on a XPL program basis, or on a finer granularity basis, what version of XPath is used.

An [XPath 2.0 Working Draft] expression must raise a dynamic error if encountered by an XPL implementation supporting only [XPath 1.0]. Optionally, the XPL implementation may raise a static error if it is able to detect the error before execution.

12.1 Exception Module

The Exception module will support exception handling, based on a model found in other programming languages such as Java or WS-BPEL. Exception handling provides a good model to handle dynamic errors.

12.2 Repeat Module p:while Element

The p:while statement will provide a repetition statement based on the idea of a repetition until a certain condition is reached.