This document is also available in these non-normative formats: XML.
This document contains requirements for the development of XML Processing Model and Language, which are intended to describe and specify the processing relationships between XML resources.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
This document is a Working Group Note of the Requirements Document for an XML Processing Model and Language for describing an interoperable way for applications to describe the order in which processes should be applied to XML documents.
The W3C XML Core Working Group does not plan to continue active work on this document but may update it. Feedback on this document is however welcome and should be sent to email@example.com (archive). W3C encourages the community to indicate interest in this document and may dedicate resources to it depending on the feedback.
Publication as a Working Group Note does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This document has been produced under the 24 January 2002 CPP as amended by the W3C Patent Policy Transition Procedure. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) with respect to this specification should disclose the information in accordance with section 6 of the W3C Patent Policy. Documentation of intellectual property possibly relevant to this specification may be found at the Working Group's public IPR disclosure page.
A large and growing set of specifications describe processes operating on XML documents. Many applications will depend on the use of more than one of these specifications. Considering how implementations of these specifications might interact raises many issues related to interoperability. This specification contains requirements on an XML Processing Model and Language for the description of XML process interactions in order to address these issues. This specification is concerned with the conceptual model of XML process interactions and the language for the decription of these interactions. This specification is not generally concerned with the implementations of actual XML processes participating in these interactions.
XML documents in this specification are operated on as information sets. The processes of interest in this specification are those that construct new information sets, inspect, augment, or extract from existing information sets, or transform existing information sets to other, new information sets. Although some applications work with concrete object models that are not identical to the Infoset, it is useful to describe the processing model in terms of the Infoset. In practice, applications will use SAX event streams, DOM object models, or other representations of XML documents and their infosets.
The language must be rich enough to address practical interoperability concerns.
The language should be as small and simple as possible.
The language must allow the inputs, outputs, and other parameters of a components to be specified.
The language must define the basic minimal set of mandatory input processing options and associated error reporting options required to achieve interoperability.
Given a set of components and a set of documents, the language must allow the order of processing to be specified.
It should be relatively easy to implement a conformant implementation of the language, but it should also be possible to build a sophisticated implementation that can perform parallel operations, lazy or greedy processing, and other optimizations.
The model should be extensible enough so that applications can define new processes and make them a component in a pipeline.
The model must provide mechanisms for addressing error handling and fallback behaviors.
The model could allow conditional processing so that different components are selected depending on run-time evaluation.
The model should not prohibit the existence of streaming pipelines.
The model should allow multiple inputs and multiple outputs for a component.
The model should allow any data set conforming to one of the W3C standards, such as XML 1.1, XSLT 1.0, XML Query 1.0, etc., to be specified as an input or output of a component.
Information should be passed between components in a standard way, for example, as one of the data sets conforming to an industry standard.
The language should be expressed in XML. It should be possible to author and manipulate documents expressed in the pipeline language using standard XML tools.
The pipeline language should be declarative, not based on APIs.
The model should be neutral with respect to implementation language. Just as there is no single language that can process XML exclusively, there should be no single language that can implement the language of this specification exclusively. It should be possible to interoperably exchange pipeline documents across various computing platforms. These computing platforms should not be limited to any particular class of platforms such as clients, servers, distributed computing infrastructures, etc.
Extract MathML fragments from an XHTML document and render them as images. Employ an SVG renderer for SVG glyphs embeded in the MathML.
Style an XML document in a browser with one of several different stylesheets without having multiple copies of the document containing different xml-stylesheet directives.
Apply a sequence of operations such XInclude, validation, and transformation to a document, aborting if the result or an intermediate stage is not valid.
Run a program of your own, with some parameters, on an XML file and display the result in a browser.
Allow an application on a handheld device to construct a pipeline, send the pipeline and some data to the server, allow the server to process the pipeline and send the result back.