- From: Alessandro Vernet <avernet@orbeon.com>
- Date: Tue, 10 Jan 2006 11:46:17 -0800
- To: public-xml-processing-model-wg@w3.org
On 1/10/06, Richard Tobin <richard@inf.ed.ac.uk> wrote: > - the pipeline language itself. I call an implementation of this > a "pipeline engine"; > > - a set of standard components, such as XSLT and XInclude; > > - a framework for writing additional components that are interoperable > with other suppliers' pipeline engines and components; > > - a component description language that would specify such things as > the number of inputs and outputs a component has, what parameters it > takes, and what infoset extensions it needs. Hi Richard, Good question. My feeling is that we want to standardize your first point above. The second point is certainly paramount for interoperability and I see this as something we want to standardize; the question is when? For a first version of the recommendation, I think it is important to respect the schedule established in our WG charter, at the cost, if necessary, of taking a pass on the standardization of the second point. > (1) A system in which components are standalone programs that read and > write plain XML files, and which compiles pipelines into > unix-style shell scripts. Obviously this system can only handle > vanilla infosets, though we could (later) define standard > serializations of extended infosets such as the PSVI. > > (2) A system in which components are Java classes conforming to an > interface. The interface would have methods to start the component, > somehow read and write infosets (either complete or streaming), > and signal and receive exceptions. The infosets would allow > arbitrary extensions some of which would be standardized. What impact, if any, would the distinction between (1) and (2) have on the design of the language itself? Alex -- Blog (XML, Web apps, Open Source): http://www.orbeon.com/blog/
Received on Tuesday, 10 January 2006 19:46:28 UTC