- From: Norman Walsh <Norman.Walsh@Sun.COM>
- Date: Thu, 26 Jan 2006 10:54:49 -0500
- To: Alex Milowski <alex@milowski.org>
- Cc: public-xml-processing-model-wg@w3.org
- Message-ID: <87hd7rf0hi.fsf@nwalsh.com>
> 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/should/must/
s/allow/allowed/
> encouraged (e.g. for the XPath 2.0 Data Model).
>
> 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.
I can't parse that. Perhaps:
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
supports optimizations and integrates with other
technologies.
> Arbitrary Components
>
> The specifications should allow use of XML-in-XML-out components.
Perhaps:
The specification should allow arbitrary components that accept
XML as input and produce XML as output to be used.
> 3 Terminology
>
> [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.
Using "iteration" here presupposes that we've decided to support iteration.
I'm not sure we have.
> [Definition: Specification Language]
s/Specification/Pipeline Specification/
> A specification language is an XML vocabulary in which an XML
> pipeline is described.
>
> [Definition: Step]
>
> A step is a specification of how a component is used in a pipeline
> that includes inputs, outputs, and parameters.
Perhaps:
A step is a single stage in a pipeline, a single component with
its associated inputs, outputs, and parameters.
>
> [Definition: Component]
>
> A component is an particular XML technology (e.g. XInclude, XML
> Schema Validity Assessment, XSLT, XQuery, etc.).
Perhaps:
A component is an implementation of an XML technology
(such as XInclude, XML Schema Validity Assessment, XSLT,
XQuery, etc.). A component accepts zero or more inputs
and parameters, performs some operation, and produces
zero or more results.
> [Definition: Component Vocabulary]
>
> A component vocabulary is the set of XML elements that describe
> the process by which an output is produced (e.g. an XSLT
> transformation). This is typically codified in an W3C or RelaxNG
> schema.
That doesn't really work for me, but I don't have a better suggestion
just at the moment.
> [Definition: Pipeline Environment]
>
> The technology environment in which the XML Pipeline is used (e.g.
> command-line, web servers, editors, browsers, embedded
> applications, etc.).
Perhaps:
The infrastructure that supports the evaluation of an XML
Pipeline. This includes the nature of the application
performing the process, (e.g. command-line, web servers,
editors, browsers, embedded applications, etc.), language
libraries, system and user settings, and other resources
outside the scope of this specification.
We also need:
[Definition: Pipeline Document]
An XML document written in terms of a set of component vocabularies
which describes an XML Pipeline.
> 4 Requirements
>
> 4.1 Allow Control Over Inputs and Outputs of Steps and XML Pipelines
>
> The specification language must allow control over the input and output of
> each step and the overall XML Pipeline At minimum, the characteristics of
s/Pipeline/Pipeline./
s/At minimum/At a minimum/
> these inputs and outputs must be described so that binding into particular
> use environments can be accomplished by introspection. This may involve
s/use environments/pipeline environments/
s/introspection/inspecting the pipeline document/
> the use of named infoset inputs and outputs.
>
> Supporting use cases:
>
> * 5.28 No Use Case
>
> (source: [xml-core-wg])
>
> 4.2 Minimal and Loose Binding for Input and Output Specification
>
> The XML Pipeline and Specification Language must provide mechanisms for
> input and output processing options such as implicit input provided from
> the user environment (e.g. a file specified on the command-line) and
s/user environment/pipeline environment/
> direct reference by a URI value. It should be possible to enable batch
s/URI value./URI./
> processing and facilitate re-use of an XML PIpeline in different Pipeline
> Environments with different inputs or outputs.
>
> Supporting use cases:
>
> * 5.28 No Use Case
>
> (source: [xml-core-wg])
>
> (source: Rui Lopes)
>
> 4.3 Input Collection and Step Ordering
>
> The XML Pipeline and Specification Language must provide mechanism for
> exact ordering of the processing of inputs and exact ordering of steps
> over a given input.
>
> Supporting use cases:
>
> * 5.28 No Use Case
>
> (source: [xml-core-wg])
>
> 4.4 Multiple Input and Output Support
>
> XML Pipelines should be allowed to have multiple inputs or outputs.
>
> Supporting use cases:
>
> * 5.6 XQuery and XSLT 2.0 Collections
>
> (source: [xml-core-wg])
>
> (source: Alessandro Vernet)
>
> 4.5 Allow Optimization
>
> Neither the XML Pipeline nor the Specification Language should inhibit a
s/inhibit/prohibit/
> sophisticated implementation from performing parallel operations, lazy or
> greedy processing, and other optimizations.
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 Thursday, 26 January 2006 15:55:02 UTC