- From: Norman Walsh <Norman.Walsh@Sun.COM>
- Date: Wed, 15 Feb 2006 14:19:37 -0500
- To: public-xml-processing-model-wg@w3.org
- Message-ID: <87slqkv392.fsf@nwalsh.com>
|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
s/will depend/depend/
| of these specifications. Considering how implementations of these
| specifications might interact raises many issues related to
| interoperability. This specification contains requirements on an XML
| Pipeline 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
| description 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 Terminology
|
| [Definition: XML Information Set or "Infoset"]
|
| An XML Information Set or "Infoset" is the name we give to any
| implementation of a data model for XML which supports the
| vocabulary as defined by the XML Information Set recommendation
| [xml-infoset-rec].
|
| [Definition: XML Pipeline]
|
| An XML Pipeline is a conceptualization of a flow of a
| configuration of steps and their parameters. The XML Pipeline
| defines a process in terms of order, dependencies, or iteration of
| steps over XML information sets.
Suggest:
An XML Pipeline is a set of Steps. The XML Pipeline defines the order
in which these Steps are applied; the input, output, and parameters,
for each step; and the final result. This definition is provided in
terms of order, dependencies, or iteration of steps over XML
information sets.
| [Definition: XML Pipeline Specification Document]
|
| A pipeline specification document is an XML document that
| described an XML pipeline.
s/described/describes/
| [Definition: Step]
|
| A step is a specification of how a component is used in a pipeline
| that includes inputs, outputs, and parameters.
|
| [Definition: Component]
|
| A component is an particular XML technology (e.g. XInclude, XML
s/an particular/a particular/
s/technology/process/
| Schema Validity Assessment, XSLT, XQuery, etc.).
|
| [Definition: Input Document]
|
| An XML infoset that an input to a XML Pipeline or Step.
|
| [Definition: Output Document]
|
| The result of processing by an XML Pipeline or Step.
s/by //
| [Definition: XML Pipeline Environment]
|
| The technology or platform environment in which the XML Pipeline
| is used (e.g. command-line, web servers, editors, browsers,
| embedded applications, etc.).
|
| [Definition: Streaming]
|
| The ability to parse an XML document and pass infoitems between
s/infoitems/information/
| components without building a full document information set.
|
|3 Design Principles
|
| The design principles described in this document are a kind of requirement
| whose compliance with is an overall goal for the specification. It is not
| necessarily the case that a specific feature meets the requirement.
| Instead, it should be viewed that the whole set of specifications related
| to this requirements document meet that overall goal specified in the
| design principle.
Suggest:
The design principles described in this document are a class of
requirement that captures some high-level, overall goals for the
specification. It is not necessarily the case that a specific feature
can be tested against these requirements. Instead, it should be viewed
that the whole set of specifications related to this requirements
document meet that overall goal specified in each design principle.
| Technology Neutral
|
| Applications should be free to implement XML processing using
| appropriate technologies such as SAX, DOM, or other infoset
| representations.
|
| Platform Neutral
|
| Application computing platforms should not be limited to any
| particular class of platforms such as clients, servers,
| distributed computing infrastructures, etc. In addition, the
| resulting specifications should not be swayed by the specifics of
| use in those platform.
Suggest:
Application computing platforms should not be limited to any
particular class of platforms such as clients, servers,
distributed computing infrastructures, etc. or any particular
implementation language.
| Small and Simple
|
| The language should be as small and simple as practical. It should
| be "small" in the sense that simple processing should be able to
| stated in a compact way and "simple" in the sense the
| specification of more complex processing steps do not require
| arduous specification steps in the XML Pipeline Specification
| Document.
The language should be as small and simple as practical. It should be
"small" in the sense that simple pipelines should be reasonably short
and "simple" in the sense that the specification of more complex
processing should not be unduly arduous.
| Straightforward Core Implementation
|
| It should be relatively easy to implement a conforming
| implementation of the language but it should also be possible to
| build a sophisticated implementation that their own optimizations
| and integrate with other technologies.
s/their own/performs extensive/
s/integrate/integrates/
| Address Practical Interoperability
|
| An XML Pipeline must be able to be exchanged between different
| software systems with a minimum expectation of the same result for
| the pipeline given that the XML Pipeline Environment is the same.
s/is the same/is consistent/
| A reasonable resolution to platform differences for binding or
| serialization of resulting infosets should be expected to be
| address by this specification or by re-use of existing
| specifications.
I have no idea what that sentence means.
| Arbitrary Components
|
| The specification should allow use any component technology that
| can consume or produce XML Information Sets.
|
| Infoset Processing
|
| At a minimum, an XML document is represented and manipulated as an
| XML Information Set. The use of supersets, augmented information
| sets, or data models that can be represented or conceptualized as
| information sets should be allow, and in some instances,
s/allow,/allowed,/
| encouraged (e.g. for the XPath 2.0 Data Model).
s/XPath 2.0 Data Model/XQuery 1.0 and XPath 2.0 Data Model (XDM)/
| Reuse and Support for Existing Specifications
|
| XML Pipelines need to support existing XML specifications and
| reuse common design patterns from within them. In addition, there
| must be support for the use of future specifications as much as
| possible.
|
| Control of Inputs and Outputs
|
| An XML Pipeline must allow control over specifying both
| the inputs and outputs of any process within the pipeline.
| This applies to the inputs and outputs of both the XML
| Pipeline and its containing steps. It should also allow
| for the case where there might be multiple inputs and
| outputs.
Suggest
It must be possible to specify both the inputs and outputs of any Step
in the XML Pipeline as well as the XML Pipeline as a whole. It should
also allow for the case where there might be multiple inputs and
outputs.
| Control of Flow and Errors
|
| An XML Pipeline must allow control the explicit and implicit
| handling of the flow of documents between steps. When errors
| occur, these must be able to be handled explicitly to allow
| alternate courses of action within the XML Pipeline.
Suggest
It must be possible to specify both explicit and implicit handling of
the flow of documents between steps in an XML Pipeline. When errors
occur, it must be possible to allow alternate courses of action within
the XML Pipeline.
|4 Requirements
|
| The following is a mapping of the requirements of this section to the use
| cases:
|
| Requirement Use Cases
| 5.27 Large-Document Subtree Iteration,
| 4.1 Allow Optimization 5.28 Adding Navigation to an Arbirarily
| Large Document
I don't understand this table, but maybe it's just me.
Be seeing you,
norm
--
Norman.Walsh@Sun.COM / XML Standards Architect / Sun Microsystems, Inc.
NOTICE: This email message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution is prohibited.
If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
Received on Wednesday, 15 February 2006 19:19:53 UTC