RE: What is passed between processes?

I think simplicity is a key to the success of the standard and we should
not burden the user with the overwhelm terms of SAX, DOM, PSVI, etc. We
should make sure there is interoperability between the pipeline
implementations. However, the interoperability between components from
different implementations seems to be an ambitious goal to me. 

>From a user point of view, I would envision there is a tool that allows
me to grab components from a UI and build a graph of processing. The
definition of each component allows the implementation to determine
whether two components can be connected and be prompted for required
parameters if any. I may use this graph as a module to build an even
more complicated system.

If I decide to switch to a different vendor/implementation, I expect it
to work. I may get some warning about missing components, but it should
still complete the process.  

Does this sound like a reasonable scenario?

Andrew



> -----Original Message-----
> From: public-xml-processing-model-wg-request@w3.org
[mailto:public-xml-
> processing-model-wg-request@w3.org] On Behalf Of Richard Tobin
> Sent: Tuesday, January 10, 2006 3:29 PM
> To: Robin Berjon; Norman Walsh
> Cc: public-xml-processing-model-wg@w3.org
> Subject: Re: What is passed between processes?
> 
> 
> > Could this be addressed by requiring each component to specify its
> > preferred input and output types (sax, dom, xdm, xml, exi, etc. --
> > with a requirement on all components to accept "xml")
> 
> I'm not sure this requirement would be particularly useful.  Requiring
> a component implemented as a Java class to accept serialized XML is
> only useful for other Java pipelines that use the same API to create
> an instance of the component and run it, and is no use at all to a
> pipeline implemented in Python.  And if you've going so far as to
> define the Java API, you might as well require a SAX interface.
> 
> At the high end of what might be done, I envisage that each component
> type (XSLT, schema-validate, etc) would have a description of its
> inputs, outputs, and parameters, and each component implementation
> would have a description that points to its type description, and also
> specifies the pipeline implementation types it works with (unix
> pipeline, some agreed Java API, etc) and the input and output types it
> supports (SAX, DOM, DOM with PSVI, plain XML, etc).
> 
> > and coming up
> > with a simple algorithm to pick the best input/output match at each
> > junction (possibly also requiring that the implementation should
> > provide at least certain adapters)?
> 
> Yes, implementations could provide SAX-to-DOM adaptors and the like,
> or they could use a component that did the conversion.
> 
> -- Richard

Received on Tuesday, 10 January 2006 21:56:26 UTC