Status of this Document
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.
This document has been produced by the W3C XML Processing Model Group
as part of the XML
Activity and is an continuation of the work done by the XML Core
Working Group. This document supercedes their requirement document note.
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.
1 Introduction
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, the
language for the decription of these interactions, and the inputs and
outputs of the overall process. This specification is not generally
concerned with the implementations of actual XML processes participating
in these interactions.
2 Design Principles
The design principles described in this document are guiding ideals
for both the requirements and use cases as well as the future
specifications produced to satisfy this document.
Infoset Processing: Any XML document in this
specification is operated on as an information set. Processes may
consume or produce information sets to inspect, augment, extract, or
produce new informations.
Technology Neutral: Applications should be free to
implement XML processing using appropriate technologies such as SAX,
DOM, or other infoset representations.
3 Terminology
Do we want a terminology section where we introduce common terms that
exist in current XML pipeline/processing languages?
4 Requirements
This list would be replaced with the longer version of the
sections.
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.
4.1 Address Practical Interoperability Concerns
We'd describe the requirement in more detail here...
Supporting use cases:
4.2 Small and Simple Language
We'd describe the requirement in more detail here...
Supporting use cases:
4.3 Allow Control Over Inputs, Outputs, and Parameters
We'd describe the requirement in more detail here...
Supporting use cases:
5 Use cases
This list would be replaced with the longer version of the
sections.
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.
5.1 Extracting MathML
Each use case would explain the inputs, outputs, and sequence of
processing steps. A diagram would be nice too.
5.2 Style an XML Document in a Browser
Each use case would explain the inputs, outputs, and sequence of
processing steps. A diagram would be nice too.
5.3 Apply a Sequence of Operations
Each use case would explain the inputs, outputs, and sequence of
processing steps. A diagram would be nice too.